“Token绩效”的黄昏：当“用AI”本身变成一场表演

“Token绩效”的黄昏：当“用AI”本身变成一场表演

上一篇文章讨论的是招聘端“信号”的断裂：编程面试题不再能区分谁更可能成为好工程师。不到一周，另一条来自亚马逊的消息补上了同一枚硬币的另一面——在职端“指标”的异化。2026年10月底，亚马逊发布了一份面向软件工程师的更新版角色指导文件，由副总裁兼杰出工程师Terk Terkowitz执笔，核心警告直白得令人意外：不要用Token消耗量、AI工具采用率或代码生成行数来衡量工程师的生产力，这些是“deeply flawed”（从根本上就有缺陷的）指标。文件还专门造了一个词来指涉它要劝阻的行为——“tokenmaxxing”，即为了数据好看而盲目拉高Token消耗。

这条消息的标题之所以刺眼，是因为它和亚马逊自己半年前的动作构成了一个近乎黑色幽默的对照。2026年初，亚马逊内部推行AI采用目标，超过80%的研发人员被要求每周使用AI工具，内部还上线了一个名为“Kirorank”的非正式排行榜，实时统计Token消耗量。员工为了排名，让AI Agent去执行毫无意义的任务来刷量，算力成本随之抬升，亚马逊不得不在5月关停了该榜单。从“催着用”到“嫌烧太多”，中间只隔了几个月。但这篇文件真正的分量，不在于亚马逊的“反悔”，而在于它用一家巨型公司的内部教训，戳破了一个正在被越来越多组织当作管理常识接受的东西：Token消耗量不是生产力。

一、Tokenmaxxing的兴起：一个“输入指标”如何被误认成“产出指标”

要理解亚马逊为什么要专门发文踩刹车，得先看Tokenmaxxing在2026年是怎么变成一种职场现象的。

Token是大模型处理文本的最小计费单位，本身只是一个成本项。但当企业迫切希望证明“AI转型正在发生”时，Token消耗量成了最容易抓取、最容易排名、最容易在仪表盘上实时展示的数字。Meta内部曾出现名为“Claudeonomics”的仪表盘，展示全公司Token使用量排名；30天内全员消耗60万亿Token，榜首员工单人消耗2810亿，按API价格折算单月花费超过140万美元。英伟达CEO黄仁勋在GTC上给出了一个更激进的叙事：年薪50万美元的工程师，如果一年消耗的Token价值不到25万美元，“我会非常担心”，并提议把相当于底薪一半的Token额度作为薪酬包的一部分。在国内，阿里、腾讯、字节等团队不同程度地将Token使用量纳入转正和晋升的参考，有的事业群甚至把核心考核指标从日活换成了Token消耗量。

这些做法共享同一个逻辑前提：用得越多，说明越拥抱AI；越拥抱AI，说明越有生产力。 亚马逊的文件恰恰攻击了这个前提。Terkowitz的措辞很精准：这些指标“与真正重要的事情脱节”，而且一旦从“衡量工具”变成“目标”，就会推高成本、增加系统复杂性，与亚马逊自己强调的“节俭”（Frugality）和“创新与简化”（Invent and Simplify）原则直接冲突。换言之，Tokenmaxxing奖励的不是价值创造，而是消耗行为本身。

二、“10倍消耗，2倍产出”：为什么Token曲线不会线性转化为生产力

如果只是成本问题，亚马逊的警告还不至于有普遍意义。更关键的是，Token消耗与产出之间的关系，在数据上已经被证明是高度非线性的。

工程智能公司Jellyfish基于Claude Code用户数据的分析显示，Token使用量前10%的开发者，消耗规模约为中位数开发者的10倍，但产出仅高出约2倍。前10%的开发者每周用量最高可达2.25亿Token，中位数约为3200万Token，差距悬殊，而产出端的提升幅度远远追不上消耗端的膨胀。Jellyfish的研究负责人Nicolas Arcolano因此建议，企业应该关注“每个Pull Request的成本”这类结果导向指标，而不是盯住Token总量。

这个数据并不否定AI编程工具的价值。同一份分析也发现，AI使用度较高的团队，Pull Request数量比低使用度团队高出约77%。问题在于边际收益的递减来得非常快：从“不用”到“适度用”，收益是真实的；从“适度用”到“刷到排行榜前列”，多出来的消耗绝大部分并没有变成可交付的成果。德国行业媒体对Tokenmaxxing的一句评论被反复引用：把Token消耗最大化当作生产力标准，和数代码行数一样糟糕，甚至更糟——因为“最大化”本身就是质量与成功的反向指标。

亚马逊文件里还有一个容易被忽略但极其重要的表述：这些“有缺陷的”指标仍然与真正重要的产出存在相关性，只是不能把它们当作目标。这是对“指标异化”最克制的承认：相关性不等于因果性，更不等于可以拿来做绩效杠杆。一旦把相关指标变成考核目标，被考核者就会优化指标本身，而不是指标原本试图捕捉的那个东西。

三、被指标绑架的人：当“证明自己在用AI”比“用AI解决问题”更费时间

