Huashu Md Html

huashu-md-html

你不再需要亲手编辑产物。md 是源代码，html / docx 是产物。这个 skill 把多端的最优解打通成一条流水线。

四个能力（决策树）

决策原则：

• 能力1产出的md可以直接喂给能力2组成一条龙（如「PDF→精美阅读html」）
• 能力3用于反向归档（如「把已发布的html博客文章存回项目源」）
• 能力4是出版终点——给人类编辑/出版社审校时用 docx，不要直接给 html 或 md，专业出版生态默认 docx

URL 场景的进一步分流（2026-05 实测发现）

URL 输入时两条路径都能跑，但产出质量差异巨大。Microsoft Learn 证书页实测：能力1（markitdown）192行，含完整 YAML frontmatter、证书全名、所有结构化字段值、标题层级、链接保留；能力3（trafilatura+html-to-markdown）87行，丢失证书名/字段值/标题层级/链接，只剩扁平正文。

判断捷径：

URL 包含的内容是「读」的，还是「查」的？

读 → 能力3（去噪）

查 → 能力1（保信息）

核心审美底线（继承自 huashu-design）

这个skill产出的每一份html都必须符合花叔的审美底线。违反任一条都重做，不要交付。

详细规则见 references/anti-ai-slop.md。

Junior Designer 工作流

收到「转换/美化/导入」类任务时，不要直接执行。先问：

1. 能力是哪个？三选一（用决策树自检） 2. 来源/去向？文件路径 / URL / 字符串？输出到哪？ 3. 能力2专属问：模板选哪个？（article默认 / report / reading / interactive） 4. 特殊需求？（图片处理：保留相对路径 还是 base64嵌入？语言：中文版/英文版？）

回答清楚再动手。不要默认猜，错了用户返工成本远大于多问一句。

能力1：万物 → md（scripts/any_to_md.py）

封装 microsoft/markitdown v0.1.5+，一份Python脚本兼容20+种格式。

调用

# 基本：自动按扩展名识别
python scripts/any_to_md.py input.pdf
python scripts/any_to_md.py input.docx -o output.md
python scripts/any_to_md.py "https://www.youtube.com/watch?v=xxx"

# 结构化网页/产品页/技术文档（保留 metadata + 标题层级 + 链接）
python scripts/any_to_md.py "https://learn.microsoft.com/en-us/credentials/certifications/modern-desktop/" -o cert.md

# 启用LLM图片描述（需要OPENAI_API_KEY环境变量）
python scripts/any_to_md.py photo.jpg --llm-describe

支持的格式

PDF、DOCX、PPTX、XLSX、XLS、HTML、CSV、JSON、XML、图片（EXIF/可选LLM描述）、音频（可选语音转写）、YouTube URL（自动抓字幕）、普通网页URL（带 YAML frontmatter）、EPub、ZIP（递归解包）、Outlook邮件（.msg）。

已知坑（写在脚本输出里提醒用户）

• 扫描PDF不做OCR，需要挂LLM client或Azure Doc Intelligence
• 复杂表格（合并单元格/嵌套）会丢失语义
• PPTX只保留文本+备注，动画排版完全丢
• 输出为LLM消费设计，给人读还要再过一道排版

依赖：pip install 'markitdown[all]'（自动检测，缺失时提示安装）。

完整cookbook见 references/markitdown-cookbook.md。

能力2：md → 精美html（scripts/md_to_html.py）

封装 Pandoc + 4套精挑模板，覆盖花叔写作场景全部需求。

调用

# 默认：article模板（Tufte风，适合essay/博客）
python scripts/md_to_html.py article.md

# 选模板
python scripts/md_to_html.py report.md --theme report      # 宽体多表格，适合技术报告/白皮书
python scripts/md_to_html.py article.md --theme reading    # Medium极简，适合公众号转接
python scripts/md_to_html.py book.md --theme interactive   # 折叠目录+SVG图，适合长文/橙皮书

# 输出位置
python scripts/md_to_html.py input.md -o out.html

# 图片处理
python scripts/md_to_html.py input.md --inline-images      # base64嵌入（自包含单文件）
python scripts/md_to_html.py input.md --copy-images        # 拷贝到output目录（默认保持相对路径）

4套模板速览

每个模板都是自包含单CSS，HTML打开即可用，不依赖外部CDN。

依赖

• brew install pandoc（必装，二进制）
• 脚本启动时自动检查which pandoc，缺失则提示安装命令

完整cookbook见 references/md-to-html-themes.md。

两种模式 · 兜底 vs 视觉设计师

能力 2 有两条路径——

兜底模式跑 pandoc 二进制，5 秒出结果，全程不联网不耗 token——这是默认行为。 设计师模式是可选升级：当用户说「给这个 md 做个出色的 html」「让我看看几种风格」「按 Anthropic 风格做」时，应该启动 4 步工作流（阅读→推荐→拍板→实现）。

完整方法论 + 流派池 + 评审清单见 references/visual-designer-mode.md。 参考实现：examples/readme.html——用设计师模式 · 方向 C（Anthropic 暖色科技）做的活样本。

能力3：html → md（scripts/html_to_md.py）

封装 html-to-markdown（Rust底层，150-280MB/s）+ trafilatura（URL场景的正文提取）。

最适合的场景：博客文章、新闻报道、Essay、公众号长文——任何「正文是产品、其他都是噪声」的页面。能力3 会扔掉导航/侧栏/相关推荐/广告，只留正文。

不适合的场景：产品页、技术文档、API doc、电商商品页这类结构化页面——能力3 会丢字段值/链接/层级。这种走能力1（markitdown）。

调用

# 本地HTML文件（直接走 html-to-markdown）
python scripts/html_to_md.py input.html

# 博客/新闻URL（自动跑trafilatura提取正文，去除导航/广告/侧栏）
python scripts/html_to_md.py "https://example.com/article"

# URL但你想要原始HTML不要正文提取
python scripts/html_to_md.py "https://example.com/data" --no-extract

# 精细控制
python scripts/html_to_md.py input.html --bullets="-" --heading-style=atx --strip="script,style,nav,footer"

# 输出
python scripts/html_to_md.py input.html -o output.md

引擎选择

依赖：pip install html-to-markdown trafilatura markdownify。

完整cookbook见 references/html-to-md-cookbook.md。

能力4：md → 精美docx（scripts/md_to_docx.py）

封装 python-docx + 出版社级排版预设，专为「给人类编辑/出版社审校/投稿/纸质书定稿」场景设计。

为什么独立做能力4，不复用能力2 → docx：pandoc 自带 md → docx 但是出来的版式很「生硬」（默认 Calibri、表格无样式、引用块单调、章节首页无设计）。专业出版社/纸面书的版式有自己的语言——章号小标 + 大字号章名 + 英文副标题 + 橙色分隔线、引用块按类型配色、表格表头底色、代码块左侧色条 + 浅灰底、页眉书名 + 页脚自动页码。能力4 把这些预设都内置了，单文件或一整本书都能一条命令生成。

调用

# 单 md 文件 → docx（默认从 md 同级目录找图片）
python3 scripts/md_to_docx.py article.md
python3 scripts/md_to_docx.py article.md -o article.docx
python3 scripts/md_to_docx.py article.md --images-dir ./images

