Anthropic 正加速走向 token 破产

要点

⚠️ Anthropic 推动 HTML 输出，让 token 问题变得更严重，而不是更轻。
📊 在我的测试样例对比中，Opus 4.7 的输入 token 已经比 GPT-5.5 多了 58–59%。
📉 当 token 数膨胀到 1.35x 时，预填充计算量约增加 82%，可容纳的原始文本约减少 26%。
🔁 HTML 会让账单越滚越大：先生成更多 token，再在每次修改时把它们重新发回模型。
🧨 租用 xAI 算力只能缓解容量压力，不能解决 token 的成本问题。
🎯 Anthropic 需要先修好成本架构，否则 Claude Code 规模越大，越可能陷入利润困境。

⚠️ HTML 的主张很诱人，也很危险

Thariq Shihipar 在《HTML 超乎寻常的有效性》一文中提出了一个很有道理的产品观点：Claude Code 生成的产物如果采用 HTML，而不是 Markdown，就能更易于阅读、浏览和操作。

这些例子很有说服力。配套展示页列出了二十个自包含的 HTML 产物，涵盖规划、代码审查、设计、原型、图示、报告、研究和自定义编辑器。

从用户体验的角度看，我赞同。

但我觉得，大家对成本问题的讨论远远不够。

HTML 不只是“一份更好的文档”。它还意味着更多内容：标签、CSS、JavaScript、SVG、组件骨架、导出按钮、布局代码和交互状态。这些 token 每一个都要生成。然后，如果你想修改产物，很多工作流又会把它发回模型，再付一次钱。

隐藏的循环就在这里：

生成更丰富的产物，
审阅这个更丰富的产物，
提出修改要求，
把产物的大段内容重新发回去，
再生成一份庞大的产物，
如此反复。

对本来就有 token 膨胀问题的模型系列来说，这笔开销会在反复修改中越积越多。

📊 我之前的测试数据，已经指向了令人担忧的方向

在之前的文章《Opus 4.7 的输入 token 比 GPT-5.5 多 58%》中，我用 21 个测试样例做了受控对比，向 Claude Opus 4.7 和 GPT-5.5 提供完全相同的输入。

核心结果很直接：

完整基准测试提示词的 token 总数：Opus 21,374，GPT-5.5 13,504。
差额：Opus +7,870 个输入 token。
相对增加：Opus +58.28%。
原始文本 token 总数：Opus 18,644，GPT-5.5 11,749。
原始文本额外开销：Opus +58.69%。

普通文本和代码密集型材料都呈现出这个趋势：

普通行文：Opus 1,519，GPT-5.5 993（+52.97%）。
长文样例：Opus 2,290，GPT-5.5 1,386（+65.22%）。
代码密集型注释：Opus 428，GPT-5.5 240（+78.33%）。
Java 样例：Opus 1,305，GPT-5.5 802（+62.72%）。

这个基准测试可以通过公开的 token-count-compare 仓库复现。

这很关键，因为 HTML 产物通常更接近代码密集型文档或混合结构文档，而不是普通文章。它们有大量标点、嵌套语法，往往还包含 CSS 和 JavaScript。对于这类产物，token 消耗和上下文余量恰恰会成为产品约束。

📉 之前那篇 Opus 4.7 分词器文章，已经敲响了警钟

在《Opus 4.7 的 token 膨胀是真的，质量上的取舍也是真的》中，我把 Opus 4.7 看作一次推理服务系统的迁移，而不只是模型升级。

当时的具体计算就已经让人不安：

Opus 4.7 对同一份输入重新分词后，token 数可能达到原来的约 1.0x–1.35x。
膨胀到 1.35x 时，预填充计算量约增加 82%，因为注意力计算量近似随序列长度的平方增长。
KV-cache 内存占用约增加 35%。
有效上下文能容纳的原始文本约减少 26%。

那时还没有加上“智能体应该默认生成更丰富的 HTML 产物”这条建议。

现在，把这两件事放到一起看：

Opus 本来就有明显的输入 token 额外开销。
与 Markdown 或普通文本相比，HTML 会增大产物体积。
修改工作流往往会再次读入这个产物。
智能体编程循环本身已经包含工具调用、重试、差异内容、日志和记忆。

token 预算就是这样破产的：不是因为一个糟糕的提示词，而是因为成千上万个“改善用户体验”的决定，每个决定都让循环多装一点东西。

🔁 反馈循环，是这场讨论缺失的一节

HTML 主张中缺失的最大实践问题，不是“Claude 能不能生成漂亮的 HTML？”

