Claude Code 核心团队成员 Thariq 最近发了一篇长文，解释为什么他和团队越来越倾向于用 HTML 代替 Markdown 作为主要输出格式。这不是技术选型的细枝末节，而是一个关于 AI 时代人机协作界面的根本判断。
Markdown 曾经够用，现在不够了
Markdown 的黄金时代是人类自己写、人类自己读的时代。它便携、有基本的富文本能力，人类用少量标记就能组织结构。但 Thariq 观察到，当 AI 开始代替人类大量生成内容时，这套格式的局限就暴露了：
超过一百行的 Markdown 文件，实际阅读率趋近于零。Thariq 坦言，他自己懒得读，团队成员更不会读。ASCII 图、Unicode 颜色字符、伪代码块——在 Markdown 里凑合表达的信息，读者其实根本吸收不了。
HTML 为什么更有效
HTML 能承载的信息密度远高于 Markdown，不仅能做标题和格式，还能：
- 表格：直接渲染结构化数据
- SVG 图：Claude 可以画出真实的图表，而不是用字符凑
- CSS 样式：视觉层次一目了然
- JavaScript 交互：滑块、开关、拖拽排序——把你调参的结果直接导回到 Prompt 里
- 绝对定位 + Canvas：空间数据的可视化
- 响应式布局：根据屏幕大小自动调整，手机和电脑都能舒适阅读
Thariq 提了一个很具体的场景：你让 Claude 生成 6 个不同风格的设计方案，Markdown 只能给你描述，HTML 可以做成一个并排对比的网格，你一眼扫过去，优劣立现。
实际工作流：从头脑风暴到实现计划
Thariq 描述了一种他日常使用的工作流：
- 让 Claude 先头脑风暴，生成一组 HTML 探索文件
- 选中一个有潜力的方向，继续扩展，做 mockup 或代码片段
- 最后生成一份 HTML 实现计划，包含数据流图、关键代码片段和可视化结构
- 开一个新 session，把这组 HTML 文件全部传进去，让 AI 基于完整的上下文开始实现
验证环节同样如此——让验证 Agent 读取这组 HTML 文件，它获得的信息量远比一个 Markdown 文件大得多。
那些具体的用例
代码审查：默认的 GitHub diff 体验很差。让 Claude 生成一份 HTML 代码解释器，渲染 diff 本身，加上行内注释、色标严重程度，PR reviewer 打开链接就能理解。
原型设计：你想调一个 checkout 按钮的动画曲线。让 Claude 生成一份 HTML，拖动滑块实时预览效果，点"复制参数"按钮，把调好的数值直接粘贴回 Claude Code。
信息汇总报告：让 Claude 读取你的 Slack、代码库、Git 历史和互联网，生成一份可读性极高的 HTML 研究报告，配有 SVG 流程图。不再是给老板写周报，而是给老板做一个能翻阅的交互文档。
任务排序：把 30 个 Linear 工单做成可拖拽的卡片，拖到 Now / Next / Later / Cut 四列里，预排好顺序，加一个"导出为 Markdown"按钮，导出来直接带每项的理由说明。
几个真实的问题
Token 效率更低？ 是的，HTML 比 Markdown 多消耗 2-4 倍 Token。但 Thariq 的计算是：信息被读进去的概率也高了好几倍，产出质量随之提升，在 100 万 Token 上下文的 Opus 4.7 里，这个开销不值一提。
版本控制麻烦？ 这是 HTML 最大的缺点——diff 噪声大，不好 review。Thariq 坦承这一点。
需要写很多 Prompt 吗？ 不需要。你只需要说"生成一个 HTML 文件"或"做一个 HTML artifact"，剩下的由 Claude 完成。真正重要的是你自己知道这个 artifact 要解决什么问题、怎么使用它。
真正的原因
Thariq 在文末说了一句话，比前面所有技术分析都值得记住：
"我真正喜欢 HTML 的原因是，它让我感觉和 Claude 的协作更加紧密了。我曾经担心因为不再深入阅读计划文档，只好让 AI 自己做决定。但事实恰恰相反——使用 HTML 之后，我比以前任何时候都更有参与感。"
这才是核心。Markdown 是异步的、单向的、给人设计的。HTML 是交互的、双向的、给 Agent 设计的。当 AI 能生成一个你真的愿意打开的文件时，协作才真正开始。