# 多 md 文件合并（普通模式，不加封面/目录）
python3 scripts/md_to_docx.py ch01.md ch02.md ch03.md -o combined.docx

# 完整书模式（自动加封面 + 目录 + 页眉页脚 + 章节分页）
python3 scripts/md_to_docx.py ch*.md postscript.md appendix.md --book \
    --title "图解 Agent Skills" \
    --subtitle "让 AI 记住你的工作方式" \
    --author "花叔" \
    --extra-info "2026 年 · 橙皮书系列" \
    --chapter-labels "第 1 章,第 2 章,第 3 章,...,后记,附录" \
    --images-dir ./images \
    -o book.docx

# 页面规格切换
python3 scripts/md_to_docx.py article.md --page-size a4   # A4 报告
python3 scripts/md_to_docx.py book.md --page-size book    # 大 32 开（默认，纸质书规格）

内置排版预设

图片自动嵌入

支持两种 md 图片语法：

# 内联式：相对路径或绝对路径
![图说](images/cover.png)

# 引用式（适合长书）：在文末定义路径
![图 1-1 · 数据曲线][fig-1-1]

[fig-1-1]: images/ch01-fig01.png "数据曲线 · 女娲37天1.8万star"

引用式还支持「按 ref 名约定路径」——如果 ref 是 fig-1-1 形态但没有定义对应路径，会自动到 --images-dir 找 ch01-fig01.png。这个约定让长书（很多章节、几十张图）写起来不用手动维护引用映射。

依赖

python3 -m pip install python-docx Pillow

脚本启动时自动检测，缺失时给出明确安装命令。

完整 cookbook 见 references/md-to-docx-cookbook.md。

排版底线（所有模板共享）

详见 references/design-tokens.md，关键参数：

正文字体（中文）  PingFang SC, Source Han Serif, Noto Serif CJK
正文字体（英文）  Inter, IBM Plex Sans, et-book
代码字体         JetBrains Mono, Fira Code
行高（中文）     1.75 - 1.85
行高（英文）     1.6
字号（桌面）     17 - 18px
字号（移动）     16px
最大宽度（文章）  680 - 720px
最大宽度（报告）  760 - 820px
段间距           1em - 1.2em
代码块底色       #F6F8FA（浅模式）/ #1F2428（深模式）
引用块           左4px色条 + 浅灰底
标题层级         h1 2em / h2 1.6em / h3 1.3em

禁用清单：紫渐变、赛博霓虹、#0D1117深蓝底、Comic Sans、emoji作正式图标。

一条龙工作流（典型场景）

# 场景1：PDF白皮书 → 精美阅读html
python scripts/any_to_md.py whitepaper.pdf -o whitepaper.md
python scripts/md_to_html.py whitepaper.md --theme report -o whitepaper.html

# 场景2：YouTube视频 → 文章博客
python scripts/any_to_md.py "https://youtube.com/watch?v=xxx" -o video.md
# 编辑video.md...
python scripts/md_to_html.py video.md --theme article -o blog.html

# 场景3：归档已发布的博客文章 → 项目源文件（能力3）
python scripts/html_to_md.py "https://example.com/blog/article" -o article.md

# 场景4：抓产品页/技术文档 → 完整结构化md（能力1）
python scripts/any_to_md.py "https://learn.microsoft.com/en-us/some-doc" -o doc.md

# 场景5：橙皮书章节 → 多模板对比
python scripts/md_to_html.py chapter.md --theme article -o ch-article.html
python scripts/md_to_html.py chapter.md --theme interactive -o ch-interactive.html
# 浏览器对比，选效果好的

# 场景6：URL不确定走哪条路 → 两个都跑对比
python scripts/any_to_md.py "https://example.com/page" -o page-markitdown.md
python scripts/html_to_md.py "https://example.com/page" -o page-trafilatura.md
# 看哪个对你下游用途更合适

# 场景7：整本橙皮书 md → 出版社审校 docx（能力4）
python scripts/md_to_docx.py md-v2/ch*.md md-v2/postscript.md md-v2/appendix.md --book \
    --title "图解 Agent Skills" \
    --subtitle "让 AI 记住你的工作方式" \
    --author "花叔" \
    --images-dir ./images-v2 \
    -o 图解Agent-Skills_出版社审校版.docx
# 158 页 · 9 章 + 后记 + 附录 + 57 张配图 · 直接给出版社编辑审

# 场景8：从 PDF 论文/报告 → docx 投稿（能力1 → 能力4）
python scripts/any_to_md.py paper.pdf -o paper.md
# 编辑 paper.md 修正格式...
python scripts/md_to_docx.py paper.md --page-size a4 -o paper.docx

异常处理

References路由

核心提醒

• 四个能力各有边界：能力1输入端、能力2 html输出、能力3反向归档、能力4 docx 出版终点。决策错了会绕远路。
• md是源，无论从哪来要回到哪——md是这个流水线的中心。
• html产出必反slop：紫渐变、emoji图标、SVG画人物——一律不要。审美底线见 references/anti-ai-slop.md。
• URL输入双路径：结构化页面用能力1（保metadata+层级+链接），博客类用能力3（去导航+只留正文）。判断捷径——内容是「读的」走3，是「查的」走1。
• docx 是给人的，不是给 LLM 的：给出版社/编辑/投稿系统就用能力4。能力2 的 html 适合自己看、网上分享，不适合编辑改稿。
• Junior先问，再做：模板选哪个、图片要不要嵌入、是否要LLM描述图片、单文件还是书籍模式——一次问清，不要边做边猜。
• 依赖外部工具：markitdown（pip）、pandoc（brew）、html-to-markdown（pip）、python-docx（pip）。脚本启动时自检，缺失明确提示。
• Python环境陷阱：macOS 上 pip 和 python3 可能指向不同 Python 版本（实测踩过：pip 是 3.11、python3 是 3.14）。安装依赖必须用 python3 -m pip install ...，不要直接 pip install。

AI时代的编程语言：md生产，html消费

前几天我在X上扔了条想法：自然语言是这个时代真正重要的编程语言，md是这个时代最好的编程文件。

[待补图：花叔5月7日X帖截图]

写这条的时候我有点自嘲。我那两个一万多star的开源项目，最重要的文件都是md。但只是因为里面还有一些python或html脚本，GitHub就把它们标成了Python项目和HTML项目。

我觉得GitHub的分类系统已经没跟上时代了。

差不多同一周，Anthropic Claude Code团队的Thariq发了篇文章，标题挺猛：HTML是新的markdown。他说他几乎不再写markdown文件了，转而让Claude Code给他生成HTML。

