Claude Code 时代的写作：为什么 HTML 正在取代 Markdown

引子：一份超过一百行的文档，没有人真的会读

Thariq Muhammad（@trq212，Claude Code 团队成员）在 2026 年 5 月发了一条推文，主张一个反直觉但细想又极其显然的观点：

Markdown 已经成为 AI 与人类沟通的主流格式，但它正在成为限制。

HTML，才是 AI 输出的下一个形态。

这条推文获得了 400+ 赞同和 200+ 评论，评论区的热烈程度说明这不是一个人的偶发感悟，而是很多人的共同困惑------随着 AI 生成内容越来越多，我们发现自己越来越读不动了。

这是一篇试图把这件事讲明白的文章。四个角度：观点评论、实践指南、认知科学背景、产品设计启示。逐一展开。

一、深度观点：Markdown 为什么正在成为 AI 时代的"权宜之计"

Markdown 的崛起有它的历史必然。它诞生于 2004 年，最初只是 John Gruber 为简化 HTML 写作而设计的一套轻量标记规则。它简单、没有生态锁定、几乎所有平台都能渲染。这些特性让它顺理成章地成为了技术社区的通用语------README、文档、博客、笔记，全用 Markdown。

AI 时代，这套遗产被完整继承。LLM 输出 Markdown 是最自然的事情：它本质上是在生成带标记的文本，格式简单、结构清晰，人类看得懂、改得了。Anthropic 的 Claude 在很多场景下甚至能输出漂亮的 ASCII 图表，用 Unicode 字符模拟颜色区块来"可视化"信息。

但问题来了：当 AI 的能力越强，它能输出的内容就越复杂、越丰富、越长------而人类消费它的方式，却还停留在二十年前的格式里。

Thariq 观察到的一个现象很能说明问题：

我发现我很难认真读完一个超过一百行的 Markdown 文件。我甚至无法让团队里的任何人去读它。

这句话背后是一个根本性的矛盾：AI 生成内容的密度正在指数级增长，但 Markdown 的表达能力是有上限的。

Markdown 能做：标题、列表、粗体、链接、代码块、图片。

Markdown 不能做（或者做得很勉强）：表格布局、CSS 样式、SVG 图表、交互控件、响应式排版、实时预览、多栏并排。

当 Claude 可以生成一个包含数据流图、代码片段注释、mockup 预览和参数调节面板的完整技术方案时，用 Markdown 来表达这一切，本质上是在用 txt 文件打开一个 Figma 项目。

Markdown 是 AI 时代的"纸带打孔"------技术上能工作，但在用最低效的方式浪费着最强大的工具的潜力。

HTML 的核心优势在于它是图灵完备的表示格式------它不仅能表达内容，还能表达界面、交互、数据和结构。你让 Claude 生成一个 HTML 文件，它实际上是在为你构建一个可以实时运行的数字制品，而不仅仅是一份静态文档。

这是为什么 Claude Code 团队内部越来越多人开始用 HTML 替代 Markdown 作为默认输出格式。Thariq 的判断是：当模型的上下文窗口达到百万级（Opus 4.7 的 1M token），生成更丰富的 HTML 不再是奢侈，而变成了理所当然的选择。

二、实践指南：怎么用 HTML 作为 AI 协作媒介

概念说清楚了，现在说实操。Thariq 在原文中给了一个重要警告：

我有点担心大家看完这篇文章就去搞一个 /html skill。在我看来，你不需要做什么特别的事情，只需要让 Claude "生成一个 HTML 文件"或"生成一个 HTML artifact"。

所以这不是关于技能树的问题，而是关于工作意识的问题------什么时候应该想到用 HTML，怎么用它。

什么场景适合用 HTML

根据 Thariq 的实践和我的理解，以下场景是 HTML 的强项：

1. 规格文档与头脑风暴

当你启动一个复杂项目，从 0 开始和 Claude 协作时，用 HTML 可以让 Claude 生成多层次的可视化输出。你可以要求它生成不同方案的并排对比（6 个不同方向的 onboarding 界面布局），包含 mockup、数据流图和关键代码片段，然后一键分享链接给同事。关键是：让 Claude 把思考过程展开成可导航的结构，而不是压缩进一个 200 行的纯文本文档。

2. 代码审查与理解

