HTML为何碾压Markdown？AI时代新选择

本文来自Anthropic官方博客，作者Thariq Shihipar是 Anthropic 的技术人员，Claude Code 团队成员。这篇文章深入探讨了为什么以及如何使用 HTML 替代 Markdown 作为 Claude Code 的输出格式，以生成更丰富、更易读、更易分享的结果。

核心观点

Thariq Shihipar 的核心观点可以概括为：随着 AI 代理能力的飞速提升，Markdown 已经越来越不够用，HTML 才是更好的输出格式，它能带来更高的信息密度、更好的阅读体验和更流畅的协作闭环。

1. 信息密度碾压 Markdown

HTML 不仅能做标题、列表、加粗这类基础排版，还能嵌入表格、CSS 样式、SVG 插图、代码片段、交互组件甚至完整的 JavaScript 应用。几乎任何 Claude 能理解的信息，HTML 都能高效呈现。相比之下，Markdown 只能靠 ASCII 画图或用 Unicode 字符模拟颜色，又丑又低效。

2. 可视化让阅读效率翻倍

超过 100 行的 Markdown 文件很少有人能读完，但 HTML 可以设计标签页、流程图、响应式布局，让读者一眼看清架构和重点。配上色彩、图标和交互式导航，阅读意愿和消化速度都大幅提升。

3. 交互式文档打造协作闭环

HTML 可以添加滑块、按钮、拖拽卡片等交互元素，让用户直接微调参数、重新排序、复制结果并反馈给 Claude。这种"AI 生成 → 用户调整 → 导出给 AI"的紧密循环，比纯文本对话框高效得多，也让人更愿意参与其中。

以下为全文翻译

Markdown 已经成为 AI 代理与人类沟通时最主流的文件格式。它简单、可移植、具备一定的富文本能力，也容易编辑。Claude 甚至已经相当擅长在 Markdown 文件里用 ASCII 字符画图表。

但随着 AI 代理变得越来越强大，我越来越觉得 Markdown 是一种限制重重的格式。具体来说，我发现超过一百行的 Markdown 文件就很难读下去了；我希望用 Claude 生成更丰富的可视化、色彩和图表；我还希望这些输出能更容易被分享。

此外，我现在几乎不自己编辑这些文件了------我把它们当作规格说明书和参考资料。即便需要修改，我通常也是让 Claude 来改，这样一来 Markdown 的最大优势之一（方便人手动编辑）也就没了。

于是，我开始偏好用 HTML 代替 Markdown 作为输出格式，并且越来越多地看到 Claude Code 团队的其他人也在采用这种做法。在这篇文章里，我会分享我们的团队为什么以及如何使用 HTML 来生成更丰富、更易读的 Claude Code 输出。如果你想跟着做，也可以直接使用我们为常见场景准备的 HTML 文件模板。

为什么用 HTML？

有几样特质让 HTML 比 Markdown 更适合我现在用 Claude Code 做的工作------尤其是那些需要或涉及以下内容的任务：

信息密度

相比 Markdown，HTML 能承载丰富得多的信息。它当然能做标题、格式化这类简单的文档结构，但它还能表现各种其他信息：

用表格展示数据
用 CSS 做设计
用 SVG 画插图
用 script 标签嵌入代码
用 JavaScript + CSS 做交互
用 SVG 和 HTML 设计工作流
用绝对定位和 Canvas 呈现空间数据
用图片标签插入图像

在我看来，几乎没有任何一组 Claude 能读的信息是你不能用 HTML 有效表达的。这使得 HTML 成为模型向你传达深度信息、以及你审查这些信息时非常高效的方式。

我发现，如果不用 HTML，模型可能会在 Markdown 里做更低效的事，比如 ASCII 图表，或者我最喜欢的------用 Unicode 字符来模拟颜色。

视觉清晰与易读性

Claude 能处理的任务越来越复杂，它生成的规格说明和计划也越来越长。我发现，超过一百行的 Markdown 文件我根本不会去读，更不用说让我团队里的其他人去读了。

但 HTML 文档读起来轻松得多，因为 Claude 可以在视觉结构上做优化------用标签页、插图和链接来导航，甚至可以做到移动端响应式，让你根据设备采用不同的阅读方式。

