再见 Markdown，你好 HTML！

​

很多人用 AI，默认会让它写 Markdown。写计划，用 Markdown；写总结，用 Markdown；写 PR 说明，还是 Markdown。这很合理，Markdown 简单、稳定、好改，放在代码仓库里也舒服。过去很长一段时间，Markdown 几乎就是 AI 和人之间最自然的交付格式。​

​

​

​

一、为什么转向 HTML？​

有五个核心原因：​

信息密度​

HTML 能够承载远比 Markdown 丰富的信息类型：​

•

表格数据（table）​

•

设计样式（CSS）​

•

矢量插图（SVG）​

•

代码片段（script）​

•

交互组件（JavaScript + CSS）​

•

工作流图（SVG + HTML）​

•

空间布局（绝对定位、canvas）​

几乎没有 Claude 能读取的信息，是无法用 HTML 高效表达的。 这使它成为模型向人类传递深度信息、以及人类审阅这些信息的高效媒介。​

​

​

​

上图是Claude 用 HTML 生成的结构化信息展示，包含表格、图表与分层布局。​

​

视觉清晰与阅读体验​

当 Claude 能够处理越来越复杂的工作时，它产出的规格说明书和计划也越来越长。一个残酷的事实是：几乎没人会认真读完一份超过 100 行的 Markdown 文件。​

HTML 文档则截然不同。Claude 可以通过标签页、插图、链接、折叠面板等方式，将内容组织成理想的视觉结构。甚至可以做到移动端响应式适配，让不同设备的阅读体验都保持舒适。​

​

​

​

HTML 的输出可以通过分区、标签页和导航结构，大幅降低长文档的认知负荷。​

​

分享便利​

Markdown 文件分享时往往需要借助第三方工具或作为邮件附件发送。而 HTML 文件只需上传，即可获得一个可直接分享的链接。同时可以在任意设备打开、浏览和引用。​

一份规格、报告或 PR 说明，如果是 HTML 格式，被实际阅读的概率要高得多。​

双向交互​

HTML 允许你与文档本身互动：添加滑块调节设计参数、切换算法选项观察效果变化、甚至生成可直接复制回 Claude Code 的提示词。​

​

​

​

通过 HTML 实现的可调参数面板，让「人机协作闭环」更加紧密。​

​

当需要的时候，这可以为我们手头特定问题创建一个专属的、一次性的编辑环境。​

数据摄入能力​

这是选择 Claude Code 生成 HTML 的最大原因之一：上下文摄入能力。​

Claude Code 可以读取整个代码文件夹、搜索 Slack 和 Linear（通过 MCP）、访问浏览器历史、检索 git 提交记录——然后将所有这些信息综合成一份结构清晰的 HTML 报告。​

​

例如，本文中的所有示意图，就是作者让 Claude Code 遍历自己的代码目录，找出所有生成的 HTML 文件，分类统计后自动生成的。​

​

二、五大实战场景​

场景一：规格制定与方案探索​

HTML 是 Claude 深入问题的丰富画布。当开始一个新任务时，作者会让 Claude 先进行头脑风暴，生成多种方案的探索页面；然后深入其中一个方向，制作 mockup() 和交互示例；最后输出一份完整的实施计划。所有这些文件都会保留下来，作为后续验证的上下文参考。​

提示词示例：​

​

我不太确定 onboarding 界面该走什么方向。生成 6 种截然不同的设计方案——在布局、语调和信息密度上做出区分——并将它们以网格形式排列在单个 HTML 文件中，让我可以并排比较。为每个方案标注它所做出的 tradeoff。​

​

场景二：代码审查与理解​

代码在 Markdown 中难以阅读，但在 HTML 中可以渲染 diff、添加行内批注、绘制模块依赖图和数据流图()。用 HTML 来理解 agent 写的代码、审查 PR、或向 reviewer 解释变更，效率远超纯文本。​

​

​

​

HTML 格式的 PR 审查报告，包含 diff 高亮、严重程度分级和流程图。​

​

提示词示例：​

​

帮我审查这个 PR，创建一个 HTML 形式的审查报告。我对 streaming/backpressure 逻辑不太熟悉，请重点分析这部分。渲染实际 diff 并添加行内边距批注，按严重程度用颜色编码，并补充任何有助于理解的可视化内容。​

​

场景三：设计与原型​

Claude Design 本身就是基于 HTML 的——因为 HTML 在设计表达上极其强大。无论最终产物是 React、Swift 还是其他框架，Claude 都可以先用 HTML 快速 sketch 出设计，再翻译成目标语言。动画、交互、滑块调参都可以在 HTML 中原型验证。​

提示词示例：​

​

我想原型化一个新的结账按钮：点击后播放动画，然后快速变成紫色。创建一个 HTML 文件，包含多个滑块和选项让我调试不同参数，并加一个「复制参数」按钮，方便我复制效果最好的配置。​

​

场景四：报告、研究与学习​

Claude Code 擅长跨多个数据源综合信息并生成易读报告。你可以让它搜索 Slack 对话、代码库、git 历史或互联网，然后将结果组织成一份长 HTML 文档、交互式讲解页面，甚至幻灯片/演示文稿。SVG 图表能极大提升复杂概念的可理解性。​

​

​

​

​

Claude 生成的交互式配置编辑器，支持表单验证、依赖检查和 diff 导出。​

​

提示词示例：​

​

我不理解我们的 rate limiter 是怎么工作的。读取相关代码，生成一个 HTML 讲解页面：token-bucket 流程图、3-4 个关键代码片段及批注、底部加一个「坑点」章节。为只读一次的人优化阅读体验。​

​

场景五：自定义编辑界面​

有些需求很难用文字框准确描述。此时可以让 Claude 构建一个「用完即弃」的专用编辑器——不是产品，不是可复用工具，而是一个为当前这批次数据量身定制的单 HTML 文件。​

关键在于：始终要提供一个「导出」功能——「复制为 JSON」或「复制为提示词」按钮——把你在 UI 里的操作转换回可以粘贴进 Claude Code 或提交到代码仓库的格式。你仍然保持在循环中，但循环变得紧凑得多。​

提示词示例：​

​

我需要重新排列这 30 张 Linear 工单。给我一个 HTML 文件，每张工单是一个可拖拽卡片，横跨 Now / Next / Later / Cut 四列。按你的最佳猜测预排序。加一个「复制为 Markdown」按钮，导出最终排序并为每列附上一句 rationale。​

​

三、常见问题​

Q: HTML 不会更耗 token 吗？​

虽然 Markdown 通常使用更少 token，但 HTML 的表达力更强、被实际阅读的概率高得多，整体产出质量反而更好。在 Opus 4.7 的 1M 上下文窗口下，token 增加几乎不会成为瓶颈。​

Q: 现在还用什么场景保留 Markdown？​

作者坦承自己已经几乎完全不用 Markdown 了——虽然这可能属于「HTML 极致派」的极端立场。​

Q: 这是否替代了传统「做计划」的方式？​

并非用一个计划替代，而是用多个 HTML 文件覆盖计划的不同阶段：一个用于实施规划、一个用于 UI 探索、一个用于设计清单。这些文件会长期保留，既供未来参考，也用于验证阶段提供上下文。​

​

​

四、结语​

以上所有原因归根结底只有一条：HTML 让大家感觉与 Claude 更加紧密地保持在同一个循环中。​

随着 Claude 承担的工作越来越多，作者发现自己阅读计划时越来越走马观花。他想要一种方式，能够真正参与到 Claude 的决策过程中，而不是简单地把任务丢给 AI。HTML 恰好做到了这一点。​

​