Claude Code · AI-native engineering

Claude Code 的下一步，不是写更多 Markdown，而是生成 HTML 工作台

过去我们习惯让 AI 输出一大段 Markdown：计划、分析、表格、TODO、代码片段，全部堆在一起。问题是，当 AI 代理真的开始处理复杂工程任务时，更长的文档不等于更好的协作。

Anthropic 在一篇 Claude Blog 里提出了一个很有意思的判断：在 Claude Code 的使用中，HTML 正在变得“反常地有效”。我理解它不是在说 Markdown 过时了，而是在说：当输出从“文本答案”升级成“工程判断”时，我们需要一个更强的承载界面。

真正的变化不是 AI 会写网页了，而是 AI 开始需要一种方式，把复杂判断组织成人类能读、能审、能继续反馈的界面。

为什么 HTML 正在取代 Markdown — 图 1：复杂代理输出需要更强的文档格式。

01. Markdown 的问题，不是“不够好”，而是“不够承载复杂性”

Markdown 的优势非常明确：简单、轻量、好写。写会议纪要、整理 TODO、记录简单设计思路，它仍然非常合适。

但 Claude Code 的输出正在变重：复杂 spec、系统设计、代码评审、研究报告、功能取舍、实现路径、风险列表、上下文证据。它们如果全部塞进一篇线性 Markdown，最后往往变成一条很长的滚动页面。

很多时候，团队成员不是不关心，而是根本读不完。于是问题从“AI 有没有生成答案”，变成了“人有没有真的看懂并参与判断”。

02. HTML 的第一个优势：信息密度更高

HTML 天然适合承载多种信息：表格、代码片段、流程图、颜色、布局、控件、状态标记、图像和 SVG。它不是把内容写成更长的段落，而是把不同类型的信息放到合适的位置。

这对 AI 输出很关键。Claude Code 能读到本地代码、文件系统、Git 历史、浏览器上下文和外部工具数据。读到的信息越多，输出就越需要一个能组织复杂上下文的界面。

信息密度：HTML 是更大的画布 — 图 2：HTML 把多种工程信息压进一个可扫描画布。

03. HTML 的第二个优势：可读性更强

原文里有一个很现实的点：如果别人更可能读完你的 spec、报告或 PR 说明，输出质量其实已经提升了。

Markdown 是线性的，它鼓励从上到下阅读。但工程协作通常不是这样。我们会先扫结论，再看风险；先看方案对比，再点进某个细节；先看架构图，再回到代码片段。HTML 可以把这些阅读路径显式设计出来。

可读性：不是写得更多，而是读得进去 — 图 3：重点不是写更多，而是让复杂信息读得进去。

04. HTML 的第三个优势：分享摩擦更低

复杂输出如果只是一个 Markdown 附件，协作链路会多很多摩擦：下载、预览、转换、找渲染器、复制片段、再发到别的地方。

HTML 的心智模型更直接：上传之后就是一个链接。浏览器能打开，手机能打开，团队能引用，评论也更容易围绕页面结构展开。

05. 最关键的一点：HTML 可以变成双向交互界面

这也是我觉得最有价值的部分。HTML 不只是“展示得更好看”，它还可以成为一次性编辑器。

例如：调动画速度、拖拽任务优先级、编辑 feature flag、调整系统 prompt、给一组设计方案打分、把需求拆成 Now / Next / Later / Cut。人的反馈不再需要重新写成长文本，而是可以通过控件、选择、拖拽和导出按钮，变成 Claude Code 能继续执行的 JSON、diff 或 prompt。

06. 这件事为什么现在才变重要？

因为 Claude Code 的角色正在变化。它不只是“回答一个问题”，而是在读取上下文、理解代码库、整理历史、连接工具、生成方案，再把方案推进到实现。

也就是说，它做的事情越多，人类越需要一个“观察窗口”。HTML 很适合当这个窗口：它可以把多源上下文变成报告、图解、分类看板和可操作界面。

数据摄取：HTML 是上下文的展示层 — 图 6：Claude Code 读上下文，HTML 负责展示上下文。

07. 最适合 HTML 的几个场景

我会把原文提到的场景归成两类。

第一类：规划、探索和代码理解

比如让 Claude Code 对同一个功能给出 6 个方案，并排展示成本、风险、体验差异和实现路径。或者让它做代码评审，把 diff、注释、严重程度、流程图和修复建议放在一个页面里。

第二类：原型、研究报告和一次性工具

比如设计原型需要调整动画参数，研究报告需要把多源信息组织成结构化页面，一次性工具需要拖拽任务、编辑配置、导出 prompt。这些都不是传统意义上的“产品页面”，但它们非常适合成为临时 HTML 工作台。

用法 2：原型、报告与一次性工具 — 图 8：HTML 可以是为当前问题定制的一次性工作台。

08. 给工程师的实用提示词：下次别只让它写 Markdown

如果你想马上试，可以把下面这段作为 Claude Code 的输出约束：

请不要只输出长 Markdown。请生成一个单文件 HTML artifact，用于帮助团队审阅这个问题。要求： 1. 用清晰的信息架构组织内容：概览、方案对比、风险、实现步骤、开放问题。 2. 用表格、流程图、颜色标签和代码片段提升可读性。 3. 如果需要人类反馈，请加入可编辑控件或选择项。 4. 最后提供一个“复制为 prompt / JSON”的区域，方便把人的选择带回 Claude Code。

这段提示的关键不是“做漂亮页面”，而是让输出从报告变成一个协作界面。

我的判断：未来 AI-native engineering 的核心能力之一，不是会不会写更多代码，而是能不能把 AI 的中间判断变成可读、可审、可交互的 artifacts。

09. 结论：HTML 不是炫技，是让人留在回路里

HTML 不会替代所有 Markdown。简单记录、轻量说明、短 TODO，Markdown 仍然足够好。

但当 Claude Code 开始承担更多工程判断时，人类真正需要的是一个可视化界面：能看懂它为什么这么选，能检查它有没有漏掉风险，也能把自己的反馈重新送回执行链路。

结论：真正的价值是留在回路里 — 图 9：Claude 做得越多，人越需要一个界面跟上它的判断。

这篇文章不是原文逐字翻译，而是基于 Anthropic Claude Blog《Using Claude Code: The unreasonable effectiveness of HTML》的中文解读和视频化重写。

适合继续用 Markdown：短笔记、简单 TODO、轻量结论。
适合改用 HTML：复杂 spec、方案对比、代码评审、研究报告、交互式参数调整。
真正值得收藏的点：下次让 AI 生成的不只是答案，而是一个能继续协作的工作台。

如果你已经在用 Claude Code，可以试一次：把同一个复杂任务分别要求它输出 Markdown 和 HTML，再比较你自己更愿意读完哪一个。