Anthropic 内部有一个观点正在流传：HTML 才是 AI 时代更好的输出格式，Markdown 该退场了。

说这话的是 Claude Code 团队成员 Thariq。他说他几乎所有东西都不再用 Markdown 了，需求文档、技术方案、代码审查报告，全部改用 Claude Code 生成 HTML。这篇文章在 X 上发出来之后，667 万次浏览，1 万个点赞。

初听起来有点怪，HTML 和 Markdown 不是压根不是一个赛道的东西吗？但把他的完整论证看下来，我觉得相当有说服力，甚至改变了我对"AI 该输出什么格式"这件事的看法。

Markdown 哪里不够用了？

Markdown 一直是 AI 的默认输出格式，理由很充分：简洁、便携、易读、易于人工编辑。Claude 甚至学会了用 ASCII 字符在 Markdown 里画各种图，表格、流程图，算是尽力了。

但 Thariq 指出了一个越来越明显的趋势：随着 Agent 越来越能干，Markdown 本身变成了瓶颈。

他提到了几个让他逐渐放弃 Markdown 的原因：

一是可读性。超过 100 行的 Markdown 文件，他基本不会认真读完。当 Claude Code 生成一个几百行的需求文档或实现计划时，他扫一眼开头就跳到结尾了。更别说让团队里其他人读，基本没戏。

二是编辑习惯变了。Markdown 的最大优势之一是"人类容易直接编辑"，但他现在对这些文件的操作，基本都是让 Claude 代劳，自己只看结果。这个优势就不存在了。

三是信息表达能力有天花板。想加颜色对比？ASCII 凑合。想做个交互式设计方案？做不到。想要真正的流程图而不是一堆短横线？要么插图片，要么将就。

这三点加在一起，让他开始重新思考：AI 时代，文件格式最重要的事情是什么？

为什么是 HTML？

他的回答是：信息密度。

作为前端开发者，你比任何人都清楚 HTML 能承载多少东西。Thariq 列了一张清单，HTML 可以表达的信息类型包括：

• 用 <table> 做真正的表格，有实际的行列结构

• 用 CSS 传递设计信息：颜色、字体、间距

• 用内联 SVG 画图表和示意图

• 用 <code> 配语法高亮展示代码片段

• 用 HTML + JavaScript + CSS 做交互元素，比如滑块、开关、下拉选择

• 用绝对定位和 Canvas 表达空间关系

• 用 <img> 嵌入图片

他的结论是：Claude 能读懂的几乎所有信息，都能用 HTML 高效表达。Markdown 只是其中一个极小的子集。

除了信息密度，他还提到了另外几个优势：

可读性。 HTML 文档可以做成真正好读的格式，tab 导航、可点击的链接、插图，甚至响应式布局。一个 HTML 报告和一个 100 行的 Markdown 文件，被人认真读完的概率差距很大。

分享。 Markdown 文件分享很麻烦，大多数浏览器不能直接渲染。HTML 丢到 S3 发一个链接，对方用浏览器直接打开。这个细节直接影响你的 spec 文档或 PR 说明有没有人看。

双向交互。 这是 Markdown 完全做不到的。HTML 里可以加滑块调整参数、加按钮导出配置，最后加一个"复制为提示词"按钮，把操作结果塞回 Claude Code 继续工作。文档变成了工具。

上下文整合。 用 Claude Code 生成 HTML 报告，可以把文件系统、MCP 工具（Slack、Linear 等）、Git 历史、浏览器里的内容全部整合进去。这是直接用 Claude.ai 对话做不到的。

几个实际用法

理论看完了，讲几个具体场景，对于前端/Node.js 开发者来说应该很有感触。

技术方案和需求文档

不再写 Markdown 的实现计划，而是让 Claude Code 生成 HTML 文件，里面有方案对比、代码片段、示意图，甚至组件 mockup。然后把这些 HTML 文件作为上下文，传给新 session 来实现。

示例提示词：

“

