一个小变化，很值得盯：有人开始不再让 Claude 默认输出 Markdown，而是直接要求它生成 HTML。

提出这个观点的是 Anthropic Claude Code 团队成员 Thariq Shihipar。Simon Willison 转述后也承认，自己过去长期偏爱 Markdown，但这次被说动了一点。

反常点在这里：Markdown 明明更轻、更干净、更适合开发者复制粘贴，为什么现在反而有人建议把输出交给 HTML？

答案不复杂。因为很多 AI 回答，已经不该只是一段文字了。

发生了什么：HTML 被拿来做临时解释界面

Thariq 的主张很具体：在向 Claude 请求解释、审查或分析结果时，HTML 可能比 Markdown 更有效。

他给的一个示例 prompt，大意是：让 Claude 创建一个 HTML artifact 来审查 PR，展示真实 diff，在边注里解释问题，用颜色标出严重程度，并重点讲清 streaming/backpressure 逻辑。

这就不是“把答案排版得漂亮一点”。

它更像把一次代码审查，临时做成一个小界面：左边看 diff，旁边看注释，颜色提示风险，必要时还有导航、折叠和图示。

HTML 的优势也在这里。它能放 SVG 图，能做页内导航，能加交互组件，能把复杂信息拆成可扫读的块。对 PR 审查、漏洞解释、架构分析、日志排查，这些都比一堵 Markdown 字墙更接近人的阅读方式。

Simon 还提到一个 copy.fail 上的 Linux exploit 解释实验：用 GPT-5.5 生成交互式 HTML 解释。效果不错，但 prompt 不够聚焦，模型花了不少篇幅解释 Python 外壳，而不是更集中解释漏洞本身。

这个细节比“HTML 很酷”更重要。

格式能增强表达，但不能替你明确意图。问题问歪了，页面做得再像产品，答案还是会跑偏。

为什么重要：Markdown 的旧优势还在，只是不再通吃

Simon 过去默认让模型输出 Markdown，有一个非常现实的理由：GPT-4 时代上下文窗口只有 8192 token，HTML 太贵。

标签、属性、样式，全是 token。Markdown 用几个符号就能表达标题、列表、代码块。那时省 token 不是审美选择，是硬预算。

现在情况变了。上下文窗口更大，artifact 这类承载方式更成熟，很多任务的瓶颈不再是“少生成几个 token”，而是“人能不能更快看懂”。

输出格式更适合的场景主要代价
MarkdownREADME、会议纪要、博客草稿、Issue、简单问答复杂结构、可视化和交互表达偏弱
HTMLPR 审查、架构解释、漏洞说明、日志排查、数据对比token 更重，依赖渲染环境，安全边界更复杂

所以别把这件事讲成“HTML 又赢了”。这太粗糙。

Markdown 仍然是低摩擦格式。能复制，能进 GitHub，能进文档系统，也更容易被版本管理和全文搜索吃进去。

HTML 的问题也实在。它更重，可移植性差一些。生成 JavaScript 交互页面时，还要考虑渲染环境和信任边界。尤其是安全分析场景，不能把模型生成的页面随手放进高权限环境里跑。

我的判断是：选择标准应该从“哪个格式更传统”换成“哪个格式能降低理解成本”。

简单内容用 Markdown。复杂关系用 HTML。

别把小票打印成海报，也别把地图念成散文。

谁该调整：开发者和技术写作者先动手

这件事最先影响两类人。

一类是 AI 工具重度用户和开发者。尤其是经常让模型看 diff、查日志、解释调用链、审查 PR 的人。

他们可以开始把 prompt 改得更像“界面需求”，而不是“作文需求”。例如要求模型输出：

  • 带目录的 HTML artifact；
  • diff 区域保留原始上下文；
  • 风险按严重程度配色；
  • 关键逻辑用 SVG 或流程图解释；
  • 每个结论旁边标明来自哪段代码或日志。

这不是花活。它能减少来回追问，也能让审查结果更容易被团队其他人读懂。

另一类是技术写作者、内部文档维护者和代码审查场景用户。他们要重新判断输出的终点是什么。

如果终点是 GitHub issue、README、知识库条目，Markdown 仍然省事。如果终点是一次复杂解释、一次复盘材料、一次临时演示页，HTML 更可能省读者的脑力。

团队落地时，我建议先从低风险场景试。

比如让模型生成本地可打开的静态 HTML，用来解释一个 PR、一次事故日志或一组数据对比。不要一上来接入生产系统，也不要允许模型生成的脚本拿到敏感权限。

“工欲善其事，必先利其器。”这句话放在这里很合适。但今天的“器”不是模型本身，而是模型把信息交到人手里的形状。

接下来该看什么：不是看 HTML 热不热，而是看承载层能不能成熟

我更在意三个变量。

第一，artifact 或类似承载层会不会变成主流工作流。

如果 AI 生成的 HTML 只能偶尔打开看看，它就是高级截图。如果它能被保存、分享、评论、回放、和代码上下文绑定，那才会进入团队流程。

第二，安全和权限边界怎么处理。

静态 HTML 和可执行脚本不是一回事。本地预览、沙箱运行、外链限制、敏感数据脱敏，这些都会决定它能不能在企业环境里铺开。

第三，模型能不能学会“少做装饰，多做结构”。

很多生成式页面最容易犯的错，是把时间花在渐变色、卡片和动画上，却没有把证据链、风险等级、上下文关系讲清楚。页面感强，不等于信息质量高。

这也是当前 AI 产品常见的尴尬：模型能力变强了，输出还挤在聊天框里。聊天框适合启动问题，不适合承载所有结果。

复杂信息被塞进线性对话，就像把一张系统架构图口述成一段话。不是不能用，是浪费人的注意力。

麦克卢汉说“媒介即信息”。放到这件事上，意思很直接：当输出从 Markdown 变成 HTML，变化的不只是外观，还是信息的组织方式。

过去，省 token 是第一优先级。现在，在很多复杂任务里，降低理解成本更值钱。

所以这次真正该试的，不是让所有回答都变成 HTML。

该试的是：当一个问题需要图、层级、证据、风险和导航同时出现时，别再逼 AI 只写一段顺滑的文字。

人不是按 token 阅读世界的。人按结构理解世界。