Markdown 与 HTML 本质是不同目标下的两种语言
输入用 Markdown，输出用 HTML，各司其职才是正解。
上周，Anthropic Claude Code 团队工程师 Thariq Shihipar 发了一篇帖子，标题叫《The Unreasonable Effectiveness of HTML》，中文翻译：《HTML 强得没边》。配套 20 个示例文件，说团队内部已经在用 HTML 替代 Markdown 作为 AI 的主要输出格式。
很多人读完的第一反应是：Markdown 要被取代了吗？
但我觉得这个问题本身就问错了。Markdown 和 HTML 从来不是同一场比赛里的对手，它们服务的是工作流里完全不同的两个环节。
Markdown 更适合输入
Markdown 最初是为人类手写内容设计的，简洁、纯文本、版本控制友好。把它作为 AI 工作流的输入侧格式，优势是真实存在的：
- 省 Token
同一份内容，Markdown 的 token 消耗通常只有 HTML 的 1/2 甚至 1/3。早期的 GPT-4 只有 8192 token 上下文，所以 Markdown 是工程上完全合理的选择，省下来的 token 预算可以塞更多有效信息。
- 易维护、易版本控制
Markdown 文件 diff 干净，git 审查友好，grep 搜索直接，任何编辑器打开就能改。HTML 一旦带上样式，diff 噪音大，维护成本高得多。
- 模型读得准，理解无损耗
大语言模型在 Markdown 语料上训练充分，结构识别稳定。背景文档、知识库、README、设计注释用 Markdown 喂进去，模型的理解效率更高，不会因为标签解析分心。
- 写提示词的原生语言
System prompt、Skills、用户个性化指令、上下文片段，用 Markdown 写结构清晰，人类好改，模型好懂，改了之后立刻能看到效果。这是提示词工程里的事实标准。
总结：Markdown 的优势在于写和维护的一侧。人写得快，机器读得准，改起来便宜，这三点在输入环节都是实打实的价值。
HTML 为什么适合输出
- 问题出在输出侧。
Markdown 渲染之后对短内容来说很好看，但 AI 生成的输出动辄几百行，渲染后依然是一堵从上到下的线性文字流，没有层级，没有跳转，没有可交互的空间。人类面对这种输出，往往扫一眼然后关掉，很少真正读完。
Thariq 的观察就在这里：Markdown 渲染得再好，也只是“格式化的文字”；HTML 的输出则可以是“空间化的界面”。二者的差距不在于视觉美观，而在于信息的组织方式。
- 空间结构，而不是线性流
方案对比可以并排，不用靠大脑 diff 两段文字。代码 diff 可以带边注和严重程度染色，一眼看出应该 focus 哪里。信息可以分层，用 Tab、折叠、跳转链接组织，读者自己选择深度。
- 交互，而不是静态文本
动效和交互只能被感受，不能被描述。一个带真实缓动曲线的动画沙盒，五秒告诉你的东西，整段文字做不到。一致性哈希讲解配上可以加减节点的交互环，比任何文字直观。
- SVG 图形原生支持
Markdown 里嵌不了矢量图，HTML 里 SVG 是一等公民。AI 可以直接内联绘制流程图、架构图、数据图表，而不只是用文字描述这里应该有一张图。
- 可以被喂回，形成闭环
HTML 输出可以直接作为下一条 prompt 的输入，也可以被其他 Agent 读取，充当共享内存。一个渲染出来的色板，比一个 JSON token 清单，更容易让人指着说「改这里」，然后继续工作。
生成成本是 Markdown 的 2 到 4 倍，但在上下文窗口动辄几十上百万 token 的今天，省 token不再是输出格式的第一优先级，易读且直观才是。约束变了，最优解自然也变了。
核心观点
输入用 Markdown，输出用 HTML。
前者省 token、易维护、便于人改和机读；后者可视化、可交互、空间化，形成真正可交付的产出物。二者各有擅长的环节，没有谁绝对好，也没有谁绝对坏。
横向对比
| Markdown | HTML | |
|---|---|---|
| Token | 消耗低，适合长上下文输入 | 高 2–4 倍，但输出场景可接受 |
| 版本控制 | 干净，git diff 友好 | 噪音大，不适合人工维护 |
| 长内容可读性 | 渲染后是线性文字流，篇幅越长越容易被跳过 | 可分层、可折叠、可跳转，信息密度高 |
| 交互能力 | 无 | Tab、折叠、滑块、SVG、可拖拽等 |
| 维护成本 | 低，任意编辑器可改 | 高，适合交付即止的产出物 |
| 最适合的环节 | 提示词、知识库、文档输入 | 规划、审查、报告、工具交付 |
在工作流里怎么切换
输入侧继续用 Markdown，输出侧只需在 prompt 末尾加一句话，就能拿到完全不一样的产出物：
方案对比
Give me a side-by-side comparison of three approaches with trade-offs called out inline. Output as a self-contained HTML file.
帮我并排对比三种方案，把权衡点内联标注出来。输出为单文件 HTML，可直接在浏览器打开。
完整示例：thariqs.github.io/html-effectiveness/01-exploration-code-approaches.html
代码审查
Help me review this PR. Render the diff with inline annotations, color-code findings by severity. Output as a self-contained HTML file.
帮我审查这个 PR。把 diff 渲染出来，带边注，按严重程度染色。输出为单文件 HTML。
完整示例：thariqs.github.io/html-effectiveness/03-code-review-pr.html
技术讲解
Explain [concept] with a TL;DR box, collapsible steps, tabbed code snippets, and a hover-linked glossary. Output as a self-contained HTML file.
解释 [概念]，包含 TL;DR 摘要框、可折叠步骤、tabbed 代码示例和 hover 联动词汇表。输出为单文件 HTML。
完整示例：thariqs.github.io/html-effectiveness/15-research-concept-explainer.html
这场讨论背后更大的趋势
Thariq 的帖子之所以能引爆讨论，不是因为HTML 比 Markdown 好这句话有多惊人，而是因为它触到了一个更大的转变：AI 正在从生成文本向生成可交互 Artifacts演进。
聊天框是一种界面，但它是为对话设计的，不是为交付设计的。当 AI 要给你一份规划、一个组件库、一篇审查报告时，对话框是个糟糕的展示容器，把所有东西都压平成一条消息流。
HTML 文件是单文件、自包含、浏览器直开，它不是聊天记录，它是一个可以独立存在的产出物，可以被人修改，可以被下一个 Agent 读取，可以直接发给协作者，三个月后打开还看得懂。Markdown 在输入侧依然无可替代，但在输出侧，它从来就不是终点。
Markdown 不会死。它在自己擅长的地方，依然是最省力的选择。
但如果你还在用 Markdown 接收 AI 的长篇输出，不妨换一次格式试试看。区别不在于哪个格式更好，而在于这个场景下用这个效率会更高。
参考来源：
- The Unreasonable Effectiveness of HTML
— thariqs.github.io/html-effectiveness
- Thariq's Post on X
— x.com/trq212/status/2052809885763747935