Token降价90%但我的AI账单没降：Jevons悖论在起作用

Token 价格降了 90%，我的 AI 账单却没降。以下是我做出的改变。

2023 年以来，Token 价格下降约 90%。企业 AI 支出却增长约 320%。

这两个数字同时成立。如果你跑过任何形式的 Agent 循环，你已经感受到了。😅

这不是计费 bug。这是 Jevons 悖论，过去两年它一直潜伏在每个 AI 预算的幕后。

160 年前的解释

1865 年，William Stanley Jevons 注意到，随着蒸汽机效率提升，英国并没有减少燃煤量，而是烧得更多了。更便宜的能源使新应用变得可行，新应用推动消费，总支出上涨而单位成本下降。

Token 的运作方式完全相同。只不过 Token 的效应更强，因为便宜的 Token 不仅让现有工作变得更便宜，还让一整类架构成为可能——而两年前没有人会为这些架构付费。

当百万 output Token 花费真金白银的时候，没有人会跑一个 20 步的自主循环。现在人人都在跑。

为什么 Agent 会让账单翻倍

聊天调用是一次性的。你问，模型答，完成。可能就几千个 Token。

Agent 不是这样工作的。它运行在循环里：思考、行动、观察、调整、重复。每一步都会重新加载至今的全部对话内容，因为模型在调用之间没有记忆。第 12 步在为第 1 到 11 步付费。

所以消耗并不随结果线性增长。更像火箭燃料：要飞得更远一点，需要多得多燃料。

高盛预测，到 2030 年全球 Token 消耗量将增长约 24 倍，主要由 Agent 驱动。这个数字听起来很荒谬，直到你算一下自己某个会话中的重新加载次数。

顺带一提，这也是上下文膨胀不是 cosmetic problem 的原因。你塞进上下文的每个不必要的文件，每次循环迭代都要付一次费，不是每个任务付一次。我专门为 Claude Code 写了一个小插件来解决这个问题，因为默认行为是每轮都重新发送所有内容，这悄悄成了我整个设置里最贵的一笔开销。

推理模型处理trivial任务

第二个乘数是 thinking 部分。推理模型在吐出第一个可见字符之前，会生成数千个内部 Token。在难题上这正是你想要的，输出也确实更好。

在"把这个变量重命名"上，这就等于在烧钱。

这里的问题不在模型。大多数设置里只配了一个模型处理所有事情，所以贵的模型也干了 trivial 的活。单次调用你感觉不到。月底你才感觉到。

管理者实际看的数字是错的

AI 生成代码的接受率大约在 80% 到 90%。在幻灯片上看起来很棒。

这也并不意味着代码就上线了。

GitClear 跨越 2.11 亿行变更的纵向研究发现，代码 churn——即两周内被回滚或重写的行——在 AI 助手出现前稳定在约 3.3%，现在大约翻了一倍。复制粘贴的行首次超过重构的行。AI 撰写的 PR 每个 PR 携带明显更多的问题。

网上流传着更夸张的数字，比如某图表声称每个 AI 编程美元只有 $0.18 变成了上线价值。我对那个数字持保留态度。它来自单一平台自身数据，不是审计过的基准。方向是对的，但精度不适合放进董事会演示文稿。

但底层观点成立，也与我观察到的一致：贵的不是生成，是生成之后的循环。修边缘情况。重写半个 diff。review 一个改了三个没人要求的文件的变更。

花在下一 sprint 就会被重写的代码上的 Token，不会因为 Token 便宜就变便宜。它们是带账单的纯粹损失。

所以真正的杠杆是路由

不是纪律。不是"少用 AI"。让团队少用 AI 只会把你想买的生产力还回去。

杠杆是哪个模型处理哪一步。

这是我当前的 /implement 循环，从 Linear 拉任务到 Done：

Opus 规划并编写生产代码

Cursor Composer 2 写测试，做第一轮 review

Sonnet 在浏览器里点一遍验证它能工作

Codex 做里程碑 review

背后的规则很简单。贵的模型运行在错误比 Token 成本更高的地方。其他地方用更便宜的。

规划和生产代码是坏决策会向下游传导的地方，所以那里我付费。测试脚手架、机械重构、浏览器验证：这些都不需要前沿层，用在那里什么都买不到。

把规划步骤交给便宜模型。

我试过，因为理论上它是最大的一项。结果反而更贵了，不是更便宜。弱的规划意味着你要重写实现，而重写正是烧钱的部分。你在一个调用上省了钱，在接下来的十二个调用上付回去。

同样的教训换了种形式：前沿模型三个回合搞定任务，总成本可能比需要十二个回合的budget模型真正花得更少，因为每个额外回合都要重新发送整个上下文。便宜模型只是单次调用便宜。

另一件无效的事是手动切换模型。两个终端，在之间复制 diff，搞不清哪个有最新状态。最后我写了个插件桥接 Claude Code 和 Cursor Composer 2，让交接在一个地方完成。灵感大量来自 openai/codex-plugin-cc，它用 GPT 做了同样的事。该表扬就表扬。

没人发的无聊部分

知道何时让 Agent 停下。

知道何时剥夺它的自主权，给它一个更窄的任务。

知道什么时候自己写更快。

这些在演示里都不起眼。但在一个 AI 设置能自我造血还是一个以更高价格产出相同输出的 AI 设置之间，恰恰是这些造成了差别。

我实际追踪的

不是消耗的 Token。这个指标已经被比我大得多的公司在规模上测试过了，结果是 Goodhart 定律进入生产：一旦消耗成为目标，它就不再测量生产力，只测量账单。

我关心的是 Agent 产出的内容有多少经过了 review 并最终 deploy。这个数字更难拿到，但它是回答这一切是否有效的唯一指标。

当前开发者的价值不在于产出的代码行数，而在于控制代码生成的那些架构。

如果你在生产环境跑 Agent：你是在追踪 Token 消耗，还是追踪实际上线了什么？很好奇其他团队怎么处理这个问题，因为我不认为有人有干净的答案。