HTML is the new Markdown：来自 Claude Code 团队的实践

AI Agent 火起来之后，凭借着简单、轻量、方便编辑，Markdown 一直都是 Agent 输出计划、说明和文档的默认格式。但上周五 Anthropic 工程师 Thariq Shihipar 提出，HTML 可能正在成为新的 Markdown。原因并不是 HTML 更"酷炫"，而是它能把代码说明、PR review、设计原型、报告、交互式编辑器等内容组织成更容易阅读和操作的页面，让人更好地参与到 Agent 的工作过程中，而不是只看一大段文本输出。

其他人怎么看 HTML is the new Markdown

这个观点一经发表，在社媒 X 上引发了不少讨论。大家的关注重点，并不是「HTML 要不要彻底取代 Markdown」，而是：在 AI Agent 工作流里，Markdown 和 HTML 到底应该分别承担什么角色。

比较保守的观点来自开发者 Somya 。他认为，HTML 很适合用来做原型、mockup、测试和预览，但如果内容主要是文字，比如代码、计划和文档，Markdown 仍然更合适。简单说，他的判断是：图和交互多，用 HTML；文字多，用 Markdown。 不过 Thariq 本人在回复里并不同意，他认为这些文字密集型场景，HTML 也同样更好。

日本开发者 Kenn Ejima 的看法更接近对原文观点的延伸。他指出，如果人们本来就不打算直接手动编辑这些内容，那么 Markdown「作为纯文本也方便人类读写」的优势就没有那么重要了。真正的瓶颈变成了人的认知负担：几百行文本很快就会超过阅读极限。HTML 则可以通过 CSS 和视觉结构提高信息密度，让内容更适合被普通用户阅读。他也补充，Markdown 在 token 效率上依然有优势，因此更像是 AI 和开发者之间的中间语言，而 HTML 更像是面向用户的展示层。

Nicolas Bustamante 则给了一个实践层面的反馈。他把 Thariq 的文章做成了一个交互式 HTML，并提到自己以前是 Markdown 用户，但加入 Microsoft 之后越来越多使用 HTML。他观察到，工程师也喜欢用 AI 生成的 HTML 在 SWE 和 PM 之间同步项目，因为它比 Markdown 更容易读。Nicolas Bustamante 目前就职 Microsoft，公开资料显示他参与 Word、Excel、PowerPoint 等产品里的 agentic AI 体验开发。

Simon Willison 也从开发者视角做了尝试。他让 AI 用 HTML 解释一个经过混淆的 Python PoC，并认为这种「用 HTML 解释复杂东西」的方式很不错。Simon Willison 是 Django Web Framework 的共同创建者，也是 Datasette 和 LLM CLI 的创建者。

整体来看，大家的分歧并不在于 HTML 是否有价值，而在于它是应该替代 Markdown，还是和 Markdown 分工协作。一个更稳妥的理解是：Markdown 依然适合作为简洁、可编辑、token 友好的工作底稿；HTML 更适合作为面向人类阅读、展示、交互和团队协作的输出层。

这也让 Thariq 的观点更准确地落在 AI Agent 工作流上：未来的文档可能不再只有一种格式，而是 Markdown 负责沉淀思路，HTML 负责让复杂信息真正被看懂、被操作。

下文根据原文观点整理，保留了作者的第一人称视角，以及他的主要论证和示例。下文并非逐字翻译，想要百分百阅读他的观点，请阅读 Thariq Shihipar 的原文。

HTML 正在变成新的 Markdown

Markdown 已经成为 Agent 和我们沟通时最常用的文件格式。它简单、可移植，也有一定的富文本能力，加上你要编辑的话也很方便。Claude 已经很擅长在 Markdown 里用 ASCII 画图了。

但随着 Agent 变得越来越强，我开始觉得 Markdown 反而成了一种限制。超过一百行的 Markdown 文件，我读起来就会觉得吃力。我想要更丰富的可视化、更好的颜色和图表，也希望这些内容能更方便地分享出去。而且，我现在越来越少亲自编辑这些 Markdown 文件。它们更多时候是规格说明、参考资料、头脑风暴的产物，就算真的要改，我通常也是让 Claude 去改。这样一来，Markdown 最大的优势之一------方便人手动编辑------就没那么重要了。

所以，我开始更偏向让 Claude 输出 HTML，而不是 Markdown。不只是我，Claude Code 团队里这样做的人也越来越多。

如果你想先看一些例子，可以去这里看一组 HTML 示例：https://thariqs.github.io/html-effectiveness

下面来说说为什么 HTML 是更好的格式：

为什么是 HTML？

信息密度

