AI 写文档，为什么突然开始嫌弃 Markdown？

这两天，AI 圈吵了一场挺有意思的架。

不是模型参数，也不是哪家公司又发了新模型，而是一个看起来特别“程序员”的问题：

AI 输出内容，到底应该用 Markdown，还是 HTML？

事情的导火索，是 Anthropic 工程负责人 Thariq Shihipar 写了一篇长文：《Using Claude Code: The Unreasonable Effectiveness of HTML》。

文章发布后很快刷屏。根据流传的数据，16 小时内有 440 万次浏览、8200 个点赞、15700 个书签，还在 Hacker News、Threads、LinkedIn 上引发了大量讨论。

乍一看，这像是一个格式之争。

但我越看越觉得，它其实不是在争 Markdown 和 HTML 谁更优雅，而是在争一件更底层的事：

我们到底把 AI 当成什么？

是一个陪你聊天、帮你写草稿的助手？

还是一个能整理知识、生成方案、交付结果的执行代理？

这两个答案不一样，输出格式就会完全不一样。

我以前几乎默认选 Markdown

作为程序员，我对 Markdown 是有感情的。

写 README，用 Markdown。

写技术方案，用 Markdown。

写公众号初稿，也经常是 Markdown。

它的好处太明显了：

• 简单
• 干净
• 任何编辑器都能打开
• 不渲染也能读
• Git 里看 diff 很舒服
• 喂给 LLM 也相对省 Token

对我这种经常在房车里换地方办公的人来说，Markdown 还有一个特别现实的优点：轻。

网络不稳定的时候，开一个文本文件就能继续写；工具链换来换去，它也不太会背叛你。

所以很长一段时间，我默认觉得：

AI 输出长文档，Markdown 就是最合理的格式。

直到最近我开始越来越频繁地用 AI 做“复杂任务”。

比如让它规划一个产品功能、审一段代码、整理一套运营方案、拆解一个自动化工作流。

这时候我发现一个问题：

Markdown 确实好编辑，但它不一定好阅读。

尤其当 AI 一口气输出几千字、上万字，里面有背景、方案、步骤、风险、检查清单、代码块、对比项……

你打开以后，常常不是“阅读”，而是“扫雷”。

HTML 派到底在说什么？

这次 Anthropic 那篇文章的核心观点，大概可以概括成一句话：

当 AI 输出越来越长、越来越复杂时，视觉结构比纯文本可编辑性更重要。

HTML 派认为，Markdown 有几个天然瓶颈。

比如超过 100 行后就开始不好浏览。

你当然可以加标题、列表、引用、代码块，但它本质上还是一条从上到下的长卷轴。

而 HTML 可以做很多 Markdown 做不到，或者做起来很别扭的事：

• 折叠章节
• 侧边目录
• 彩色标签
• 响应式布局
• 卡片式信息块
• 嵌入图表
• 风险项高亮
• 复杂信息分栏展示

这对于“人类快速 review”确实很有吸引力。

想象一下：你让 Claude Code 给你生成一个功能实现计划。

如果它输出 Markdown，你看到的是一份长文档。

如果它输出 HTML，你可能看到的是一个小型交互式页面：左边是目录，中间是任务拆解，右边是风险清单，重要步骤可以展开，代码片段有颜色，关键决策被标出来。

这时候 HTML 不再只是“网页格式”，而像是 AI 给你临时搭了一个工作台。

Anthropic 内部据说已经把 HTML 作为计划文档、代码审查、设计文档的默认格式。支持者甚至说，HTML 文档能让理解速度提升 40%。

这个说法不一定适用于所有场景，但它击中了一个真实变化：

AI 生成的东西，正在从“文本”变成“界面”。

Markdown 派为什么反应这么大？

但反对声音也非常强烈。

而且很多反驳，我觉得都很有道理。

首先是协作编辑问题。

Markdown 的美妙之处在于，谁都能改。

你在 VS Code 里改，我在 Obsidian 里改，别人甚至用系统自带文本编辑器也能改。

但 HTML 不一样。

渲染出来很好看，不代表源码好维护。

你打开一看，可能是 div 套 div、style 套 style，还有一堆 class 名和内联样式。对普通人来说，这不是文档，是装修现场。

第二个问题是 Token 浪费。

有些测试里，HTML 相比 Markdown 会多出大约 70% Token。对于 RAG、知识库、长期上下文来说，这不是小事。

尤其当你把文档再次喂给 LLM 时，HTML 标签会变成噪音。

同一份内容，如果用 Markdown，RAG 检索准确率可能是 85%；HTML 去标签后可能只有 68%；PDF 原始文本更惨，可能只有 52%。

这些数字未必能代表所有任务，但方向很清楚：

给人看，HTML 可能更舒服；给模型吃，Markdown 往往更干净。

第三个问题是安全。

Markdown 再怎么复杂，本质上还是文本。

但 HTML 一旦带上 JavaScript，就可能从“读文本”变成“运行代码”。

如果 AI 生成的 HTML 被直接打开、分享、嵌入系统里，就会出现 XSS、恶意脚本、数据泄漏等风险。

这也是很多老派工程师本能警惕的地方：

文档就应该是文档，不应该悄悄变成程序。

还有一个很现实的问题：慢。

生成 HTML 通常比生成 Markdown 更慢。有讨论里提到，复杂 HTML 输出可能慢 2 到 4 倍。

在一次性生成报告时，这点延迟可以接受。