[待补图：Thariq文章首页截图 https://thariqs.github.io/html-effectiveness/]

Thariq的文章我看了，写得挺好。但看完之后我意识到一件事：他说对了一半。

HTML没有取代markdown。markdown跑到了另一端，登顶了。

md早就是这个时代的代码了

我去年某天写过一句话：最好的编程语言就该是自然语言。

那时候说这话还有点理想化的味道。一年多过去，事情确实在朝这个方向走。

[待补图：花叔即刻动态截图 - 「最好的编程语言就该是自然语言」]

去年8月，OpenAI发布了一个东西叫AGENTS.md。就是一份md文件，写在项目根目录，告诉AI agent这个项目的规则、约定、要做什么不要做什么。听起来像配置文件。

但它扩散得吓人。到现在被60000多个开源项目采用。Cursor、Codex、Devin、Claude Code、Gemini CLI、GitHub Copilot都支持。

到去年12月，Linux Foundation成立了Agentic AI Foundation，把AGENTS.md捐进去做开放标准。白金成员里有AWS、Anthropic、Google、Microsoft、OpenAI，基本是AI半壁江山。

一份md文件被Linux Foundation标准化了。这事我觉得挺有象征意义的。

Karpathy的影响力更直接。今年4月他把自己的llm-wiki gist开源出来，是一个用来管理个人知识库的项目。核心架构是三层md文件：raw/存原始资料，wiki/存LLM生成的md知识，CLAUDE.md存schema和规则。

这个gist几天涨到5000多star，CLAUDE.md那个文件本身，就一个文件，单日涨了7900个star，目前接近5万。

一个markdown文件，5万star。

Karpathy自己解释为什么用md：「Future-proof，vendor-neutral，人和机器都能读。哪天Obsidian挂了，文件还能被任何文本编辑器打开。」

这个理由挺简单的，但你想想，能同时满足「人能读、AI能读、可以diff、可以版本控制、可以grep、不绑定厂商」的格式，目前确实只有md。

Cloudflare做过一个实测，一篇普通博客HTML格式16180个token，转成md只要3150个token。80%的token压缩。换算成实际成本，同样的预算可以处理7到17倍的请求。

GitHub官方博客今年发了一篇叫spec-driven development，里面有句话我读到的时候停了一下：

「文档不再是描述代码，文档就是代码。自然语言被编译成更低级的语言，那些更低级的语言长得像Python或JavaScript而已。」

Visual Studio Magazine把md形容得更准：在agentic AI里，markdown是「一个稳定的、可审计的控制界面，用来定义AI的行为」。

AI在Skill、CLAUDE.md、AGENTS.md、cursor rules里能跑出来什么，全看你md怎么写的。

md不再只是一种文件格式。它是这个时代的源代码。

但html在消费端确实赢了

Thariq说他不再写md了，这个判断如果限定在「让AI生成给我看的产物」上，我同意。

我自己的工作流早就是这样了。

我做的几个项目网站，比如ppt.huasheng.ai、ds.bookai.top、ds.huasheng.ai，存放的所有内容都是html。每次让AI帮我做一个解释器、一个对比工具、一个可交互的演示，最后产出的都是html文件。

我把它们丢到S3、Cloudflare、自己的服务器上，扔一个链接出去就完事了。

如果让我把这些东西用md输出我会疯。md承载不了我要的东西。

Thariq说的几条理由我都同意，挑两个我感受最深的。

第一个是空间信息。diff、调用图、架构图、流程图这些东西天然有空间维度，md把它们压扁成一行行的字。同样一份代码diff，让AI画成左右对照的html页面，配上行内annotation和颜色区分，理解效率根本不在一个量级。

第二个是动态体验。我做产品原型的时候，经常需要让AI生成一个带动画的mock。比如一个按钮按下去转什么颜色、用什么easing曲线、过渡多久。这种东西你用文字描述再多都没用，得真的看一眼才能判断。

我之前做小猫补光灯的UI迭代，就是让AI生成html原型版本，每个按钮的反应直接跑一遍，看着选。那种感觉跟看md里写一句「这里建议加一个圆角动画」完全不一样。

[待补图：花叔做的某个html原型或解释器截图]

Anthropic今年4月推了Live Artifacts，让HTML从静态产物升级成了「持久化、可交互、能拉实时数据的dashboard」。我看到这个功能上线的时候挺兴奋的，因为它把html消费端的能力又往前推了一截。

老牌AI实践者Simon Willison最近也写了篇文章，承认自己被Thariq说服了。他说GPT-4那个年代他养成了「什么都让AI输出md」的习惯，因为8192个token的上下文不允许浪费。

但现在他改主意了：「我准备多试试用html格式让AI解释复杂概念了，特别是带SVG图表和交互组件的版本。」

这种立场翻转挺有意思的。它说明事情确实在变。

真正有意思的是这两件事其实是一件事

我在这里停了一下。

如果md在生产端越来越重要，html在消费端越来越重要，那这两件事是不是其实是同一件事？

我觉得是。

这是一个分工的形成。

以前md和html是有过论战的。10年代是HTML的时代，blog、文档、官网都用HTML写。后来md兴起，因为写起来快、看起来干净、能纯文本编辑。技术圈基本切到了md。

那个论战的隐含前提是：生产者和消费者是同一个人。 你写一份文档自己看，或者写给同事看。不管哪种，写的人和读的人都是人，都是同一类用户。

所以选格式要折中，既要好写，又要好看。md胜出，因为它的折中点最舒服。

AI出现之后，第一次出现了一个新情况：生产成本可以被AI吸收。

你不再需要亲手编辑产物。HTML因为太重而被嫌弃的那部分代价，由AI承担了。你只承担消费。

这意味着原来要折中的需求被解耦成了两端的极端最优。

生产端要的是轻、是快、是可diff、是token-efficient。那就是md。

消费端要的是丰富、是可视化、是可交互、是好分享。那就是html。

两端各自登顶。中间的那个折中位置，没人需要了。

[待补图：md→html分工概念图 - 抽象的源代码到产物的流转可视化]

最干净的活体证据可能是Karpathy和Lex Fridman那对组合。

Karpathy的llm-wiki，内核是markdown wiki，所有原始资料、概念页、索引都是md。据VentureBeat等媒体的报道，Lex Fridman用了同款架构，但在外面加了一层，让AI生成动态html+JavaScript，可以排序、过滤、调参、做交互可视化。

内核md，外壳html。

不是Lex替换了Karpathy，是他在Karpathy的基础上加了消费层。这两层各做各的事，不冲突，互相加强。

我看到这个组合的时候挺兴奋。因为这就是「md生产，html消费」在现实里跑通的样子。

我自己的活样本：橙皮书

聊到这里其实我应该坦白一件事——我已经在用这个分工干活很久了，只是直到看Thariq文章那一刻才反应过来。

橙皮书系列我做了7本，全部免费上架微信读书。Claude Code从入门到精通、Claude Code源码解析、Harness Engineering、Agent Skills、OpenClaw、Polymarket、Hermes Agent，加起来读者已经过百万。

[待补图：橙皮书系列封面合集]

经常有人问我同一个问题：你的橙皮书排版怎么这么好看？比一般的电子书强太多了。

我以前回答得比较随意，说就是用了点设计技巧。现在回头看，真正的答案是这个分工。

写每一本橙皮书的时候，我让AI产出的从来都是md。一章一章的md文件，简单的标题层级，行内代码块，普通的无序列表。我review的时候改的也是md，加一句话、删一段话、调一下逻辑。

到了构建环节，我有一个build脚本。md转成html章节片段，html再编译成epub和pdf。

所有的字体选择、颜色搭配、版面设计、章节装饰、代码高亮，全在html到epub/pdf这一层做。

[待补图：橙皮书构建流程图：md源 → html fragments → epub/pdf]

这意味着我review内容的时候面对的是md，没有视觉干扰，能专心看文字。AI再生成内容的时候面对的也是md，token efficient，能塞下整本书的上下文。

但读者拿到的是漂亮的epub或pdf，HTML的所有表达力都用上了。

这个分工不是我刻意设计的。一开始我也试过让AI直接产html，发现两个问题。

一是改起来烦，一个段落里塞着各种tag，肉眼分辨不出哪是内容哪是格式。二是上下文炸，一个章节就要几千token，AI没办法一次看完整本书的脉络。

后来切换成md转html再转pdf，问题都消失了。回头看，这就是「生产端用md、消费端用html」自然演化出来的结果。

公众号文章我也是这么走的。写作用md，过editor.huasheng.ai排版变成微信富文本，最后发到公众号。我review的永远是md源文件，读者看到的是排好版的内容。

我做的md-to-pdf skill、整套写作系统、整个橙皮书工作流，本质上都是这一个分工的物化。

只是我一直不知道这个分工值得被命名。

边界

需要补一句：这个分工不是万能的。

不是所有内容都需要html消费。文章本身就是文字消费——你现在读的这篇就是。md够了，转成微信图文也够了。再丰富的html对一篇散文式文章没什么帮助。

短消息、推特、即时沟通、纯文字阅读，html都过重。

适合html消费的是「复杂结构信息」：研究报告、技术解释、设计文档、可交互原型、数据dashboard、需要折叠和导航的长文档、需要试参数的playground。这些场景md承载不动。

适合md消费的还是「线性文字阅读」：essay、文章、书籍正文、新闻报道。这些场景html是过度设计。

判断哪边的方法挺简单的：你需要的是看一段连续的字，还是看一个有空间结构的东西？

命名

调研的时候我让agent去搜了一遍，2024年之前没有人清晰地说过「md生产，html消费」这件事。

倒是有人说过markdown好，有人说过HTML的优点，有人争过两者的取舍。但把它们当作一对分工的论述，目前没看到。

那就叫这个名字吧。

md生产，html消费。

这个分工不是我们造出来的，是AI让它显形的。

以前你又是写者又是读者，所以你需要一个折中的格式。

现在你不写产物了，你只读它。AI替你写。

写者和读者第一次是两个人。一个是AI，一个是你。

两个人，自然要用不同的语言。

<div align="center">

huashu-md-html

「md 是源代码，html / docx 是产物。」

  

<br>

md/html/docx 多向流水线 · 四个能力一站式：万物 → md · md → 精美 html · html → md · md → 出版社级 docx

<br>

把任意文件（PDF / DOCX / PPTX / XLSX / EPUB / 图片 / 音频 / YouTube / 网页 URL）转成干净的 markdown，再用 4 套精挑过的主题加工成出色的 html，或反过来把已发布的 html 拉回来归档成 md。需要给出版社/编辑/投稿系统时——一条命令把 md 加工成出版社级 docx，自动嵌图、加封面、做目录、配页眉页脚。

每个能力都封装成一个命令，每套主题都过了反 AI slop 检查清单——没有紫渐变、没有 emoji 当图标、没有 #0D1117 深蓝底，配色克制，有出版社品位。

npx skills add alchaincyf/huashu-md-html

跨 agent 通用——Claude Code、Cursor、Codex、OpenClaw、Hermes 都能装。

看效果 · 装上就能用 · 四个能力 · 4 套 html 主题 · 一条龙工作流

</div>

---

Demo

<p align="center"> <img src="demos/v3-hara-hero.gif" alt="huashu-md-html Hero · md 是源，html 是产物" width="100%"> </p>

<p align="center">_{▲ 20 秒 · Kenya Hara 极简风格 · md → 入·排·出 → html · 衬线 + 留白 + 一抹赤陶橙<br> 👉 <a href="demos/v3-hara-hero.mp4">下载 MP4（含 BGM · 850KB）</a>}</p>

<details> <summary>另一版风格预览（点开看 Pentagram 信息建筑派 · 18 秒）</summary>

<p align="center"> <img src="demos/v1-pentagram.gif" alt="huashu-md-html · Pentagram 风格" width="100%"> </p>

<p align="center">_{▲ Pentagram 信息建筑派 · 象牙白 + 墨黑 + 辛辣红 · 大字号 sans + 12 列网格 + tabular nums<br> 👉 <a href="demos/v1-pentagram.mp4">下载 MP4（含 BGM · 2MB）</a>}</p>

</details>

📌 以上两段动画都是用 [huashu-design](https://github.com/alchaincyf/huashu-design) skill 做的——作为本 skill 的宣传短片。 同一个产品，两种视觉哲学，差异不来自模板而来自设计语言。

---

装上就能用

npx skills add alchaincyf/huashu-md-html

然后在 Claude Code 里直接说话：

「这个 PDF 转成 md」
「把这篇 md 做成精美 html，用 article 主题」
「这个博客 URL 转回 md，去掉导航和侧栏」
「把这份 PPTX 转成 md，再用 reading 主题做成发布版」
「把这些章节 md 做成一份出版社可审校的 docx」
「这份稿子做成投稿用的 word，A4 规格」

没有按钮、没有面板、没有 GUI。

---

四个能力

决策原则：

• 能力 1 产出的 md 可以直接喂给能力 2，组成「PDF → 精美阅读 html」一条龙
• 能力 3 用于反向归档（把已发布的 html 拉回项目源）
• 能力 4 是出版终点——给人类编辑/出版社审校时用 docx，不要直接给 html 或 md，专业出版生态默认 docx

URL 输入的两条路径

URL 既能走能力 1（markitdown）也能走能力 3（trafilatura），但产出质量差异巨大：

判断捷径：URL 里的内容是「读」的还是「查」的？读 → 能力 3（去噪），查 → 能力 1（保信息）。

---

4 套 html 主题

每套都过了反 AI slop 检查清单。自包含单 CSS，HTML 打开即用，不依赖外部 CDN。

<table> <tr> <td width="50%"><img src="examples/output/article.png" alt="article 主题预览"><br>_{<b>article</b> · Tufte 风 · 衬线 + 边距笔记}</td> <td width="50%"><img src="examples/output/report.png" alt="report 主题预览"><br>_{<b>report</b> · 白皮书风 · 宽体多表格}</td> </tr> <tr> <td width="50%"><img src="examples/output/reading.png" alt="reading 主题预览"><br>_{<b>reading</b> · Medium 风 · 单栏极简}</td> <td width="50%"><img src="examples/output/interactive.png" alt="interactive 主题预览"><br>_{<b>interactive</b> · 长文档 · 侧边栏 + 折叠目录}</td> </tr> </table>

排版底线（所有主题共享）

正文字体（中文）  PingFang SC, Source Han Serif, Noto Serif CJK
正文字体（英文）  Inter, IBM Plex Sans, et-book
代码字体         JetBrains Mono, Fira Code
行高（中文）     1.75 - 1.85
行高（英文）     1.6
字号（桌面）     17 - 18px
最大宽度（文章）  680 - 720px
最大宽度（报告）  760 - 820px
代码块底色       #F6F8FA（浅模式）/ #1F2428（深模式）
引用块           左 4px 色条 + 浅灰底

禁用清单：紫渐变、赛博霓虹、#0D1117 深蓝底、Comic Sans、emoji 作正式图标。

---

md → 出版社级 docx

为什么单独做能力 4？因为 pandoc md -o docx 出来的 docx 默认 Calibri、无表格样式、无封面、章节首页平淡——能给 AI 看，不能给出版社编辑改稿。

能力 4 的脚本内置了出版社版式预设：

# 单文件转换
python3 scripts/md_to_docx.py article.md

# 整本书（自动加封面 + 目录 + 页眉 + 章节分页）
python3 scripts/md_to_docx.py ch*.md postscript.md appendix.md --book \
    --title "图解 Agent Skills" \
    --subtitle "让 AI 记住你的工作方式" \
    --author "花叔" \
    --images-dir ./images \
    -o book.docx

版式特性：

实战验证：用这个脚本生成《图解 Agent Skills》158 页出版社审校稿（9 章 + 后记 + 附录 + 57 张配图），一条命令搞定。

完整 cookbook 见 `references/md-to-docx-cookbook.md`。

依赖：python3 -m pip install python-docx Pillow

---

一条龙工作流

# 场景 1：PDF 白皮书 → 精美阅读 html
python3 scripts/any_to_md.py whitepaper.pdf -o whitepaper.md
python3 scripts/md_to_html.py whitepaper.md --theme report -o whitepaper.html

# 场景 2：YouTube 视频 → 文章博客
python3 scripts/any_to_md.py "https://youtube.com/watch?v=xxx" -o video.md
# 编辑 video.md...
python3 scripts/md_to_html.py video.md --theme article -o blog.html

# 场景 3：归档已发布的博客文章 → 项目源 md
python3 scripts/html_to_md.py "https://example.com/blog/article" -o article.md

# 场景 4：抓产品页 / 技术文档 → 完整结构化 md
python3 scripts/any_to_md.py "https://learn.microsoft.com/en-us/some-doc" -o doc.md

# 场景 5：橙皮书章节 → 多主题对比
python3 scripts/md_to_html.py chapter.md --theme article -o ch-article.html
python3 scripts/md_to_html.py chapter.md --theme interactive -o ch-interactive.html

# 场景 6：URL 不确定走哪条路 → 两个都跑对比
python3 scripts/any_to_md.py "https://example.com/page" -o page-markitdown.md
python3 scripts/html_to_md.py "https://example.com/page" -o page-trafilatura.md

# 场景 7：整本书 md → 出版社审校 docx
python3 scripts/md_to_docx.py md-v2/ch*.md md-v2/postscript.md md-v2/appendix.md --book \
    --title "图解 Agent Skills" --author "花叔" --subtitle "让 AI 记住你的工作方式" \
    --images-dir ./images-v2 -o 出版社审校版.docx

# 场景 8：PDF 论文 → docx 投稿（能力 1 → 能力 4）
python3 scripts/any_to_md.py paper.pdf -o paper.md
# 编辑 paper.md 修正格式...
python3 scripts/md_to_docx.py paper.md --page-size a4 -o paper.docx

---

依赖

脚本启动时会自检，缺失的依赖会明确提示安装命令，不会静默失败。

⚠️ macOS Python 环境陷阱：pip 和 python3 可能指向不同的 Python 版本（实测踩过：pip 是 3.11、python3 是 3.14）。安装依赖请用 python3 -m pip install ...，不要直接 pip install。

---

仓库结构

huashu-md-html/
├── SKILL.md                 # Agent 主文档（中文）
├── README.md                # 本文件
├── scripts/                 # 四能力入口
│   ├── any_to_md.py         # 能力 1：万物 → md
│   ├── md_to_html.py        # 能力 2：md → 精美 html
│   ├── html_to_md.py        # 能力 3：html → md
│   └── md_to_docx.py        # 能力 4：md → 出版社级 docx
├── templates/               # 4 套精挑 html 主题 + 公众号专用
│   ├── article/             # Tufte 风
│   ├── report/              # 白皮书风
│   ├── reading/             # Medium 极简
│   ├── interactive/         # 长文档导航
│   └── wechat/              # 公众号转接
├── references/              # 按任务深入文档（中文）
│   ├── markitdown-cookbook.md
│   ├── md-to-html-themes.md
│   ├── html-to-md-cookbook.md
│   ├── md-to-docx-cookbook.md     # ⭐ 新增：md → docx 完整指南
│   ├── design-tokens.md
│   └── anti-ai-slop.md
├── examples/                # 主题预览
│   ├── input/md-vs-html.md
│   └── output/{article,report,reading,interactive}.{html,png}
├── demos/                   # README 引用的宣传动画
│   ├── v3-hara-hero.{gif,mp4}     # Kenya Hara 极简
│   └── v1-pentagram.{gif,mp4}      # Pentagram 信息建筑
└── requirements.txt

---

设计哲学

这个 skill 的存在源于一个简单观察：AI 时代，文档的「生产格式」和「消费格式」第一次解耦了。

写作发生在 markdown——可 diff、AI 友好、版本可控。 分发发生在 html——排版精致、可分享、可导航。 来回切换不应该有成本。

大多数「转 X 到 Y」工具优化的是「转换保真度」。这个 skill 优化的是写作者的循环：

• 一份 md 是源——所有创作和编辑都在 md 里
• 多套 html 是产物——按场景挑主题，渲染一份精美的 html
• 来回往返不丢结构——把已发布的博客拉回项目源，或者把别人的好内容归档成 md

继承自 huashu-design 的反 AI slop 审美底线——4 套主题各有一个克制的强调色和一个出版级的排印签名，看起来像出版社做的，不像 SaaS 落地页。

---

License

MIT License — 个人和商业使用均自由，无需授权。

如果这个 skill 对你有帮助，欢迎 star 仓库；如果你做了有意思的衍生作品（新主题、新格式支持），欢迎 PR。

---

联系花叔（Huasheng）

花叔是 AI Native Coder、独立开发者、AI 自媒体博主。代表作：小猫补光灯（App Store 付费榜 Top 1）、《一本书玩转 DeepSeek》、nuwa-skill（GitHub 21k+ stars）、huashu-design。全平台累计粉丝 30 万+。

商业合作、内容定制、咨询，请发邮件到 alchaincyf@gmail.com 或私信任一社交平台。

反 AI slop — huashu-md-html 的审美底线

这是从 huashu-design 继承并适配到「文档场景」的反slop清单。每一条违反都是品牌识别度的稀释。

什么是 AI slop？

AI slop = AI 训练语料里最常见的"视觉最大公约数"。

紫渐变、emoji 图标、圆角卡片+左 border accent、SVG 画人物、深蓝底——这些东西不是因为它们丑，而是因为它们是 AI 默认模式下的产物，不携带任何品牌信息。

文档场景的 AI slop 就是：每个 AI 工具的默认 markdown 渲染器都长得一样——白底、Helvetica、淡蓝链接、emoji 当 list 标记、紫色系统消息。用户读到这种页面，认不出谁的作品。

文档场景的 7 条硬禁令

1. 紫色渐变 background 永远不要

例外：用户明确要求紫渐变（罕见），或品牌本身就用（Linear 某些场景）。

2. Emoji 作为系统图标永远不要

❌ 这种排版：

✨ **核心要点**
🔥 **关键发现**
💡 **思考**
⚡️ **行动项**

✅ 这样：

**核心要点**
**关键发现**
**思考**
**行动项**

或用细微的字体样式（小型大写、斜体）做语义区分。

emoji 作为内容（文章里偶尔出现一个 ☕️ 表达情绪）OK；emoji 作为结构性图标永远不要。

3. 圆角卡片 + 左 border accent 烂大街组合

❌ 这种 callout：

.callout {
  border-radius: 12px;
  border-left: 4px solid #blue;
  background: #f0f4ff;
  padding: 16px;
  box-shadow: 0 2px 4px rgba(0,0,0,0.05);
}

是 2020-2024 Material/Tailwind 时期产物，已经成了视觉噪音。

✅ 用这种代替：

• 简单的 <blockquote> 配上极简风（左侧 3px 实线，无阴影）
• 不同 callout 类型用字体级差区分（小标题用 small-caps）
• 或者干脆用细的水平分隔线代替框

我们 4 套模板里的 blockquote 都遵守这条。

4. 深蓝底 #0D1117 永远不要

GitHub dark mode 美学的烂大街复制。所有 AI 生成的 dark theme 默认都是这个色——撞衫到名字都一样。

✅ 用这些：

• #15181f（report dark）— 中性偏冷
• #1c1a16（article dark）— 暖中性
• #15130f（reading dark）— 更暖
• #1a1916（interactive dark）— 中性偏暖

每个都和 #0D1117 不同，但都是"低饱和、暗调中性"。

5. 赛博霓虹（neon-green/cyan/magenta on black）

属于游戏UI风，不是阅读体验。

6. Inter / Roboto / Arial 大字号 display

不是说不能用 Inter（report 模板就用了 Inter 做 body），是说：

❌ 正文用 Inter，标题也用 Inter → 看不出"有设计"还是"demo页"

✅ 正文 Inter / 标题用 serif 或不同字重的 sans → 字体级差是设计

我们的 4 套模板都遵守这条：要么标题/正文不同字族，要么不同字重 + 不同字号倍数 + 不同字距。

7. SVG 画人物/物体 imagery

AI 画的 SVG 人物永远五官错位、比例诡异。文档场景里基本不需要画人物——但万一遇到要"配图"：

✅ 顺序： 1. 用真图（Wikimedia/Met/Unsplash/AI生成图片如 nano-banana-pro） 2. 用 placeholder 灰块 + 文字标签（"产品图待补"） 3. 删掉这个图位

❌ 永远不要：

• 用 SVG 手画一个简笔画人
• 用 emoji 大字号代替 illustration
• 用纯色块 + Bezier 曲线"暗示"图

5 条软原则（情境判断）

8. 一处 120%，其他 80%

文档里一定要有一个值得截图的细节签名：

• article 的 hr 用 30% 宽细线
• report 的 KPI grid 数字大字号 + 极细 grid 线
• reading 的 hr 用 "· · ·" 三点居中
• interactive 的 sidebar TOC 上面有"目录"小型大写标签

每套模板都有自己的"那一处"。不要每个地方都精致——会变成均匀平淡。

9. 配色用 spec 里已有的

不要凭空发明色。每套模板的 theme.css 顶部有 CSS 变量定义所有色——所有自定义元素也只能从这些变量取色。

❌ 突然加一个 color: #333 — 不在 spec 里 ✅ color: var(--color-ink) — 用 spec

10. 链接颜色不要太抢戏

文档场景里链接很多。如果每个链接都鲜艳一下，整页就花了。

✅ reading 模板的处理：链接颜色用 ink（=正文色），下划线用 accent — 既能识别又不抢戏 ✅ article/report/interactive：链接用 accent 但稍微调暗 + 极细下划线

❌ 不要：bright blue + bold

11. 阴影克制

文档不需要阴影。表格不需要阴影。引用块不需要阴影。代码块不需要阴影。

唯一可能的阴影场景：图片的极细投影（box-shadow: 0 1px 2px rgba(0,0,0,0.04)）让图片"贴在纸上"。

不要堆叠阴影、模糊半径>10px的阴影、彩色阴影。

12. 装饰性 icon 永远不需要

文档里看到这种：

🚀 **能力**：超快速度
✨ **特性**：非常优秀
🎯 **目标**：很重要

每个标题都配 emoji，是"不够专业就用 emoji 凑"的病。

我们 4 套模板的 SKILL.md 里都没有装饰性 emoji（除了 SKILL.md frontmatter 的触发词列表）。

反例隔离（演示反 slop 时）

如果你的文档就是要演示什么是 slop（比如本文档），不要让整页变 slop。用诚实的 bad-sample 容器隔离：

<div class="bad-sample">
  <span class="bad-tag">反例 · 不要这样做</span>
  <!-- 反例内容 -->
</div>

.bad-sample {
  border: 1px dashed var(--color-rule-strong);
  padding: 1em;
  margin: 1em 0;
  position: relative;
  opacity: 0.7;
}
.bad-tag {
  position: absolute;
  top: -0.6em;
  left: 1em;
  font-size: 0.75em;
  background: var(--color-paper);
  padding: 0 0.4em;
  color: var(--color-ink-mute);
}

这种容器明确告诉读者"这是反例"，反例服务于叙事而不是污染主调。

检查表（每次输出 html 前过一遍）

• [ ] 没有紫渐变
• [ ] 没有 emoji 作系统图标
• [ ] 没有圆角卡片+左 border 烂组合
• [ ] dark mode 底色不是 #0D1117
• [ ] 没有霓虹色
• [ ] 标题/正文不是同一个 sans 字体
• [ ] 没有 SVG 手画人物
• [ ] 链接不抢戏
• [ ] 阴影克制（≤1层，blur ≤ 4px）
• [ ] 没有装饰性 emoji
• [ ] 配色全部用 CSS 变量（不凭空发明色）
• [ ] 至少有一处 "120% 细节"

与 huashu-design 的关系

huashu-design 是设计哲学的源头（含 20 种风格、设计方向顾问、品牌资产协议、动画/演示/原型守则）。

huashu-md-html 是它在"文档场景"的窄域应用：

• 不做品牌资产协议（文档场景用户极少传 logo/产品图）
• 不做设计方向顾问（用 4 套预定义模板替代）
• 反 AI slop 哲学完整继承
• 排版底线完整继承

如果你做的是动画/原型/演示/品牌设计——回到 huashu-design。

如果你做的是文档/报告/文章/书籍——用本 skill。

design tokens — 排版底线（4套模板共享）

这是 huashu-md-html 所有模板必须遵守的视觉底线。每个 theme.css 都基于这套 token 设计，但有自己的 accent 和气质偏好。

字体堆栈

中文字（serif，文学/出版气质）

--font-serif-zh: "Source Han Serif SC", "Songti SC", "Noto Serif CJK SC", "Source Han Serif", serif;

article / reading / interactive 用这个。

中文字（sans，技术/报告气质）

--font-sans-zh: "PingFang SC", "Hiragino Sans GB", "Microsoft YaHei", sans-serif;

report 用这个。

英文字（serif，editorial）

--font-serif-en: "et-book", "Source Serif Pro", "Iowan Old Style", "Palatino Linotype", Georgia, serif;

article 用这个（et-book 是 Tufte CSS 的字体）。

英文字（serif，reading-focused）

--font-body-en: "Charter", "Iowan Old Style", "Apple Garamond", Georgia, serif;

reading 用这个（Charter 是 macOS 内置阅读字体）。

英文字（sans）

--font-sans-en: "Inter", "IBM Plex Sans", -apple-system, BlinkMacSystemFont, "Helvetica Neue", sans-serif;

report / interactive 的正文用这个。

代码字

--font-mono: "JetBrains Mono", "SF Mono", "Fira Code", "IBM Plex Mono", Menlo, Consolas, monospace;

所有模板共用。JetBrains Mono 字体设计针对代码可读性优化，连字（ligatures）开启。

字号

设置在 html { font-size: ... } 上，所有 em 单位自动缩放。

行高

中文需要更大的行高，因为字符更密；英文1.6就够。我们都偏向中文文档，用1.7-1.85区间。

最大宽度

为什么是这些值：

• 单栏阅读黄金宽度是 60-75 个英文字符宽（约 30-40 个中文字符）
• 720px @ 17px 字号 ≈ 42 个中文字符 / 65 个英文字符——舒适区间
• 报告需要塞表格，所以放宽到820px
• reading 故意做窄到 680px，强迫沉浸

颜色

article — 赤陶橙 + 象牙白

--color-paper: #fffaf3;     /* 暖底 */
--color-ink: #1a1a1a;
--color-accent: #b04a1a;    /* terracotta */

report — 墨水蓝 + 纯白

--color-paper: #ffffff;
--color-ink: #14181f;
--color-accent: #1f4ea8;    /* ink blue */

reading — 暖橙 + 暖米

--color-paper: #fbfaf7;
--color-ink: #2a2a2a;
--color-accent: #c75a30;    /* warm orange */

interactive — 森林绿 + 米白

--color-paper: #fbfaf6;
--color-ink: #1f201d;
--color-accent: #2c5e3f;    /* forest green */

暗色模式

每套模板都有 @media (prefers-color-scheme: dark) 切换。

暗模式底色禁用：

• ❌ #0D1117（GitHub dark）— AI slop 之王
• ❌ #000000 纯黑 — 对比度太硬
• ❌ #1a1a2e 紫调暗 — 廉价游戏UI感

暗模式底色用：

• ✅ #15-1c 区间的暖中性色（带2-5度色温）
• ✅ 配合稍微调亮的 accent（避免深底配深 accent）

间距节奏

--rhythm: 1em - 1.6em;

段落间距用 em，让字号缩放时间距按比例变化。

标题层级

中文排版细节

标点挤压（Optical kerning）

未来浏览器会原生支持 text-spacing-trim，目前各模板都用了：

text-wrap: pretty;           /* 智能换行（避免悬挂标点）*/
hanging-punctuation: first allow-end last;  /* 标点悬挂 */

引号

花叔偏好「」，所有模板的字体stack都包含能正确渲染「」的中文字体（思源宋/PingFang）。

中英文之间

不加空格（盘古之白禁用）。这是花叔明确写过的偏好。

<p>md是这个时代的源代码。</p>
<!-- 不写成： <p>md 是这个时代的源代码。</p> -->

数字与字母

数字用 font-variant-numeric: oldstyle-nums 让数字与中文字体协调（article 模板）； 表格里用 tabular-nums lining-nums 让数字对齐（report 模板）。

特殊元素

代码块底色

浅模式：#F6F8FA 系（Apple-像素灰）/ #F4EEDD（暖象牙）/ #F0ECE3（reading暖底）
深模式：#1F2428（中性）/ #25221C（暖深）/ #2A2C25（更暖）

不要 #0D1117。

引用块

border-left: 3-4px solid var(--color-accent);
background: var(--color-paper-soft);
font-style: italic;

不要：背景渐变、左border + 圆角卡片、emoji icon 装饰。

表格

• thead 顶部 2px 黑线（出版社标志）
• thead 底部 1px
• tbody 行底 1px 浅灰
• 末行 2px 黑线
• 数字列右对齐（<td class="num">）

黑名单（所有模板永不使用）

加新模板的清单

1. templates/<name>/theme.css — 复用上面的 CSS 变量结构 2. 选定 accent（一个，不超过两个） 3. 行高、最大宽度、字号确定 4. 暗模式底色避开禁用清单 5. 在 scripts/md_to_html.py 的 VALID_THEMES 加上名字 6. 在 references/md-to-html-themes.md 加哲学说明 7. 用本项目"md生产html消费"的草稿做端到端测试，截图对比其他模板

最后那一步是质量保证——能跟现有4套放一起不打架，才说明设计成立。

html→md cookbook — 三种场景下的工具选择

这个 cookbook 是能力3（html→md）的实战参考。脚本 scripts/html_to_md.py 包装了下面的引擎选择逻辑。

引擎概览

安装

pip install html-to-markdown trafilatura markdownify

三种典型场景

场景1：本地 HTML 文件（已清洁）

python scripts/html_to_md.py article.html -o article.md

默认引擎 html-to-markdown。返回的 markdown 已经过自动 HTML 净化（去script/style）。

适合：保存好的网页、已经清洗过的HTML、邮件HTML、导出的飞书/Notion HTML。

场景2：野生 URL（带噪声）

python scripts/html_to_md.py "https://example.com/article" -o article.md

脚本自动启动 trafilatura.fetch_url + extract，提取主体内容（去nav/aside/footer/广告），再喂给 html-to-markdown。

适合：博客文章、新闻报道、技术文档、官方公告。

何时跳过 trafilatura：

# 不要正文提取，保留全部HTML
python scripts/html_to_md.py "https://example.com/data" --no-extract

适合：已经是"纯内容"页面（如GitHub raw、自己控制的HTML、API返回的clean HTML）。

场景3：精细控制输出格式

python scripts/html_to_md.py article.html \
  --engine markdownify \
  --heading-style=atx \
  --bullets="-" \
  --strip="script,style,nav,footer,aside,iframe,form" \
  -o article.md

markdownify 的可配置项：

适合：要把转换结果喂回花生的写作系统，或后续要被审校agent检查的md。

输出结构

html-to-markdown 引擎的返回是结构化的：

from html_to_markdown import convert
result = convert(html)

result.content        # markdown正文（脚本输出的就是这个）
result.metadata       # 字典，含title/links/headings
result.tables         # 结构化表格列表
result.images         # 图片引用列表
result.warnings       # 转换警告

如果需要metadata（比如批量抓取），可以直接调用底层API（不通过本脚本）。

引擎对比示例

输入：

<h1>Hello</h1>
<p>This is a <strong>test</strong>.</p>
<ul><li>One</li><li>Two</li></ul>

html-to-markdown 输出：

# Hello

This is a **test**.

* One
* Two

markdownify --bullets="-" --heading-style=atx 输出：

# Hello

This is a **test**.

- One
- Two

风格差别在 bullets 字符上。生产环境推荐统一用 -。

中文页面常见问题

编码问题

URL 抓取时如果出现乱码：

# 默认 User-Agent + utf-8 解码（脚本已实现）
# 如果对方服务器用 GBK/GB2312：
python scripts/html_to_md.py "https://example.cn/page" --user-agent "Mozilla/5.0"
# 然后用 iconv 重编码（如必要）

段落合并

trafilatura 的默认提取模式可能合并段落。如果你需要保留每个 <p> 的独立性：

# 修改 scripts/html_to_md.py 的 trafilatura_extract 函数
trafilatura.extract(html, output_format='html', favor_recall=True)

favor_recall=True 会保留更多结构，代价是带回更多噪声。

URL 抓取的反爬虫

某些网站（公众号/知乎/小红书）会反爬。本skill不内置反爬绕过——硬性原则：

• 不绕过 paywall
• 不绕过反爬虫机制
• 不爬需要登录才能看的内容

如果你需要这类内容，建议：

1. 浏览器手动打开 → 复制源HTML → 保存本地 → 用本skill的本地HTML分支 2. 用 agent-browser skill（基于 Playwright）真正打开页面再提取

何时降级到 markitdown 的 HTML 转换

markitdown 也支持HTML输入（能力1）。两者区别：

简单说：单文件HTML/URL → 能力3；多格式混合包 → 能力1。

工作流闭环

# 把已发布的公众号文章存回项目源
python scripts/html_to_md.py "https://mp.weixin.qq.com/s/xxx" -o archive.md
# 重新编辑 archive.md，再走能力2 输出新版本
python scripts/md_to_html.py archive.md --theme article -o new.html

# 把朋友发的网页链接转成 md 笔记
python scripts/html_to_md.py "https://blog.example.com/article" -o note.md

markitdown cookbook — 各文件类型的转换最佳实践

这个 cookbook 是能力1（万物→md）的实战参考。脚本 scripts/any_to_md.py 包装了下面所有用法。

安装

# 推荐：一次到位
pip install 'markitdown[all]'

# 可选 extras（按需选）
# pdf docx pptx xlsx xls outlook audio-transcription youtube-transcription az-doc-intel
pip install 'markitdown[pdf,docx,pptx,xlsx]'

需要 Python ≥ 3.10。

各类型 cookbook

PDF

python scripts/any_to_md.py file.pdf -o out.md

适用场景：原生PDF（含可选文本层）。

坑与降级：

• 扫描PDF（图片PDF）→ 默认输出几乎为空，必须挂 LLM 或 Azure Document Intelligence
• 复杂表格（合并单元格、嵌套）→ 单元格语义可能丢失
• 带图表/图片的PDF → 图片不会被OCR，只保留文件名

降级路径：

# 挂 LLM 描述图片（要 OPENAI_API_KEY）
python scripts/any_to_md.py file.pdf --llm-describe

# 挂 Azure Document Intelligence（高保真扫描件）
python scripts/any_to_md.py file.pdf \
  --azure-doc-intel "https://xxx.cognitiveservices.azure.com/"

DOCX

python scripts/any_to_md.py document.docx -o out.md

质量：对纯文本/标准排版的Word文档接近无损。Heading 1/2/3 能正确映射成 # ## ###。

坑：

• 文本框、SmartArt、复杂浮动布局 → 会被扁平化或丢失
• 修订标记、批注 → 默认不保留
• 嵌入的图片 → 提取出文件名占位，不内嵌

PPTX

python scripts/any_to_md.py deck.pptx -o out.md

输出结构：每张幻灯片 = 一个 ## Slide N 段落，包含文字 + speaker notes。

坑：

• 动画、过渡、布局完全丢失
• 图表数据丢失（只保留chart的标题）
• 用作"AI消化PPT内容"OK，用作"还原幻灯片"则不够

XLSX / XLS

python scripts/any_to_md.py spreadsheet.xlsx -o out.md

输出：每个worksheet 转成 markdown table。

坑：

• 公式不会被evaluate，只看cell的当前值
• 合并单元格 → 拆开
• 数据透视表、图表 → 丢失

替代：复杂Excel分析用 xlsx skill 或 pandas 直接处理，这里只用于"提取干净文本喂AI"。

HTML

python scripts/any_to_md.py page.html -o out.md

质量：对简单HTML（带article/section/p/h1-6/ul/ol）很好。复杂页面（带nav/aside/广告）会保留所有HTML结构产生噪声。

推荐：HTML转md优先用能力3（html_to_md.py），它有 trafilatura 做正文提取，自动去噪。

图片（jpg/png/gif）

# 不挂LLM：只提取EXIF和文件名
python scripts/any_to_md.py photo.jpg

# 挂LLM：让模型描述图片内容
python scripts/any_to_md.py photo.jpg --llm-describe

需要 OPENAI_API_KEY 和 pip install openai。

音频（mp3/wav/m4a）

# 需要先装 audio-transcription extra
pip install 'markitdown[audio-transcription]'

python scripts/any_to_md.py recording.mp3 -o transcript.md

底层用 pydub + speech_recognition，离线可用，但准确度随音质变化大。

替代方案：花叔的工作流里更高质量的方案是 huashu-subtitle skill（豆包Audio API），准确度更高，特别是中文长音频。

YouTube URL

# 需要先装 youtube-transcription extra
pip install 'markitdown[youtube-transcription]'

python scripts/any_to_md.py "https://www.youtube.com/watch?v=xxx" -o video.md

会自动抓取YouTube字幕（如有）。没有字幕的视频会失败，需要降级到 gemini-video skill。

EPub

python scripts/any_to_md.py book.epub -o book.md

按章节切分输出，每章一个 H1/H2。封面图、文内插图丢失。

ZIP

python scripts/any_to_md.py archive.zip -o archive.md

行为：递归解包，每个内部文件按其类型转md，按目录结构组织。

Outlook .msg

pip install 'markitdown[outlook]'
python scripts/any_to_md.py email.msg -o email.md

提取主题/发件人/收件人/正文/附件名。附件本身不会被转换。

一条龙工作流

# PDF白皮书 → md → 精美阅读html
python scripts/any_to_md.py whitepaper.pdf -o wp.md
python scripts/md_to_html.py wp.md --theme report -o wp.html

# YouTube视频 → md脚本 → 文章博客
python scripts/any_to_md.py "https://youtube.com/watch?v=xxx" -o talk.md
# 编辑 talk.md，改写成文章...
python scripts/md_to_html.py talk.md --theme article -o blog.html

何时不用 markitdown

已知的版本变化

• v0.1.5（2026-02-20）：内存内转换、PDF表格对齐改善、插件架构开放
• v0.1.x 之前：表格还原差，建议升级到最新

# 检查当前版本
pip show markitdown | grep Version

# 升级
pip install -U 'markitdown[all]'