摘要：Anthropic Claude Code 团队成员 Thariq Shihipar 提出一个反直觉但非常值得重视的观点：在很多开发场景里，不要默认让大模型输出 Markdown，而应该直接要求它输出 HTML。这个建议之所以重要，不是因为 HTML 更“高级”，而是因为当模型开始承担解释、审查、文档和交互式展示任务时，HTML 提供的结构化表达能力、视觉组织能力和轻量交互能力，正在显著改变开发者获取信息和理解复杂系统的方式。
过去两年，几乎所有人都默认把 Markdown 当成大模型输出的标准格式。这个习惯并不奇怪。Markdown 足够轻，足够简洁，跨编辑器、跨平台、跨工具都很稳。在大模型上下文窗口还比较紧的时候，它还有一个非常现实的优势：省 token，省格式噪音，也更不容易把输出搞乱。
但最近 Anthropic Claude Code 团队成员 Thariq Shihipar 提出的一个观点，值得开发者认真重看这件事。他主张，在很多实际使用场景里，尤其是解释复杂系统、审查代码、生成技术说明、构建交互式分析材料时，应该主动要求 Claude 输出 HTML，而不是 Markdown。
Simon Willison 在评论这篇文章时，把这个思路概括成了一个很有冲击力的标题：The Unreasonable Effectiveness of HTML。中文大致可以理解成，HTML 在这类场景里的效果好得有点“超出预期”。这不是一句夸张口号，而是一个很现实的工作流变化信号：当大模型输出不再只是“文本答案”，而是开始承担解释界面、审查面板、交互式说明页、结构化知识展示这样的任务时，Markdown 可能已经不是默认最优解了。
一、这件事为什么反直觉
之所以很多人第一次看到这个观点会觉得意外，是因为我们长期把 HTML 理解成“网页开发语言”，而把 Markdown 理解成“写作格式”。于是潜意识里会觉得：既然我只是让模型解释一个 PR、总结一段代码、整理一个知识点，为什么要让它搞成 HTML 这么重？
问题在于，这个判断默认了两件事：第一，输出主要是纯文本；第二，阅读场景主要是线性阅读。但今天很多 AI 输出，已经不是纯文本消费场景了。开发者让模型做的事情，越来越像是在生成一个“可浏览、可比对、可定位、可折叠、可高亮、可交互”的解释界面。
一旦任务从“生成一段说明”转向“生成一个可以帮助人理解复杂对象的界面”，HTML 的优势就会突然变得非常明显。
Markdown 擅长的是轻量表达，它能很好地完成标题、列表、代码块、引用和表格这些基础工作。但它不擅长布局，不擅长多区域并排展示，不擅长细粒度高亮，不擅长交互，也不擅长在一个结果里自然嵌入图形、导航、折叠区、注释层或小部件。
而 HTML 恰恰相反。它的本质不是“更花哨的文本格式”，而是一个天然带结构和容器能力的输出介质。它允许模型把信息组织成卡片、分栏、标签页、浮动注释、颜色层级、SVG 示意图、时间轴、流程图，甚至带一点轻量 JavaScript 的交互组件。对于复杂解释任务来说，这不是装饰，而是认知效率本身。
二、为什么 Claude Code 团队会强调这一点
这背后其实是 Claude Code 这类工具形态变化的自然结果。
如果大模型只是一个聊天窗口，Markdown 确实通常够用了。可一旦它进入开发工作流，成为 PR review 助手、代码解释器、架构说明器、文档生成器，输出就不再只是“给你一段答案”，而更像是“给你一个工作面板”。在这个阶段，表达介质的选择开始直接影响理解效率。
Thariq 给出的提示词例子就很有代表性，大意是：帮我 review 这个 PR，创建一个描述它的 HTML artifact；我对 streaming/backpressure 这部分不太熟，请重点看那里；把实际 diff 渲染出来，在边缘做行内注释，按严重程度给问题着色，并用任何有助于表达概念的方式组织内容。
注意，这个需求如果用 Markdown 也不是完全做不了，但效果通常会比较别扭。因为 PR review 本来就是一个强结构化任务，它天然需要：
- 原始 diff 与解释并排对照
- 风险等级有明显视觉区分
- 重点区域能快速跳转
- 不同问题分层折叠
- 上下文说明和局部代码形成映射
这些都更接近一个轻量页面，而不是一篇线性笔记。也正因为如此，Claude 输出 HTML artifact 之后，就不只是“回答了问题”，而是在某种意义上生成了一个临时的、围绕任务定制的信息产品。
这也是为什么这件事对开发者生产力有现实意义。很多时候，模型值不值钱，差别不在它“会不会答”，而在它能不能把复杂信息组织成你可以迅速消化的形式。
三、HTML 的真正优势，不是好看，而是更适合复杂解释
很多人一听到“让 AI 输出 HTML”，第一反应是：是不是只是页面更好看？
我觉得这恰好低估了问题。真正的优势不是美观，而是认知组织能力。
1. 更强的结构化表达
Markdown 本质上是顺序流。你可以加标题、列表、引用，但信息大多数还是一段一段往下排。HTML 则可以非常自然地把一个复杂话题切成多个区域，比如“概览”“风险点”“关键代码”“时序关系”“建议改动”“补充资料”，每个区域都有自己的布局和视觉权重。
对于架构解释、代码审查、系统行为说明来说，这种分区能力非常重要。因为开发者理解复杂内容时，往往不是从头到尾通读，而是在不同视角之间快速切换。
2. 可以原生嵌入 SVG 图表
这可能是最被低估的一点。模型如果被要求输出 HTML，就可以顺手输出 SVG 流程图、模块关系图、时序图、数据流示意图。对解释网络请求、并发控制、缓存机制、状态机、PR 改动前后逻辑差异来说，这个能力非常有价值。
很多过去需要画图工具单独补的工作，现在模型在一次输出里就能带上。图未必完美，但常常已经足以把抽象关系说清楚。
3. 可以加入轻量交互
交互式小部件不一定要多复杂。哪怕只是：
- 点击展开详细解释
- 鼠标悬停看术语说明
- 标签切换不同视图
- 按严重级别筛选问题
- 折叠/展开长代码块
这些对阅读体验的提升都很明显。因为复杂信息的难点，往往不是“信息量不够”，而是“一次呈现太多，用户难以消化”。交互能让信息分层暴露，而 HTML 是承载这种分层的天然格式。
4. 更适合做“临时工件”
这也是我觉得 Claude Code 这类工具特别适合采用 HTML 输出的原因。很多 AI 输出其实不是最终文档，而是任务过程中的临时工件，比如一次 PR review、一页漏洞解释、一份系统梳理、一张概念地图。这类东西不一定要进正式知识库，但它需要在当下足够清晰、足够可浏览、足够好用。
HTML 很适合这种一次性但高价值的中间产物。它比纯 Markdown 更强，但又没有重到非得走完整前端开发流程。
四、这件事为什么现在才变得重要
Simon Willison 提到一个关键背景。过去 GPT-4 时代，很多人默认要求模型输出 Markdown，一个非常现实的原因是上下文窗口小，HTML 相比 Markdown 会多一些格式 token，性价比未必高。
但现在这个约束正在变弱。
一方面，模型上下文窗口更大了，格式开销不再像以前那么敏感。另一方面，更关键的是，开发者对模型的期待已经变了。以前我们更关心“它能不能生成文字”，现在更关心“它能不能生成一个帮助我工作的信息界面”。在这种变化下，Markdown 的简洁优势开始让位给 HTML 的表达优势。
换句话说，不是 HTML 突然变厉害了，而是任务类型变了。当任务从“让 AI 写”走向“让 AI 解释、组织、呈现、引导理解”，HTML 就更像正确的介质。
五、Simon Willison 的实验，为什么很有说服力
这件事不是停留在理念层面。Simon Willison 还直接拿 GPT-5.5 试了一次。他让模型解释一段关于 Linux 漏洞的代码，并要求输出 HTML，且使用 HTML、CSS、JavaScript 的能力，把说明做得更丰富、更交互、更清晰。
这个实验很有代表性，因为它不是一个“写网页”的任务，而是一个典型的“解释复杂技术对象”的任务。模型输出的不是一段普通答案，而是一页结构化解释材料。
这说明一个很重要的现实：HTML 输出这件事不依赖某一家模型专属能力，而更像是一种跨模型、跨工具的提示策略。 Claude 可以做，GPT 也可以做。只要模型足够强，理解这种“请生成一个可视化解释工件”的意图并不困难。
这也意味着，这个方法的意义不止于 Claude Code。它更像是整个 AI 开发工作流里一个值得推广的新默认：
- 解释复杂代码时，别总让模型写 Markdown
- 说明系统行为时，别总满足于普通列表
- 做 PR review、漏洞解读、技术文档时，可以先试试 HTML artifact
很多时候，你会得到一个明显更“可用”的结果。
六、这对普通开发团队意味着什么
我觉得这件事最大的启发，不是“以后都别用 Markdown 了”。Markdown 当然还很重要，而且在很多场景下依然是最优解，比如 README、轻量笔记、issue 模板、简单总结、跨平台纯文本协作。
真正值得调整的是默认思维：不要把 Markdown 当成所有 AI 输出任务的统一终点。
更合理的做法是按任务类型选格式：
- 线性阅读、简要总结、需要复制粘贴到文档系统时，用 Markdown
- 需要可视化解释、局部对照、结构导航、交互展示时，用 HTML
如果一个团队开始有意识地这样区分，AI 输出的可用性会提升很多。特别是在代码审查、漏洞分析、架构评审、技术 onboarding、复杂流程说明这些高认知负荷任务里，HTML 可能带来的不是“小优化”，而是一次明显的工作流提效。
七、这背后真正值得注意的，是 AI 输出正在从“答案”变成“界面”
我觉得这篇文章真正有价值的地方，还不只是提供了一个提示词技巧，而是点出一个更大的方向变化：AI 的输出正在从答案形态，走向界面形态。
过去我们把模型当成一个会写字的系统，所以自然默认它的产物应该是段落、列表、表格和代码块。现在模型越来越像一个可以临时生成解释界面、分析面板和认知辅助工件的系统。这时候，HTML 就不是“多此一举的格式”，而是更接近它能力上限的承载方式。
从这个角度看，Thariq 的观点其实很像一个时代转换信号。真正先进的，不是让模型把字写得更漂亮，而是让模型把复杂信息组织成一个人愿意看、看得懂、能操作的东西。
这也是为什么我觉得这件事很可能会在开发工具里快速扩散。未来无论是 Claude Code、OpenAI 的编程工具，还是各种 IDE 内嵌 Agent、代码审查助手、知识解释器，都会越来越多地输出 HTML artifact、交互式说明页、局部分析面板，而不只是长长的一段 Markdown。
八、写在最后
如果只把这件事看成一个“小技巧”，你可能会觉得它只是提示词工程里的一个新花样。但如果把它放到开发工作流演进里看，它其实非常重要。
它提醒我们，很多 AI 场景的问题，不是模型本身不够强，而是我们还在用旧的输出习惯限制它。我们习惯让模型给一个答案，却没有认真想过，某些任务真正需要的也许不是答案，而是一个结构化、可导航、可交互、可视化的解释界面。
在这个意义上，“让 Claude 输出 HTML 而不是 Markdown”并不是为了炫技，而是为了让 AI 更像一个真正能帮人工作的搭档。
对开发者来说，最值得马上尝试的一步也许非常简单：下次你让模型解释一个复杂 PR、一段难懂代码、一个漏洞成因、一套系统流程时，不要再默认说“帮我总结一下”，而是直接试试这句：
请创建一个 HTML artifact 来解释这件事。
你很可能会第一次真正感受到，输出格式本身，也是一种生产力。