Claude Code 与 HTML Artifacts 的不合理有效性
Markdown 赢得了 agent 协作的第一阶段,因为它足够简单。
它容易生成、容易 diff、容易粘贴到 pull request 里,也足够胜任大多数笔记。因此它自然成了 coding agents 的默认输出格式:计划、总结、规格说明、评审笔记、事故复盘和实现清单,最后都变成了 Markdown。
Anthropic 最新的 Claude Code 文章指出,这个默认选择开始显露边界。
重点不是 Markdown 不好,而是 Claude Code 现在能做的事已经不只是写一篇很长的文本文件。HTML 给模型提供了更好的工作表面:更高的信息密度、更清晰的视觉结构、更容易分享的 artifacts,以及轻量级交互。
对开发者来说,这是一个很实际的变化。它改变了我们应该让 Claude Code 产出什么。
核心观点
在官方文章中,Claude Code 团队的 Thariq Shihipar 解释了为什么他开始在许多 Claude Code 输出中更偏好 HTML 文件,而不是 Markdown。
原因很直接:随着 Claude Code 承担更大的任务,输出本身也会变得更大。
30 行的 Markdown checklist 没问题。300 行的实现计划、研究报告、代码评审、架构解释或 UI 探索,即使技术上能渲染,也不代表它适合阅读。
HTML 给 Claude Code 更多空间来组织同样的信息:
- 用表格做高密度对比
- 用 CSS 建立视觉层级
- 用 SVG 画图
- 用图片展示引用
- 用 JavaScript 做本地交互
- 用标签页和章节做导航
- 用按钮复制生成的 prompts、JSON、diff 或设置
这让 HTML 不再只是文档格式,而更像一次性的工作台。
对 agent 工作流来说,这个区别很重要。
为什么这对 Claude Code 用户重要
Claude Code 和普通聊天界面不同,因为它能读取本地项目、检查 git 历史、操作文件、使用 MCP servers,并且能在真实工程 workspace 里生成 artifacts。
这让它非常适合基于真实上下文创建有用的 HTML artifacts。
例如,与其问:
Write a plan for refactoring the billing module.
你可以问:
Create an HTML artifact that explains the billing refactor.
Include a module map, the key file changes, risks by severity,
a staged migration plan, and a copyable implementation prompt.
这两个 prompts 背后的请求可能相同,但第二个请求的是一种更容易检查、更容易分享,也更容易在后续 Claude Code 会话中作为参考使用的格式。
这才是真正的优势:HTML 可以变成持久的项目上下文,而不只是一次性的回答。
HTML 胜过 Markdown 的四类场景
1. 规格说明与计划
规划是 Markdown 最先开始吃力的地方。
长实现计划通常会混合架构、代码片段、依赖关系、图表、权衡、截图和开放问题。Markdown 可以承载这些内容,但它并不会帮助读者导航。
HTML 可以让 Claude Code 把计划拆成更易审查的界面:
- 顶部概览
- 系统流程图
- 按文件列出的变更地图
- 风险表
- 分阶段 rollout 计划
- 未解答问题
- 可复制的后续 prompts