AI 编程真正的差距，不在模型，在你舍不舍得喂 Token

这两天有个说法在中文互联网传得很猛：

Token 要写进工资条了。

起因是黄仁勋最近在 All-In Podcast 上说了一段很炸的话。大意是：如果一个年薪 50 万美元的工程师，一年只用了 5000 美元 token，他会很警觉；如果连 25 万美元 token 都没吃到，他会“deeply alarmed”。他还打了个更狠的比方：这就像芯片设计师还坚持拿纸和笔，不肯用 CAD。

这话一出来，很多媒体立刻跟上了。

Tom’s Hardware 把重点落在“年薪一半都该拿去买 token”。 36 氪更直接，标题就叫《用多少词元（Token），要被写进工资条了》。

一下子，token 不再只是一个技术词。 它开始被翻译成：补贴、绩效、配额、生产力。

我觉得这波讨论里，最值得抓住的，不是“以后公司会不会按 token 管人”。

而是另一个更有用的判断：

Token 就是子弹，神枪手都是子弹喂出来的。

这波讨论为什么会突然火

因为黄仁勋说的，不只是“AI 很重要”。

他说的是一个更激进的东西：

优秀工程师的生产力，应该天然绑定大规模 token 消耗。

这背后其实是在改写一套老的成本观。

过去团队看 AI，很容易像看 SaaS 订阅： 能不能更便宜一点，额度能不能收紧一点，能不能少跑几轮。

但黄仁勋的意思不是这个。

他的意思更像：

如果一个高薪工程师没有用大量 token 去放大自己，那才是真的浪费。

所以中文媒体才会迅速把它翻译成“工资条”和“补贴”。

因为一旦 token 被看作生产力预算，它就不再只是 API 成本，而更像设备费、算力费、训练费。

36 氪那篇文章里还顺手串起了几件事：

阿里在给员工报销 AI 工具。 58 同城管理层直接说 Token 用得越多越好。 昆仑万维把 AI Coding 能力和工具使用纳入正式考核。

你会发现，话题已经不是“AI 编程工具好不好用”了。

而是：

企业到底愿不愿意把 token 当成正式生产资料。

但真正有价值的，不是“多花”，而是“多反馈”

说实话，我也不认同把 token 消耗直接拿来做 KPI。

社区里已经有人在吐槽了：token spend 很容易变成 vanity metric。 花得多，不等于产出高。 把“消耗额度”直接等于“工作表现”，很容易把人带偏。

这一点我同意。

但如果因此得出另一个结论：那就应该尽量省 token。

我觉得也错了。

因为在 AI 编程里，高手更费 token，往往不是因为他们更浪费。

而是因为他们更清楚，token 买到的不是答案，而是反馈密度。

你看一个成熟工作流，最吃 token 的地方，常常不是第一轮“帮我写个函数”。

真正烧得快的，往往是这些动作：

先让它拆 spec。 再让它给两个方案对比。 写完先自测。 再做一轮 review。 再换角度反驳。 最后再收口。

这时候你买到的，根本不是一段代码。

你买到的是一整轮迭代。

<figure><img src=“images/01-compare.png” alt=“01-compare”></figure>

研究也在指向同一件事：token 大头不在“首稿”，在“返工”

这也是我这次重写最想补的一块。

因为如果只讲体感，容易显得像立场先行。

但最近一篇 arXiv 论文《Tokenomics》分析了 30 个 agent 软件工程任务，结论很有意思：

平均下来，59.4% 的 token 花在 code review 阶段。

论文作者的总结更直白： agent 软件工程的主要成本，不在初次生成，而在后续的 refinement 和 verification。

这和很多人直觉相反。

很多人以为 token 都烧在“让模型写代码”这一步。

但真正把账单拉高的，往往是：

你让它补测试。 让它反复审查。 让它对照需求修正。 让多个 agent 互相找错。

也就是说，token 不是主要花在“开第一枪”。

它主要花在：校准、修正、确认命中。

所以我更愿意把 token 看成三类预算：

第一类：探索预算。 用来多试几个解法，不靠脑补。

第二类：验证预算。 用来 review、补测试、找反例、压边界。

第三类：流程预算。 用来把 AI 接进 spec、编码、review、测试，而不是偶尔问一句就关掉。

高手为什么更费 token？

很多时候不是因为他们更懂模型参数。

而是因为他们更舍得把 token 投在这三件事上。

所以，Token 确实是子弹，但不是让你乱扫射

这里最容易跑偏。

我不是在劝你无脑烧最贵模型。

多打子弹，不等于乱打。

真正好的打法，反而很像训练场。

1. 练习弹和实战弹要分开

不是每个环节都值得上最贵模型。

搜资料、改文案、整理格式、补注释，这些完全可以便宜一点。

但难 bug、架构拆解、关键 review、重要重构，这些地方就别抠。

如果你总让最便宜的模型做最难的判断，最后得出的不是“AI 不行”。

而是你的投喂方式不行。

2. 每次开火都要看弹着点

很多人 token 其实也没少花，但进步不大。

问题不在数量，在复盘。

你得知道：

什么任务先写 spec 再做会更稳。 什么任务适合先并行跑几个方案。 什么 bug 让模型先 review 比直接改更快。 哪些活适合全托管，哪些必须中途接手。

不复盘，token 只是消耗。 复盘了，token 才会变成训练。

3. 真正该省的，是低质量开火

最亏的情况，不是 token 花多了。

而是：

你明明该多试两个方案，却硬憋着。 明明该补一轮测试，却舍不得跑。 明明该让 agent 连续干下去，却还是把 AI 当搜索框。

看起来你在控制成本。

其实你是在放慢反馈速度。

而工程里最贵的，从来不是那点调用费。

最贵的是：

你多走的一天弯路。 你错过的更优方案。 你本可以并行验证，却被拖成串行的那几轮等待。

<figure><img src=“images/02-workflow.png” alt=“02-workflow”></figure>

最后一句

所以我对这波“Token 写进工资条”讨论的态度很简单：

别把 token 当荣誉勋章。 也别只把它当账单。

更好的理解是：

它是反馈预算。

高手更费 token，不是因为他们爱浪费。

而是因为他们知道，真正拉开差距的，不是会不会打开 Claude Code、Codex、Cursor。

而是你有没有建立起一套高频反馈回路：

敢试。 敢重来。 敢让 AI 多跑几轮。 也敢在关键节点下重注。

神枪手不是省子弹省出来的。

以前喂的是时间。 现在多了一种弹药，叫 token。

你现在最舍不得花 token 的地方，是哪一步？

参考来源：All-In Podcast transcript（Podscripts 镜像）；Tom’s Hardware（2026-03-23）；36 氪《用多少词元（Token），要被写进工资条了》（2026-03-27）；arXiv《Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering》。