易于分享

Markdown 文件很难直接分享，因为大多数浏览器不支持原生渲染。你通常得把它们作为附件加到邮件或消息里。

只要上传了 HTML 文件，分享链接就很简单。同事可以在任何地方打开它，并且轻松引用。如果你的规格说明、报告或 PR 评述是用 HTML 写的，被阅读的概率会高得多。

双向交互

HTML 还能让你与文档互动。例如，你可以让 Claude 添加滑块或旋钮来调整设计，或者允许你调整算法里的不同选项以观察效果。你还可以让它提供"复制这些更改到提示词"的功能，方便粘贴回 Claude Code。

当需要时，这能让你为当前特定问题创建专属的编辑环境。

数据导入

比起 Claude.ai 或 Claude Design，用 Claude Code 生成 HTML 文件的最大原因之一，是 Claude Code 能消化大量上下文。例如，写这篇文章时，我让 Claude Code 读取我的代码文件夹，找到所有我生成的 HTML 文件，分组归类，然后用图表制作一个代表每种类型的 HTML 文件。你在这篇文章里看到的图表就是直接这么得来的。

除了文件系统，Claude Code 还能通过你的 MCP（如 Slack、Linear 等）、你的浏览器（搭配 Chrome 里的 Claude）以及你的 git 历史来获取更多上下文。

快速上手

有一点值得注意：你不需要做太多准备工作就能让 Claude 生成这样的 HTML。你只需提示它"生成一个 HTML 文件"或"做一个 HTML artifact"。关键是你想让它做什么、你怎么用它。随着时间推移，你可能需要针对常见的模式建立一套"技能"，但从零开始用提示词驱动是感受它在不同场景下工作原理的好方法。

使用场景

为了让这个思路更具体，下面是一些我认为用 HTML 文件比 Markdown 更有意义的示例场景。你也可以在 GitHub 上查看这些用例的图库。

规格说明、规划与探索

HTML 是 Claude 深入分析问题的丰富画布。当我开始处理一个问题时，我不再写一个简单的 Markdown 计划，而是期望生成一个由 HTML 文件构成的网络。例如，我可能先让 Claude Code 进行头脑风暴，创建几个不同方向的探索。然后我会让它深入其中一个方向，可能会做出界面原型或案例。最后，当我觉得满意了，就让它写一个实现计划。计划定稿后，我会新建一个会话，把所有这些文件传给 Claude 让它实现。在验证阶段，我也会让验证代理读取这些文件，这样它就能获得更全面的需求上下文。

示例提示词：

"我不确定登录页该走哪个方向。生成6种截然不同的方案------变化布局、语气和信息密度------在单个 HTML 文件里以网格形式排列，让我能并排对比。标明每种方案的权衡。"
"创建一个详细的实现计划 HTML 文件，确保包含一些原型图、数据流图，以及可能想审查的关键代码片段。让它容易阅读和消化。"

适用于：

探索代码中不同的实现方式
同时试验多种视觉设计

代码审查与理解

代码在 Markdown 文件里读起来很困难，但用 HTML 我们可以渲染 diffs、注释、流程图和模块。用 HTML 来理解开发者写的代码、审查代码、或者向审查者解释 PR。

示例提示词：

"帮我审查这个 PR，创建一个 HTML artifact 来描述它。我对流式/背压逻辑不太熟，所以重点放在那块。渲染实际 diff，在行内加边注，按严重程度给发现结果标色，再用其他必要手段把概念讲清楚。"

适用于：

创建 PR
审查 PR
理解代码中的某个主题

设计与原型

Claude Design 基于 HTML，因为 HTML 在设计表达上极其强大，即使最终产品不是 HTML。Claude 可以用 HTML 画出设计草图，然后再用你喜欢的语言（React、Swift 等）来写。

你还可以原型化交互效果，比如动画、动作等。考虑让 Claude 添加滑块、旋钮等控件，让你精确调出想要的效果。

示例提示词：

"我想设计一个新的结算按钮，点击时播放一个弹跳动画，然后快速变成紫色。创建一个 HTML 文件，包含几个滑块和选项，让我尝试这个动画的不同参数。加一个'复制参数'按钮，把调好的参数复制出来。"

适用于：