亚马逊的指导文件之所以值得程序员认真读，不仅因为它是来自一家标杆公司的管理判断，更因为它描述的那种行为扭曲，已经在大量普通开发者的日常中发生了。

搜狐科技2026年4月的一篇报道记录了一个典型场景。国内某头部互联网大厂的算法工程师王鹏，所在团队统计Token用量和AI生成代码比例，虽然没有明文的硬性惩罚，但存在团队排名，排名靠后会传导到领导，再传导到个人。问题在于，他的开发工作主要在Linux远程服务器上完成，而公司的AI统计工具最初只适配Mac和Windows。为了避免数据“挂零”，他开始了一种荒诞的流程：先在本地用AI写代码，让使用行为被统计到，再把代码复制到服务器上运行。更有甚者，原本两秒钟就能手动完成的复制操作，他会故意去问一遍大模型，等它输出一分钟，仅仅是为了增加Token消耗量。

为了证明AI在省时间，他不得不浪费更多时间去“展示”AI如何省时间。 这个场景的讽刺程度，不亚于卓别林在《摩登时代》里被传送带逼到发疯的拧螺丝工人。报道中那位工程师的原话是：“其实挺影响效率的，但如果不这样做，数据就会挂零。”

这正是Tokenmaxxing最深层的代价。它消耗的不只是公司的算力预算，还有工程师的注意力、判断力和工作流程的完整性。当一个开发者开始为了数据而调整行为，而不是为了解决问题而调整行为时，指标就已经从“观测工具”变成了“劳动过程的支配者”。亚马逊文件里那句“如果你当前的工作无法从现有AI工具中获益，这是一项发现，而不是一次失败”，正是对这种倒置的纠正：诚实地记录AI帮不上忙的地方，比假装它处处有用更有价值。

四、和“编程面试已死”是同一条逻辑

把亚马逊的“Token泼冷水”和Anthropic取消编程面试放在一起看，会发现它们指向同一个结构性变化，只是发生在职业生命周期的两端。

Anthropic的工程经理Felix Rieseberg放弃编程面试，是因为“能不能写出正确代码”不再能区分候选人。亚马逊警告Tokenmaxxing，是因为“用了多少AI”同样不再能区分谁在创造价值。两者失效的原因在形式上不同——前者是供给端被AI拉平，后者是度量端被行为扭曲——但本质相同：当一项活动变得极其廉价和易得时，用它来充当能力或贡献的证明，就不再具有区分度。 写代码曾经稀缺，所以编程题有信号；AI使用量现在泛滥，所以Token数没有信号。

更值得警惕的是，亚马逊的文件并没有否定AI采用率指标的参考价值，只是拒绝把它变成目标。这留下了一个尚未解决的真空：如果Token消耗量、代码生成量、AI采用率都不能作为绩效指标，那应该用什么？亚马逊给出的替代方案——“文艺复兴式开发者”，即能把AI工具、人类判断力和领域专业知识结合起来创造新东西的工程师——听起来正确，却难以直接量化为季度考核表上的一行数字。Terkowitz自己也承认，长期结果指标存在时间延迟、难以归因，这正是代理指标（proxy metrics）始终挥之不去的原因。DORA社区在讨论Tokenmaxxing时也指出，DORA指标从一开始就不是为评估个体开发者产出而设计的，把它变成个人记分卡，和把Token用量变成排行榜，是同一种错误在不同时代的翻版。

这意味着，接下来一段时间里，程序员很可能要在一个旧指标已死、新指标未生的过渡地带工作。组织仍然需要某种可见的“证据”，而最容易抓取的证据仍然会是Token消耗、AI调用次数、生成代码占比。抵抗这种惯性，不能只靠管理层的自觉，也需要工程师个体对自己工作的“可解释性”负责：不是“我用了多少AI”，而是“我选择让AI做什么、拒绝了什么、修正了什么、最终交付了什么”。

结语：别让工具的使用量替你说话

亚马逊这份文件最值得记住的，不是它“打脸”了自己半年前的推广政策，而是它说出了一条在指标狂热中容易被遗忘的工程常识：Token是成本，不是成果；AI使用量是输入，不是输出。 Jellyfish的数据已经表明，从适度使用到极限使用，多出来的消耗换不回成比例的产出；Kirorank的教训则表明，只要把消耗量变成排名，就一定会有人去刷，而刷出来的数字除了推高账单和复杂度之外，不证明任何事情。

对于程序员个体，这条消息的启示可以压缩成一句话：在“用量锦标赛”里保持判断力，是一种正在变得稀缺的职业能力。 当周围的人都在展示自己烧了多少Token、接入了多少Agent、生成了多少代码时，真正值得展示的，是你知道哪些Token花在了值得的地方，以及哪些Token你选择了不花。亚马逊说“无法从AI中获益是一项发现，不是一次失败”——这句话如果只被理解为对管理层的建议，就浪费了。它同样是对每一个写代码的人的提醒：你最有价值的判断，可能恰恰发生在你决定不用AI的那一刻。