代码在 Markdown 里就是代码块。但代码是有结构的------有模块依赖、有数据流向、有业务逻辑。HTML 可以渲染 diff、标注注释、生成模块关系图，甚至做成交互式的代码解释器。Thariq 的用法是：每次提 PR 都附带一个 HTML 代码说明器，效果比 GitHub 默认的 diff 视图好得多。

3. 设计原型与交互调试

Claude Design 基于 HTML，因为它本身就极擅长表达设计。即使你的最终交付物是 React Native 或 Swift，Claude 也可以先用 HTML 做出可交互的设计稿，配上滑块和参数调节面板让你实时调整效果，然后把参数迁移到目标代码。这比来回看静态 mockup 然后靠文字描述调整要高效得多。

4. 报告、研究与知识整理

Claude Code 可以读取 Slack、代码仓库、git 历史、网页------然后把所有信息综合成一份 HTML 报告。Thariq 在研究 prompt caching 的进展时，让 Claude 读取了完整的 git 提交历史，生成了一份带 SVG 流程图的深度技术文档。这在 Markdown 里几乎不可能做到同等效果。

5. 一次性定制编辑界面

这是最有趣的使用场景。当你想调整的东西很难用文字描述清楚时（比如重新排序 30 个 Linear 工单，或者编辑一组复杂的 feature flag 配置），你可以让 Claude 构建一个临时专用的 HTML 编辑器------拖拽卡片排序、可视化配置编辑、prompt 模板实时预览------最后加上一个"复制为 Prompt"按钮，把你的操作结果转译回 Claude Code 的指令。

这最后一个模式揭示了 HTML 作为 AI 协作媒介最核心的设计原则：让 AI 生成的输出不只是信息，而是可以反向编程的媒介。

工作流建议

从 Markdown 迁移到 HTML，不需要一夜之间颠覆所有习惯。Thariq 的建议是：

从"让它生成 HTML 文件"开始，不要一开始就搞复杂的模板或技能
想清楚你最终怎么消费这个输出：是本地打开查看？是分享给同事？是作为下一步工作的参考？
HTML 生成比 Markdown 慢 2-4 倍，这是真实成本，但通常值得------尤其当你需要多次查阅这份文档时

一个实际的起点：下次你让 Claude 做技术方案时，试试说"生成一个 HTML 文件，包含架构图、数据流说明和关键代码片段，方便我阅读和分享"。感受一下差异。

三、认知科学：为什么信息密度和视觉结构如此重要

原文中有一个细节很有意思：Claude 试图在 Markdown 里用 Unicode 字符估计颜色（比如用不同颜色的方块来"可视化"一个设计稿），Thariq 把这称为"我最喜欢的一个例子"。

这个例子精准地揭示了 AI 输出格式与人类认知之间的断裂。

认知负荷理论

认知心理学中有个核心概念叫认知负荷（Cognitive Load）：人在处理信息时能够同时保持的注意力资源是有限的。当信息密度超过这个阈值，人就会开始跳读、略读、或者干脆放弃。

Markdown 在信息量较小时是完美的：清晰的标题结构、简洁的列表、代码块一目了然。但当信息量增大，它的扁平结构反而成了负担------你无法通过视觉层级快速定位关键信息，所有内容以相同的"权重"堆在屏幕上，等着读者自己组织结构。

HTML 通过视觉结构和空间布局解决这个问题。标题的大小、颜色区块、位置关系、留白------这些都是人类视觉系统天然擅长处理的信息通道。一个设计良好的 HTML 页面，人在扫视时就能直觉地把握整体结构，而不需要逐字阅读。

双通道理论

人类认知有两条平行的信息处理通道：语言通道 和视觉/空间通道。Markdown 主要激活语言通道------你读文字、理解、再组织。HTML 可以同时激活两条通道：图表、色彩、空间布局直接通过视觉系统传达信息，不需要经过语言解码的"翻译"步骤。

这就是为什么流程图比文字描述更易理解，为什么配色方案比 RGB 值列表更直观，为什么交互原型比规格说明更有说服力。

Claude 生成 ASCII 图表、用 Unicode 模拟颜色，本质上是在试图激活视觉通道，但 Markdown 的媒介限制了这种努力的上限。HTML 解除了这个限制，让 AI 能够真正发挥多模态表达的潜力。

可供性（Affordance）与交互设计