创建设计系统组件
调整组件细节
可视化组件库
原型化动画

报告、研究与学习

Claude Code 非常擅长综合来自多个数据源的信息，并将其转化为易读的报告。你可以让 Claude 搜索你的 Slack、代码库、git 历史或者互联网，并生成易于阅读的报告。

你可以把它组装成一长份 HTML 文档、一个交互式解释器，甚至一个幻灯片/演示文稿。让 Claude 用 SVG 画图表来帮助可视化。

示例提示词：

"我不太理解我们的限流器到底怎么工作的。阅读相关代码，生成单个 HTML 解释页面：一个令牌桶流程的图表，3-4 个带注释的关键代码片段，底部加一个'易错点'章节。优化成让读者一次读完就能理解。"

适用于：

撰写功能总结
生成解释性文章
起草周度状态报告
创建事故报告
制作 SVG 插图、流程图、技术图表

自定义编辑界面

有时你很难纯靠文本框描述你想要的东西。针对这种情况，我经常让 Claude 为我正在处理的具体问题构建一个一次性的编辑器：它不是产品，也不是可复用的工具，而是一个单独的 HTML 文件，专门为这一份数据而建。

诀窍总是在结尾加一个导出功能：一个"复制为 JSON"或"复制为提示词"按钮，把我在 UI 里做的操作转回可以粘贴到 Claude Code 或提交到文件的内容。你仍然保持在循环里，但这个循环变得更紧密了。

示例提示词：

"我需要重新排这 30 个 Linear 工单的优先级。给我做一个 HTML 文件，每个工单是一张可拖拽的卡片，放在 Now / Next / Later / Cut 四列里。按你的最佳判断预排序。加一个'复制为 Markdown'按钮，导出最终排序结果，并为每个分组附上一行理由。"
"这是我们的功能开关配置文件。做一个基于表单的编辑器，按区域分组开关，显示开关之间的依赖关系，如果某个开关开启但前置条件关闭则给出警告。加一个'复制 diff'按钮，只输出更改过的键。"
"我在调优这个系统提示词。做一个并排编辑器：左边是带高亮变量槽的可编辑提示词，右边是三个样本输入，实时渲染填充后的模板。加一个字符/Token 计数器和复制按钮。"

适用于：

重新排序、分类或分组任何东西（工单、测试用例、反馈）
编辑结构化配置（功能开关、环境变量、带约束的 JSON/YAML）
提示词、模板或文案的调优（带实时预览）
数据集标注------批准/拒绝行、标记示例、导出筛选结果
注释文档、转录文本或 diff，并导出注释
选择那些用文本表达很痛苦的值：颜色、缓动曲线、裁剪区域、cron 表达式、正则表达式

常见问题

这些都是我常被问到的关于在 Claude Code 中使用 HTML 的问题，以及我日常实践中得出的答案：

问：这样会不会效率更低？

虽然 Markdown 通常用更少的 Token，但我发现 HTML 更强的表现力以及我读它的意愿大大提高，最终产出更好。有了 Opus 4.7 的 100 万 Token 上下文窗口，增加的 Token 数量在上下文中几乎感觉不到。

问：你现在什么时候会用 Markdown？

老实说，我几乎在一切场景下都停止使用 Markdown了，不过我对 HTML 的偏爱可能有点极端。

问：这就是你取代规划的方式吗？

我发现我不再只有一个计划，而是针对计划的不同部分/阶段分别有若干个 HTML 文件。比如，我会制作一个 HTML 的实现计划，然后另一个文件用于探索 UI，最后再一个 HTML 组件列出所有设计。我倾向于保留这些文件作为未来的参考，也在验证阶段使用它们。

与 Claude 保持同步

以上所有内容归结起来，我使用 HTML 而非 Markdown 的真正原因是，它帮助我更好地与 Claude 保持同步。随着 Claude 承担越来越多的工作，我注意到自己读计划的细致程度在下降，我希望有一种方式能持续关注它的选择，而不是直接撒手不管。HTML 恰恰做到了这一点。我现在感觉比以往任何时候都更贴近它的决策。

本文由 Thariq Shihipar（技术人员）撰写，表达了他个人的观点------以及对在 Claude Code 中使用 HTML 文件的偏爱。