但在高频交互里，每次都等一个精美网页，就有点像点外卖等摆盘。

好看是好看，饿的时候真没必要。

最有意思的是，有人吐槽：

这篇反对 Markdown 可读性的文章，本身就是一篇又长又复杂的 HTML。

这句话很损，但也很精准。

很多格式争论最后都会变成这样：你证明自己观点的方式，刚好暴露了它的边界。

llms.txt 的争议，其实也是同一个问题

同期还有一个相关讨论：llms.txt。

你可以把它理解成一个给 AI 看的 Markdown 索引文件，有点像 robots.txt，但目标读者不是搜索引擎爬虫，而是 LLM 或 AI Agent。

支持者认为，网站应该给 AI 准备一份更干净、更结构化的入口。

比如 API 文档原网页可能有 79000 token，但整理成 llms.txt 后，只需要 1800 token。对 coding agent 来说，这确实很省。

但反对者也很直接。

Google 的 John Mueller 说过类似观点：LLM 一直在处理正常 HTML，它们完全没问题，没必要搞只有机器人能看到的页面。

现实数据也比较冷静：即便有网站采用 llms.txt，目前也没有看到统计显著影响。

这场争论和 Markdown vs HTML 很像。

表面上是在争一种文件格式。

背后其实是在问：

我们要不要为 AI 单独设计一套内容基础设施？

如果 AI 只是偶尔来读一下，那没必要。

如果 AI Agent 未来会频繁读取、理解、调用、执行，那也许真的需要。

我的判断：不要选边站，先看这份内容的“下一站”

我现在比较认同的共识是：

面向第三方阅读、不需要修改的内容，HTML 更合适。

需要协作、需要进工具链、需要被 RAG 和 Agent 消费的内容，Markdown 更合适。

换句话说，不要问“Markdown 和 HTML 谁更好”。

要问：

这份内容的下一站在哪里？

如果下一站是人类阅读，比如汇报、展示、审阅、客户交付，那 HTML 的视觉层级很有价值。

如果下一站是 Git、知识库、RAG、自动化脚本、二次编辑，那 Markdown 的朴素反而是一种优势。

我自己现在会这样分：

• 思考阶段：Markdown
• 协作阶段：Markdown
• 知识库沉淀：Markdown
• Agent 输入上下文：Markdown
• 最终展示交付：HTML
• 复杂报告阅读：HTML
• 一次性 review 页面：HTML

这就像我们开房车旅行。

车上常用的东西，一定要轻、耐用、好修。

但到了某个地方，要给别人分享一路的故事，你当然可以做成更漂亮的相册、视频或者网页。

工具没有绝对优劣，只有使用场景。

真正变化的是：AI 的输出正在产品化

这场争论最有意思的地方，不是 HTML 赢了还是 Markdown 赢了。

而是它提醒我们：

AI 输出正在从“答案”变成“交付物”。

以前我们问 AI 一个问题，它回一段文字，像聊天记录。

现在我们让 AI 做一件事，它可能输出：

• 一份产品方案
• 一份代码审查报告
• 一个调研页面
• 一个执行计划
• 一组可运行脚本
• 一个可交互 dashboard

这时候，格式就不再是包装问题，而是工作流问题。

Markdown 代表的是可编辑、可追踪、可进入工具链。

HTML 代表的是可视化、可交付、可快速理解。

它们背后对应的是两种 AI 角色：

一种是助手，帮你写草稿。

一种是代理，帮你合成结果、呈现结果，甚至执行结果。

如果你把 AI 当助手，Markdown 很自然。

如果你把 AI 当代理，HTML 也许只是开始。

再往后，AI 输出的可能不是 Markdown，也不是 HTML，而是一个临时生成的 App、一个可操作的界面、一套自动执行的流程。

到那时，我们争论的可能就不是“文档格式”，而是“AI 应该把工作交付到哪个界面”。

给普通 AI 使用者的一个简单建议

如果你不是在做底层工具，只是日常用 AI，我建议先记住一个判断标准：

要改，用 Markdown。要看，用 HTML。要喂给 AI，用 Markdown。要交付给人，用 HTML。

这句话不严谨，但够实用。

比如：

你让 AI 写公众号初稿，用 Markdown。

你让 AI 整理会议纪要并长期归档，用 Markdown。

你让 AI 生成一份给客户看的调研报告，可以用 HTML。

你让 AI 生成代码审查结果，团队要继续讨论和修改，用 Markdown；只是给你快速扫一遍风险，用 HTML。

你要做 RAG 知识库，优先 Markdown。

你要做最终展示页，可以 HTML。

不要被格式的信仰绑架。

真正重要的是：这份内容能不能在你的工作流里顺畅流动。

最后

我挺喜欢这场争论。

它不像很多 AI 热点那样只是在比参数、比榜单、比谁发布会更炸。

它讨论的是一个很细、很具体，但又会影响我们每天使用 AI 的问题。

很多时候，生产力的差距不在于你用了哪个最强模型，而在于你有没有把输出接到正确的地方。

Markdown 和 HTML 的分歧，本质上不是格式审美的分歧。

它是在提醒我们：

AI 时代，内容不只是被写出来，还要被阅读、被检索、被协作、被执行。

所以格式不是小事。

它决定了 AI 生成的结果，是停留在聊天窗口里，还是能真正进入你的工作流。

而对一个想用 AI 做一人公司的普通人来说，这可能比又多会一个提示词，更重要。