让 AI 输出 HTML,效果好得有点不讲道理

喜欢就关注我哦～

Claude Code 团队最近发了一篇文章：《Using Claude Code: The unreasonable effectiveness of HTML》。

文章不长，但讨论了一个很多人每天都在面对却不怎么谈的问题：AI 产出的东西，到底应该长什么样？

过去两年，所有人让 AI 干活，默认输出格式几乎全是 Markdown。这个习惯太自然了，自然到没人觉得有问题。Markdown 轻量、好编辑、兼容一切工具链，从 Obsidian 到 Notion 到 GitHub README，哪儿都能用。

但当 AI 开始承担更重的工作——代码审查、方案对比、事故复盘、需求整理——Markdown 的短板就出来了。

一份 200 行的技术方案发到群里，你会从头读到尾吗？一份 PR 审查说明只有几段文字加代码块，reviewer 能快速判断这个 PR 敢不敢合吗？

Markdown 擅长呈现"文本"。问题在于，很多 AI 任务产出的已经不是文本，而是结构、关系、状态、选择、风险和行动。这些东西，HTML 表达起来自然得多。

三个很具体的理由

Anthropic 的文章里给了几个理由，我掰开说一下。

第一，HTML 一个文件能装的东西多得多。 Markdown 能写标题、列表、表格、代码块，日常笔记够用。但复杂交付物需要的不止这些——你可能想在同一页里放流程图、风险热力图、可折叠的代码 diff、按模块分组的改动清单。Markdown 做不到，HTML 可以。SVG 画架构图，CSS 控制信息层级，JavaScript 加上拖拽排序，Canvas 画空间关系图，全都是标准能力，不需要额外工具。

第二，长内容的阅读门槛差很多。 Agent 越强，产出的报告和分析就越长。问题不是信息没用，而是读不动。一份 150 行的 Markdown 方案，同事打开扫两眼就关了。同样的内容做成 HTML，顶部有导航，关键风险用红色标记，次要信息默认折叠，想看再展开——阅读门槛会明显下来。不是为了好看，是为了让人真的能读完。

第三，HTML 天生适合分享。 Markdown 发出去，接收方可能需要特定的渲染器或文档平台才能看到排版效果。自包含的 HTML 文件不一样——上传之后就是一个链接，浏览器点开就能看，不需要解释怎么打开。PR 说明也好，事故复盘也好，方案对比也好，打开门槛越低，被认真看的概率越高。

一个很容易被误解的点

Anthropic 这篇文章不是在发布新功能，也不是在说 Markdown 过时了。

它只是在 Getting started 里提了一句：某些 HTML 输出模式如果经常用，以后可以考虑沉淀成 skill。

重点不是"Claude 又发了一个 Skill"，而是一个更基础的变化：当 AI 要交付复杂内容时，光靠一篇长 Markdown 可能不够了。HTML 不是装饰，是更适合承载信息的容器。

哪些场景 HTML 明显更好

短笔记、简单清单、日常回复，Markdown 就挺好的，不用折腾 HTML。

下面这几类场景，HTML 的优势会明显得多。

代码审查和 PR 解释。 一个改了十几个文件的 PR，涉及数据流、状态管理、权限、异常处理、测试覆盖。如果 reviewer 只能看到几段文字加零散的代码块，很难快速形成判断——哪些是高危改动，哪些是例行调整，哪些需要作者补充说明。HTML 可以把这些维度拆开：改动范围一目，风险分高、中、低用颜色区分，数据流用 SVG 画出来，关键 diff 直接渲染，建议修改项列在每条风险下面。reviewer、PM、测试同事都能各取所需，而不是所有人都要啃同一篇长文。

产品方案和设计探索。 做方案经常不是缺答案，而是需要比较多个方向。一个 onboarding 页面，该做成问答式、卡片式、表单式还是导览式？Markdown 可以把六个方案挨个写出来，但读者要在方案之间来回翻。HTML 可以把六个方案放进同一个页面并排比较，每个方案一个卡片区域，标上适合人群、信息密度、转化优势和实现成本。当 Claude Code 能读到代码库和设计规范时，它生成的 HTML 还能尽量贴近现有产品约束，不只是"漂亮原型"，是可以进入设计讨论的中间表达层。