相比 Markdown，HTML 能承载的信息丰富得多。它可以做标题、段落、格式这些基础文档结构，还可以表达很多其他东西，比如：

用 table 展示表格数据；
用 CSS 表达设计信息；
用 SVG 画插图；
用 script 标签放代码片段；
用 HTML 元素、JavaScript 和 CSS 做交互；
用 SVG 和 HTML 表达工作流；
用绝对定位和 canvas 表达空间信息；
用 img 标签嵌入图片。

只要是 Claude 能读懂的信息，几乎都可以用 HTML 相当高效地表达出来。

这让 HTML 成为一种很高效的沟通方式：模型可以用它向你传达更深入的信息，你也能更容易地阅读和检查信息。

如果不能这么做，模型在 Markdown 里就可能会用一些效率更低的方式，比如 ASCII 图。我很喜欢这个例子：它会用 Unicode 字符来"估算"颜色。下面是 Claude Code 里出现过这种颜色信息：

视觉清晰和易读

随着 Claude 能做的工作越来越复杂，它写出来的规格说明和计划也越来越长。

实际使用下来，我发现自己通常不会认真读超过 100 行的 Markdown 文件，更别提组织里的其他人会去读了。

但 HTML 文档会好读很多。Claude 可以用更适合浏览的方式组织结构，比如 tab、插图、链接等等。它甚至可以做成响应式页面，让你在不同设备上以不同方式阅读。

易分享

Markdown 文件其实不太好分享，因为大多数浏览器并不能很好地原生渲染 Markdown。你经常只能把它作为邮件或消息的附件发出去。

但 HTML 不一样。只要把文件上传到某个地方，比如 S3，你就可以直接分享链接。你的同事可以在任何地方打开，也更容易引用里面的内容。

这样 HTML 格式的规格说明、报告或者 PR 说明，别人真的去读它的概率会高很多。

双向交互

HTML 还可以让你和文档本身产生交互。比如，你可以让 Claude 给文档加一些滑块或者旋钮，用来调整设计参数；或是修改算法里的不同选项，看看会发生什么。甚至让它加一个按钮，把你调整后的结果复制成 prompt，再粘回 Claude Code 里。

如果想看这种双向交互的例子，可以看我之前关于 playground 的帖子：https://x.com/trq212/status/2017024445244924382

长上下文

为什么要用 Claude Code 来生成 HTML，而不是用 Claude.ai 或 Claude Design？一个很重要的原因是：Claude Code 能吃进很多上下文。

比如，写这篇文章时，我让 Claude Code 读了我的代码文件夹，找出我之前生成过的所有 HTML 文件，把它们分组、分类，然后再生成一个 HTML 文件，用图表展示每一类。你在这篇文章里看到的这些图，就是这么来的。

除了文件系统，Claude Code 还可以通过 MCP 获取更多上下文，比如 Slack、Linear 等；也可以通过 Claude in Chrome 读浏览器里的信息，还可以看你的 git 历史等等。

有意思的 HTML

用 Claude 做 HTML 文档，就是更好玩。它会让我感觉自己更参与其中，也更愿意投入到这个创作过程里。光这一点，对我来说就已经足够了。

HTML 怎么用？

我有点担心大家看完这篇文章之后，会把它做成一个 /html skill 之类的东西。当然这可能有价值，但我想强调的是：你其实不需要做太多额外准备，就能让 Claude 开始这么做。

你只要直接说： "帮我生成一个 HTML 文件" 。

真正的关键不是某个固定技能，而是你要知道：你希望这个文件用来做什么，以及你打算怎么用它。

以后你也许会慢慢沉淀出一个 skill，但现在我建议先从零开始 prompt，多试几种场景，先熟悉它到底适合怎么用。

使用场景

为了让这件事更具体，我做过很多不同用途的 HTML 文件。你可以在这里看到全部示例：https://thariqs.github.io/html-effectiveness/

下面是一些概览。

规格说明、计划和探索

HTML 是一个很丰富的画布，适合让 Claude 深入处理一个问题。当我开始处理一个问题时，现在不再期待它只给我一个简单的 Markdown 计划，而是会期待它生成一组 HTML 文件。比如，我可能会先让 Claude Code 做头脑风暴，探索几个不同方案。然后我会让它在某一个方案上继续展开，可能做一些 mockup，或者写一些代码片段。最后，当我觉得方向差不多了，再让它写实现计划。等我对计划满意后，我会开一个新 session，把这些文件一起喂进去，让它开始实现。

做验证时，我也会让负责验证的 Agent 读这些文件。这样它就能拥有更完整的上下文，知道真正需要检查些什么。