技能介绍

问题在哪

写技术内容的人常常卡在格式分裂：PDF、Office、网页各一套，改一版要手工重排；给编辑的 Word 和给自己看的 HTML 也不是同一套工具链。这个技能把 Markdown 当源代码，把 HTML、DOCX 当可重复生成的产物，用四条能力拼成一条可决策的流水线，而不是「随便转一下」。

四条能力怎么选

| 意图 | 能力 | 脚本 |
|------|------|------|
| 导入 PDF/DOCX/网页等 | 万物→md | scripts/any_to_md.py（markitdown） |
| 可发布、可阅读的 HTML | md→精美 html | scripts/md_to_html.py（Pandoc + 四套自包含模板） |
| 博客 URL / 本地 HTML 归档回源 | html→md | scripts/html_to_md.py（trafilatura + html-to-markdown） |
| 投稿、审校、纸书定稿 | md→精美 docx | scripts/md_to_docx.py（python-docx + 出版预设） |

能力 1 的 md 可以直接喂给能力 2（例如 PDF→阅读向 HTML）；能力 3 适合把已发布页面存回仓库；能力 4 是给人编辑的终点，专业流程默认要 DOCX，不要只交 HTML 或裸 md。

URL 分流很关键：内容是「查」的结构化页（文档、证书、商品）走能力 1，保留 metadata、链接和标题层级；内容是「读」的正文页（博客、新闻）走能力 3，自动去掉导航和侧栏。不确定时可以两路各跑一遍对比。

能力 2 默认是 兜底模式（--theme 选 article / report / reading / interactive，本地 Pandoc，不耗 token）；需要「按内容定制视觉」时再进可选的 设计师模式（读稿→推荐方向→定稿→实现）。所有 HTML 产出继承 huashu-design 底线：禁用紫渐变、深蓝底、emoji 当正式图标等，细则在 references/anti-ai-slop.md。

边界与注意

扫描 PDF 无 OCR，复杂表格、PPTX 动画排版会丢语义；markitdown 输出偏 LLM 消费，给人看还要再排版。
能力 3 不适合产品页/API 文档类 URL，会丢字段；这类应改用能力 1。
执行前应先对齐：能力编号、输入输出路径、HTML 模板、图片是相对路径还是嵌入、是否书籍级 docx——文档里强调 先问再做，避免猜错模板或引擎。
依赖 markitdown、Pandoc、html-to-markdown、python-docx；脚本会自检缺失项。macOS 上建议用 python3 -m pip，避免 pip 与 python3 版本不一致。