我不确定 onboarding 页面该往哪个方向走，给我生成 6 种完全不同的设计思路，布局、风格、信息密度都要有差异，用一个 HTML 文件并排展示，每种方案标注它在做的取舍。

代码审查

HTML 可以渲染真实的 diff，加行内注释，画模块关系图。他现在每次提 PR 都会附上一个 HTML 格式的代码说明，他说这通常比 GitHub 默认的 diff 视图好读，也更有可能被认真审查。

示例提示词：

“

帮我审这个 PR，生成一个 HTML artifact。我不熟悉 streaming/backpressure 的逻辑，重点讲那部分。渲染真实的 diff，用颜色区分问题严重程度。

设计原型

Claude Design 本身就是基于 HTML 的。你可以让 Claude 用 HTML 画出组件原型，再转成 React 代码。也可以加交互滑块，调动画曲线、颜色参数，最后加复制按钮，把满意的参数直接带走。

示例提示词：

“

我想做一个结账按钮，点击后播一段动画然后变紫色，用 HTML 做几个滑块让我调动画参数，加复制按钮把调好的参数输出来。

临时编辑界面

这个用法我觉得最有意思。有时候你很难用文字描述你要什么，可以让 Claude 临时做一个专用的 HTML 编辑器，目的只是用一次，最后加一个"导出 JSON"或"复制为提示词"的按钮把操作结果转回文本。

示例提示词：

“

我需要对 30 个工单重新排优先级，做一个 HTML 文件，把每张工单做成可拖拽的卡片，分 Now / Next / Later / Cut 四列，按你的判断预先排好，加一个"复制为 Markdown"按钮导出最终结果。

技术学习文档

这个 Thariq 也提到了，Claude Code 能读 Git 历史，综合多个数据源生成 HTML 报告。他举了一个例子，为了写一篇关于 prompt caching 的文章，他让 Claude Code 读完 Git 历史，生成一份详细的 HTML 研究文档给自己阅读。

示例提示词：

“

我不太理解我们的限流器是怎么工作的，读相关代码后生成一个 HTML 说明页：token-bucket 流程图、3-4 个关键代码片段加注释、底部加一个"坑"汇总。面向读一遍就能理解的人来写。

几个常见问题

这篇文章评论区问得比较多的问题，他也整理了：

HTML 不是消耗更多 token 吗？

是更多，但他认为更高的表达力带来的收益大于多出的 token 成本。Opus 4.7 有 100 万上下文窗口，多出那些 token 在实际使用中感受不到。

生成速度慢吗？

确实慢，大概是 Markdown 的 2-4 倍时间。他认为结果值得等，这个就见仁见智了。

版本控制怎么办？

他坦承这是最大的缺点：HTML 的 diff 很难看，也很难审查，远不如 Markdown 的 diff 干净。这个问题目前他没有好的解法。

怎么查看 HTML 文件？

直接用浏览器打开本地文件就行，或者上传到 S3 获取分享链接。Claude Code 也可以帮你直接打开。

真的要全面转向 HTML 吗？

Thariq 自己说他可能走到了"HTML 极端主义者"这一侧，普通用户不需要做到那么彻底。

我的看法是，他的核心论点站得住：在 AI 时代，"人类方便直接编辑"已经不再是文件格式最重要的特性了。我们越来越多地把这些文件当作 AI 读写的中间产物，而不是自己亲手维护的文档。在这个前提下，HTML 能承载的信息确实比 Markdown 丰富得多。

但全面放弃 Markdown 对大多数人来说既不现实也没必要。比较合理的做法是：复杂的、需要给人看的输出用 HTML；简单的内部草稿、快速记录用 Markdown。版本控制场景下 Markdown 依然更友好，这个短期内不会变。

如果你在用 Claude Code 开发，可以从代码审查这个场景开始试试 HTML 输出，因为 PR 说明这种东西，好不好读直接决定有没有人认真看。

他整理了一批示例文件放在这里： https://thariqs.github.io/html-effectiveness ，涵盖各种用途的 HTML 格式文档，可以直观感受一下效果，比看文字描述更有说服力。