研究报告和事故复盘。 这类内容最大的问题不是缺材料，而是材料太多。Slack 里有讨论，Git 里有变更记录，Linear 里有任务，网页上有参考资料。Claude Code 能读到很多上下文，如果最后只输出一篇长 Markdown，收集上下文的能力就浪费了。HTML 报告可以先给结论摘要，再铺证据链、时间线和关键图表，风险项和下一步行动放在一起。事故复盘做成时间轴，竞品研究做成对比页，周报做成按项目分组的状态卡——这些不是传统文章的表达方式，但确实是 HTML 很擅长的。

临时编辑器和决策工具。 还有一种用法经常被忽略。很多时候你让 AI 帮忙，不是想看报告，而是想做决策——给三十个需求排优先级、调整 feature flag 配置、清洗一批数据、给客户反馈打标签、调整系统提示词。如果用纯文本交互，整个流程就很绕：你说一句，AI 改一版，你再说一句，AI 再改一版。HTML 可以直接生成一个临时编辑器：把需求做成可拖拽卡片，配置项做成表单，提示词做成左右对照，筛选结果做成可勾选列表。最后加一个"导出为 JSON / Markdown / Prompt / diff"的按钮。你还在决策回路里，但操作轻了很多。

怎么开始用 HTML 输出

不需要复杂配置。从一句提示开始就行。

最基础的版本：

不要输出 Markdown。请创建一个自包含的 HTML 文件，解释这个模块的工作方式。要求：- 顶部给 5 句话摘要- 用 SVG 画出数据流- 列出 3 个关键代码片段，加上注释- 用颜色区分高风险和低风险- 页面要能直接在浏览器打开- 所有 CSS 和 JS 写在同一个文件里

做 PR Review 时：

请生成一个 HTML 审查报告。重点不是罗列所有改动，是帮 reviewer 快速判断这个 PR 能不能合。包含：改动范围、关键 diff、风险分级、需要作者确认的问题、可以直接复制到 PR 评论里的建议。

做可操作的小工具：

请生成一个单文件 HTML 小工具。我要用它整理需求。页面里放 Now / Next / Later / Cut 四列，卡片可以拖拽。最后给一个"复制为 Markdown"的按钮，输出最终排序和每个需求的一句话理由。

关键不在于提示词的长度，而在于说清楚目标：这个 HTML 文件要帮人完成什么动作——阅读、比较、审查、编辑、还是导出？目标越具体，产出越有用。

HTML 有什么不好的地方

不回避问题。HTML 不是万能格式，有些场景 Markdown 仍然是最优解：短笔记、简单待办、文章草稿、README、API 文档、需要长期版本管理的文字材料。Markdown 干净、稳定、diff 友好，这些优势不会消失。

HTML 的问题也很真实：比 Markdown 更长，更占 token；CSS 和布局一旦复杂，版本管理就是负担；如果 JavaScript 来源不可控，分享前还要考虑安全边界；直接把 HTML 当唯一源文件，后续让 Agent 修改时可能被大量样式噪音淹没。

比较稳的做法：把 Markdown、JSON、YAML 当源数据，把 HTML 当视图层。 核心事实和决策逻辑有干净的结构化来源，HTML 负责展示、比较、交互和分享。个人用可以不用这么讲究，团队协作的话，这个边界早想清楚，后面少返工。

说到底

如果你已经在用 Claude Code 处理复杂任务，可以试着在系统提示里加一条：

当任务包含多方案比较、代码审查、状态汇总、风险评估、数据筛选或人工确认步骤时，优先生成自包含 HTML 文件，而不是只输出 Markdown。这个 HTML 文件必须帮助人完成至少一个具体动作：阅读、比较、审查、编辑、导出。

说到底，这不是换一种文件后缀的事。每次让 AI 输出复杂内容时，先想清楚一个问题：这次输出是给人看的，还是继续丢给下一个工具的？不同目的需要不同的交付形式。

当 Agent 能处理的任务越来越多、越来越重，让人能快速看懂它做了什么、为什么这么做、下一步该怎么接手——这比"再多生成一点内容"重要得多。