HTML 文档的交互能力引入了另一个认知层面的优势：可供性（Affordance）。

当一个文档包含滑块、按钮、下拉菜单时，读者立刻知道这是可以交互的------这改变了他们与内容的关系。不再是"阅读并理解一段说明"，而是"探索并形成直觉"。这种主动探索带来的理解深度远超被动阅读。

Thariq 提到的"play button → 动画 → 颜色变化"的原型设计场景，就是在利用这个机制：不是告诉用户参数是什么，而是让用户自己去拧参数，在拧的过程中形成对系统的直觉理解。

这种认知收益是纯文本格式无论如何都无法提供的。

四、产品设计启示：AI 输出格式正在重新定义人机界面

Thariq 的观点不只是个人工作流优化，它指向了一个更大的产品设计趋势：随着 AI 越来越深地介入知识工作，AI 输出的"界面"正在成为核心设计议题。

Artifacts 的汇流

回看近两年的产品演进，会发现一个清晰的脉络：

Anthropic 推出 Artifacts，让 Claude 生成可预览的代码块、文档和代码片段
Cursor 推出 Compositor，把 AI 输出变成可组装的界面元素
Vercel v0 和类似工具把 AI 生成的前端代码直接变成可运行的预览
Claude Code 的 HTML 输出模式，则是在 AI 协作工作流层面系统性地拥抱这一方向

这些产品不约而同地在做同一件事：把 AI 输出从"文本"升级为"可交互的数字制品"。

背后的驱动力是一样的：当 AI 的能力足够强，瓶颈不再是"生成速度"，而是"人类能否有效消费 AI 的输出"。一个每秒能生成 1000 token 的模型，如果输出的是人类读不动的文档，实际吞吐量就是零。

人机协作界面的范式转移

传统软件设计中有一个经典概念：输出设备与输入设备的对称性。你用键盘输入，用屏幕输出；你给出指令，消费结果。但 AI 正在打破这个对称------AI 不是执行单一指令的工具，而是能够生成复杂、多模态、上下文丰富的输出的协作者。

在这种范式下，输出格式不再只是"显示方式"，而是协作界面的核心组成部分。一个 HTML 文件可以是规格文档、可以是原型、可以是报告、可以是编辑工具------这取决于它在工作流中扮演什么角色。

Thariq 说"用 HTML 让觉得更在循环里（feel more in the loop）"------这句话值得深究。他说的不是效率提升，而是参与感。当文档是静态文本时，他是读者，Claude 是作者；当他消费 HTML 制品时，他是在和 Claude 一起探索一个可以交互的空间，作者和读者的边界模糊了。

这才是 AI 协作工具的正确类比：不是更快的打字机，而是更聪明的画布。

对 AI 产品设计者的启示

如果你在设计 AI 相关的工具或功能，有几个问题值得认真思考：

你的 AI 输出格式是否匹配任务的复杂度？ 简单任务用 Markdown 没毛病，复杂任务要考虑更丰富的格式能力
用户是否真的消费了你的输出？ 如果 AI 生成的内容阅读率很低，格式就是问题所在，而不是内容质量
你的工具是否在培养用户的消费习惯？ 工具会塑造行为------当用户习惯了只读短 Markdown，他们就不会去读长文档，即使内容本身很好
你是否在利用交互能力？ 一个可以调节参数的界面 vs 一段描述参数的文字，差异不只是体验上的------它会影响用户对系统的理解深度

结语：这不是关于 HTML vs Markdown 的战争

写到最后，有必要澄清一件事。Thariq 的核心论点不是"Markdown 死了"或"所有内容都应该用 HTML"。他的论点是：随着 AI 进入知识工作的核心场景，我们需要重新思考"输出格式"这件事。

Markdown 依然是非常好的格式------轻量、便携、版本控制友好、几乎零门槛。它会在很多场景继续存在。

但当我们谈论 AI 与人类的深度协作------规格文档、代码审查、设计原型、技术报告------这些需要高信息密度、强结构化、可交互甚至可操作的场景，HTML 的表达能力是 Markdown 无法替代的。

关键不是选边站，而是意识到格式选择的认知代价。当你让 Claude 生成一份超过一百行的文档，你应该问一下自己：这真的应该是 Markdown 吗？

如果答案是否------你知道该怎么做。