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

LaughingZhu

806人浏览 · 2026-05-16 09:34:31

LaughingZhu · 2026-05-16 09:34:31 发布

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

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

Markdown 已经成为 AI 与人类沟通的主流格式，但它正在成为限制。
HTML，才是 AI 输出的下一个形态。

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

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

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

Markdown vs HTML comparison from Thariq's article

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

Two-way interaction demo from Thariq's article

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

1. 规格文档与头脑风暴

Specs and planning HTML example from Thariq

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

2. 代码审查与理解

Code review HTML example from Thariq's PR workflow

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

3. 设计原型与交互调试

Design prototype HTML example from Thariq

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

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

Research report HTML example from Thariq's git history analysis

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

5. 一次性定制编辑界面

Custom HTML editor for task triage from Thariq's example

这是最有趣的使用场景。当你想调整的东西很难用文字描述清楚时（比如重新排序 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 输出格式与人类认知之间的断裂。

认知负荷理论

Visual clarity comparison: HTML's structured layout vs flat markdown

认知心理学中有个核心概念叫认知负荷（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 的汇流

AI output paradigm shift: from text to interactive 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 协作工具的正确类比：不是更快的打字机，而是更聪明的画布。