HTML 作为 LLM 输出格式的非凡效能

多年来，Markdown 一直是 LLM 通信的金标准。其简单性、可读性和普及性使其成为智能体（agents）交付代码、解释和文档的自然选择。然而，Claude Code 等工具的高级用户中出现的一种日益增长的趋势表明，范式正在发生转变：HTML 作为主要输出格式的“非凡效能”。

开发者不再将 HTML 视为最终的部署目标，而是越来越多地将其作为中间产物的媒介——可丢弃的 UI、交互式仪表板和复杂的验证工具——这些产物提供了静态文本根本无法比拟的清晰度和实用性。

超越静态文本：选择 HTML 的理由

Markdown 的主要局限性在于其线性。虽然它非常适合结构化文本，但在处理高密度信息和交互性方面却显得力不从心。通过提示 LLM 输出一个没有任何依赖项且样式稀疏的单个 index.html 文件，开发者正在解锁几个关键优势：

1. 交互式验证与工具化

与其阅读一份描述重构过程的 500 行 Markdown 文件，开发者现在会让智能体构建“评审仪表板”。这些是本地 HTML 页面，允许用户可视化更改、与状态管理模型进行交互，甚至对提议的架构进行轻量级模拟。

正如一位开发者所指出的，使用 HTML 允许他们使用 JavaScript 来模拟 TypeScript 应用中的状态管理，并利用 ts-morph 来映射调用点。这使得静态规范变成了一个“验证导向”的文档，将通常需要数天的过程缩短到了几小时。

2. 视觉密度与认知负荷

长篇 Markdown 可能会变成难以解析的文本墙。HTML 允许视觉密度——使用标签页、网格和交互式元素来组织信息。这对于复杂问题特别有用，因为单个评审单元可能跨越多个文档。通过创建一个自定义的本地网页，智能体可以为评审大规模更改提供一个合理的设置，而无需用户管理多个窗口或 macOS spaces。

3. 可移植性与“氛围编码”（Vibe Coding）

“单文件应用”的方法具有某种优雅感。一个工具可以被构建、发送给同事，并在任何浏览器中打开，无需服务器或安装。这催生了一种“氛围编码”的形式，其目标是快速原型化一个功能性工具或可视化器，使其本身就充当文档。

权衡：HTML vs. Markdown

尽管有这些优势，向 HTML 的转变并非没有摩擦。社区已经强调了几个开发者必须考虑的关键权衡：

Token 效率与成本

HTML 比 Markdown 显著更加冗长。这会导致更高的 token 消耗，从而增加响应的延迟和 API 调用成本。对于某些人来说，这是为了获得“平方级的清晰度”而付出的微不足道的代价，但对于其他人来说，这是一个显著的开销。

共同创作与可编辑性

Markdown 最强有力的论情点之一是它专为人类-AI 共同创作而设计。人类可以轻而易举地跳入一个 .md 文件并微调一句话或添加一个项目符号。相比之下，HTML 对人类手动编辑起来要困难得多。这存在将工作流从“协作”转向“委派”的风险，即人类只是提示 AI 进行更改，而不是直接编辑内容。

维护与版本控制

虽然可丢弃的 HTML 是有用的，但长期维护这些产物具有挑战性。HTML 的版本控制比纯文本更繁琐，且更新样式或布局通常需要重新生成整个文档，这可能会引入内容中出现幻觉的风险。

其他替代方案

并非所有人都认为 HTML 是答案。为了弥合纯文本与完全交互性之间的差距，出现了几种替代方案：

• 结构化数据 (JSON/XML): 一些开发者已转向使用 JSON 编写规范，以实现静态分析。这允许他们使用自定义 schema 来验证不同文档之间的数据库字段是否匹配，从而提供了一种 HTML 或 Markdown 都无法提供的严谨性。
• 增强型 Markdown: 像 sdocs 这样的工具试图在保持 Markdown 作为源码的同时，提供即时的浏览器端渲染体验，包括对 Mermaid 图表等交互式元素的支持。
• 高级文本格式: 其他人则推崇 Org-mode 或 AsciiDoc，它们提供了比 Markdown 比更强大的结构化能力，同时比 HTML 更易于人类编辑。

结论

重新发现 HTML 作为主要的 LLM 输出格式，代表了我们对“文档”认知的转变。我们正在从“文档是静态记录”的想法转向“文档是功能性工具”的想法。虽然 token 成本和可编辑性障碍仍然存在，问题在于将复杂的技术计划转化为交互式、可链接且可视化的产物，事实证明，对于那些管理高复杂度系统的人来说，这是一种不可抗拒的升级。