Tokenmaxxing 辩论没有抓住要点

Source: Dev.to

请提供您希望翻译的正文内容，我将把它翻译成简体中文。

介绍

Jensen Huang 说，每位工程师每天应该消耗 100,000 个 token。
Shopify 的首席技术官说，真正的指标是你如何使用它们。两者皆是正确的。两者亦都危险。

Tokenmaxxing 叙事

“tokenmaxxing” 讨论在黄的主题演讲声明后迅速升温：如果你的年薪 20 万美元的工程师一年没有消耗六位数的 token，你就没有充分利用 AI。逻辑看似合理——token 越多 = AI 辅助越多 = 生产力越高。但事实并非如此。

Shopify 的 Mikhail Parakhin 负责运营全球最 AI 密集的工程组织之一。他们的内部数据表明，2025 年 12 月是一个拐点，日活跃使用量出现垂直上升。然而，分布极度倾斜：前 10 % 的用户消耗的 token 量呈指数级高于后 75 % 的用户。如果这种趋势持续下去，最终会出现 “一个人消耗所有 token” 的局面。

这就是原始使用量指标的问题所在：它们优化的是动作，而不是进步。

反模式：令牌密集型工作流

Parakhin 描述了一种 并行运行多个相互不通信的代理 的反模式。这会高效地消耗令牌——如果你的目标是燃烧令牌的话。没有迭代的并行生成不过是昂贵的掷骰子。

实际上，根据 Shopify 的数据，深度优于广度 才有效：

• 串行研究循环 —— 一个代理构建，另一个使用不同模型进行批评，第一位根据反馈进行修订。
• 更高的延迟，产生更高质量，减少在死胡同上浪费的令牌。

这映射到生产系统：基准分数最高的编码模型往往会产生臃肿的差异（例如，GPT‑5.4 过度编辑；Opus 4.6 欠编辑）。真正重要的评估指标不是 pass@1 —— 而是修复是否需要触及三个文件还是三十个文件。认知复杂度胜过令牌计数。

将令牌预算制度化为关键绩效指标

当令牌预算成为关键绩效指标时，工程师会开始针对该指标进行优化：

• 微服务的复兴 – 让团队能够独立发布，并在并行情况下消耗更多令牌。
• PR 审核队列堵塞 – 并非因为人工审查慢，而是 AI 生成代码的量超出了任何审查能力。

Shopify 的内部解决方案是把更多资源花在审查上，而不是生成上。他们的 批评‑生成令牌比例 故意与大多数团队相反。验证使用最强大的模型（Opus 4.6、GPT‑5.4 Pro），而生成则既便宜又快速。验证过程则慢且昂贵。

转变度量标准：从消费到结果

方向正确的论点是我们需要在开发循环中投入更多的 AI 计算，但把它表述为“每位工程师的 token 预算”会产生错误的激励。它暗示消费是目标，而不是结果。

这与 2000 年代的代码行数（LOC）度量类似。我们痛苦地认识到，代码越多意味着 bug 越多、维护成本越高、技术债务越大。当我们开始衡量环路复杂度、测试覆盖率和部署频率时，LOC 就不再是虚荣指标。Token 消耗也需要同样的演进。

关键在于已部署价值与 token 支出的比例。

• 一个 50 token 的提示修复了生产事故，胜过 50,000 token 的投机性架构探索。
• 一个在合并前捕获安全缺陷的批评循环，其价值超过十个并行代理生成的竞争实现。

基础设施的赌注不仅是更大的上下文窗口或更便宜的推理，而是 基于追踪的评估系统，能够理解到底是什么真正推动了成果。Parakhin 指出，Shopify 正在围绕以下内容构建内部遥测：

• PR 合并速度
• 每次 AI 生成变更的回滚率

——而不是“每位工程师消耗的 token”。

正确方法的好处

正确实施的团队能够获得叠加的优势：

• 代码库更整洁，因为批评代理防止了混乱。
• 部署流水线更快速，因为审查瓶颈被自动化处理，而不会被压垮。
• 工程师将 token 用于收敛的迭代循环，而不是分散的并行分支。

如果你在本季度制定 AI 预算，考虑换个角度提问：

• 与其问“我们能负担多少 token”，不如问 “我们的批评‑生成比例是多少？”
• 与其跟踪消耗量，不如跟踪 从提示到产出的转化率。

结论

Tokenmaxxing 是一个陷阱。获胜的团队是 令牌最小化者——最大化每个令牌的输出，而不是每美元的令牌数。