Anthropic 内部不用 Markdown 了——但我可能还是会继续用

今天看到一个挺有意思的开源项目，叫 HTML Anything。它的思路很简单：把任意数据源都转成 HTML，让 AI 直接消费 HTML 格式的内容。

这个项目的出现并不是孤立的。最近网上能看到一股潮流——Anthropic 的开发者公开说，他们内部已经不再使用 Markdown，全都改用 HTML 了。

听起来很有说服力。Anthropic 是做 AI 的，他们自己用什么格式喂给模型，应该是反复验证过的。

但我有点不一样的想法。

HTML 看起来更好的理由

我能理解他们为什么这么做。HTML 比 Markdown 表达力强：

如果你只看”信息表达的完整性”，HTML 确实是赢家。

问题是，AI 时代不能只看表达力，还要看 token 成本。

Markdown 的字符密度非常高。# 标题 几个字符就是一个 h1，**粗体** 四个字符就是一段强调。同样的内容如果换成 HTML，光是 <h1></h1> 就要 9 个字符，再加上 class、style、属性，token 量很容易翻几倍。

我们平时用 Claude Code 或者 Codex 写代码，本质上是让 AI 读一堆文本，然后理解、改写。如果所有页面、所有文档、所有上下文都换成 HTML，一次会话能塞进去的内容直接被压缩了——你本来能装 20 个文件的上下文，现在可能只能装 8 个。

更糟的是，要让 HTML 真正”好用”，光裸的标签是不够的，还得带上 CSS、属性，有时候还得带样式。这些东西对 AI 理解内容几乎没有帮助，但每一个字符都在烧你的 token。

我们本来用编程工具，只需要让 AI 访问纯文本。现在变成访问 HTML，每一次访问都比以前贵几倍。这件事不算账的话感受不到，一旦真的跑起来，token 用完的速度会让你心疼。

有人会说：“Anthropic 都这么做了，肯定是验证过的。”

我同意他们验证过。但要看到一个前提：

Anthropic 内部用 token 的成本，跟你和我用 token 的成本，根本不是一回事。

他们用的是自家模型，边际成本几乎为零。他们做实验、对比效果，发现 HTML 在某些任务上更准确——这是他们能得出的结论。但这个结论里面，没有把 token 价格当成约束条件。

而我作为外部开发者，每一次 API 调用都是真金白银的账单。如果 HTML 让准确率提升 5%，但成本翻倍，那这件事在经济上就走不通。

技术上更好，不等于经济上可行。这是两件事。一个好的方案如果跑不起来，那它就不是一个好的方案——至少不是对我而言的好方案。

我不会因为某家公司的开发者说什么就立刻跟。这种事必须自己跑一遍才知道。

我现在的初步判断是：

对绝大多数独立开发者和小团队来说，第二种场景更常见。我自己用 Claude Code 和 Codex 的方式，绝大部分时间都在第二种场景里。

所以我大概率会继续用 Markdown。哪怕 Anthropic 的人说 HTML 更好——这话对他们成立，不一定对我成立。

如果项目里真的需要 HTML（比如最终要渲染成网页、要生成富文本），我会这么处理：

写代码、读代码、处理上下文——继续用 Markdown，让 Claude Code 或 Codex 在最低 token 成本下工作。

只有真正需要”产出 HTML”的那一步，把这一步单独拆出来，交给一个更便宜的第三方 API（甚至是开源模型）去做。这一步任务很窄，输入是结构化数据或者 Markdown，输出是 HTML，不需要顶级模型的推理能力，用便宜的 AI 完全跑得动。

这样一来：

从经济学的角度看，用顶级模型去吐 HTML 标签是最浪费的一件事。它的脑力应该用在理解代码、设计方案、跨文件改动上，不是用来打 <div class="...">。

我可能是错的。但”我可能是错的”和”我应该跟着别人走”是两回事。

权威能告诉你什么是技术上最优的，但只有你的账单能告诉你什么是你能负担的。

在自己的项目里跑一遍，看看 token 账单的变化，再决定要不要跟潮流。别因为别人说 HTML 好就立刻全换——尤其当你不是 Anthropic。