它能。

真正的问题是：人怎样才能高效反馈，而不必一遍遍支付整个产物带来的额外开销？

用 Markdown 时，反馈通常很便宜：

改一下第二节。删掉开头。把这条往上挪。重写结尾。

用 HTML 时，反馈涉及的结构可能复杂得多：

用户可能需要指向某个视觉区域，而这个区域很难用文本清楚表达。
为了安全修改，模型可能需要完整的 DOM，或大段 HTML。
CSS 和布局调整可能牵动文件中相隔很远的部分。
交互元素需要 JavaScript 状态和行为，而不只是文字。
很小的视觉改动，也可能需要重新生成大量输出。

正确做法也许是：“用 HTML 作为渲染后的产物，但在底层保留一份更精简的权威源数据。”

例如：

把语义内容保存在 Markdown 或 JSON 中，
把 HTML 当作可以随时重新生成的展示层，
接受补丁式修改，而不是重写整个文件，
保留稳定的元素 ID，让反馈能精确指向目标，
要求模型输出差异，而不是整份文档，
把内容修改与布局修改分开。

如果没有这样的架构，HTML 会让每一轮反馈都变成更大的 token 账单。

🧨 租用 xAI 算力，修不好不合理的 token 成本结构

这就是近期 xAI/Anthropic 算力新闻值得关注的原因。

Simon Willison 在关于 xAI/Anthropic 数据中心协议的笔记中提到，Anthropic 与 SpaceX/xAI 达成协议，将使用“其 Colossus 数据中心的全部容量”。Tom’s Hardware 对同一消息的报道则是：SpaceX 出租了一台配备 220,000 块 Nvidia GPU、拥有 300 兆瓦 AI 算力的超级计算机的使用权。

增加算力可以扩充容量，却不会自动改善单位成本与收益。

如果产品使用方式鼓励用户生成更大的产物、为了反馈把更大的产物发回去、运行更长的智能体循环，并容忍更高的分词器开销，那么租来的算力就只是一只泄压阀，治不了根。

一个令人不安的可能性是：Anthropic 用增加供给来应对需求，却让 token 架构继续维持高成本。

到了 Claude Code 的规模，这种方式不可持续。

🎯 Anthropic 应该尽快修什么

我不认为答案是“别用 HTML”。

HTML 有用，用户体验上的收益也真实存在。

答案是：Anthropic 需要从设计上让丰富的产物节省 token。

但改进清单应该以证据为依据。我会把它收窄到三个站得住脚的要求：

公布产物的 token 成本账。 展示同一个 Claude Code 任务分别采用 Markdown、纯 HTML、带样式的 HTML 和交互式 HTML 时的 token 成本，再展示经过两三轮修改后的成本。没有这组对比，“HTML 的用户体验更好”就只讲了产品价值的一半。
降低 Opus 在标记语言和类代码输入上的 token 额外开销。 我之前的基准测试已经支持这一点：面对相同测试样例，Opus 4.7 比 GPT-5.5 多用了 58–59% 的输入 token，其中代码密集型注释的额外开销达到 +78.33%。
只有产物基准测试证实整份重写占据主要成本时，才优先采用补丁式修改。 我不该假定 Claude Code 总是在重新读入或重新生成整个文件。合理的要求更简单：测量整个循环，再优化最贵的部分。

在有直接证据证明它们确实是瓶颈之前，我会撤下那些更偏推测的建议：理解 DOM 的压缩方式、稳定锚点、规范化源模型，以及专门的 HTML 修改协议。

如果 Anthropic 想让 Claude Code 成为智能体编程的核心界面，这就不是打磨体验的小问题，而是基础设施的核心问题。

最后胜出的编程智能体，不会是那个只在一次生成中做出最漂亮产物的工具。

而是那个能让人持续参与迭代，同时不至于每当人说一句“改一下那部分”，就耗尽 token 预算的工具。

🧭 我的看法

Thariq 说得对：HTML 能让 Claude Code 显得好用很多。

但如果 Anthropic 推动 HTML 产物，却不解决修改成本，就等于加速冲向 Opus 4.7 已经暴露出的那个成本问题。

产品体验正在走向更丰富、更直观、交互性更强的智能体输出。

还没有答案的问题是：随着这些产物越来越大，修改循环还能不能保持低成本？

这是 Anthropic 应该公开测量的问题。

现在就解决它，别等“漂亮的 Claude 产物”成了掩盖巨额 token 额外开销的又一种方式。