Amazon 把 AI 用量做成排行榜，员工开始用 AI 制造 AI 工作

1980 年代有过一个广为流传的故事：IBM 给工程师按代码行数发奖金，写得多发得多。某次有人做了一轮大重构，把代码从 6000 行优化到 4000 行——他在月报里诚实填了 “-2000 行”。系统当场死机，HR 也不知道这要怎么扣钱。

四十年过去了，剧本只换了道具。

Amazon 最近在内部上线了一个叫 MeshClaw 的 AI agent 工具，员工可以用它触发部署、做邮件 triage、调 Slack。同期公司定了硬指标：80% 以上的开发者每周必须用 AI。再加一手——开内部排行榜，按每个人消耗的 token 数排名。

官方说法是 token 数不进绩效。员工不这么看。一位接受采访时说："压力太大了，有人就是在用 MeshClaw 刷 token。"另一位更直接：“经理在看这个榜。他们一开始盯用量，就会出现非常变态的激励，有人对这件事相当好胜。”

这个行为已经有了专属名词：tokenmaxxing——故意写超长 prompt、把简单任务拆成五次调用、让 AI 写 AI 用的提示词去再调一次 AI。Meta 内部据说有同款行为，叫法都一样。

这不是 KPI 设计烂，是 KPI 类别选错了

刷到这条新闻，第一反应通常是：“Amazon 这指标设计得真粗糙，换个聪明的不就行了？”

错。

问题不在指标的粗细，而在指标的类别。"AI token 用量"是个过程指标——衡量你做了什么动作。但公司真正想要的是结果指标——你产出了什么。过程指标的特征是：可以被无穷优化，且优化它对结果没有任何因果保证。

经济学家 Charles Goodhart 1975 年总结过这件事，叫古德哈特定律：一个度量一旦被当作目标，它就不再是个好度量。原始语境是英国央行——你拿任何一个金融统计量去管经济，那个统计量就开始失真。这条定律在工程组织里被反复验证过：

每次新工具上线，总有人坚信"这次不一样，这次的指标更聪明"。结果剧本一字不差。AI 用量只是这个家族的最新成员，唯一的差别是这次刷得更快——AI 帮你刷 AI 的用量是闭环。

第二个反应通常是：“那别看 token 数，看提示词质量、看任务完成数、看 AI 辅助下的代码合入率？”

听上去都合理，但每一个都能被破。

看提示词质量？ 已经有人让 AI 帮自己写"看起来更专业"的提示词去喂 AI——一层套一层，质量评分能拉满。

看任务完成数？ 把一个任务拆成五个 sub-task，每个都过 AI。

看代码合入率？ 在能不用 AI 的地方挂一句 AI 注释——反正算法识别的是"有 AI 痕迹"。GitHub 之前那波 “AI 写了 N% 代码” 的 PR 营销叙事，是同款变形。

只要你定义的是过程——做没做、做了多少、做得"看起来好不好"——它就一定能被低成本伪造。这不是道德问题，是数学问题：可观测的中间状态，总能找到更便宜的路径去触发。

真正能扛住 Goodhart 的指标只有一类：结果指标——这个 feature 上线后用户留存提了几个点、这个 bug 修完后线上 P99 降了多少、这个项目早交付了几周。它锁定的是"业务后果"，不是"员工动作"。

但结果指标有两个让管理层头痛的毛病：慢，季度才能看出来；个人归因关系弱，团队成果不好切到人头。于是管理层总是忍不住回到过程指标——快、清晰、可比。然后撞回同一面墙。

更隐蔽的陷阱是榜单本身编码了一个错误假设：用得多 = 用得好。

实际可能完全相反。

一个真把 AI 用熟的开发者，一次调用就能拿到想要的结果——提示词精确、上下文够、改一改 commit 完事。日均 token 消耗远低于团队中位数。一个刚被推着上 AI 的开发者，反复试、来回改、同一个问题问五遍——token 数高得惊人。

按 token 数排榜，第一种人显示为"AI 参与度低"，第二种人被表扬为"积极拥抱 AI"。激励完全反向。

任何用过 LLM 写代码的人都能验证——熟练度的增长曲线，几乎一定伴随着 token 消耗的下降。把这个量做 KPI，等于把"熟练度低"包装成了"绩效高"。

下次你公司开 AI 落地会议——有人提议"咱们也搞个 AI 用量排行榜推一推"，你大概可以代入了。

不是问"指标怎么设更合理"。是问一句更朴素的：你想要的是用量，还是产出？

如果是产出，就别测用量。如果非要测点什么，测业务结果在 AI 介入前后的差——慢、糙、不可比，但至少没在生产假数据。

度量陷阱不是新鲜事。AI 只是把它的运行速度加快了。1980 年代的工程师用循环展开和宏定义刷代码行数，2026 年的工程师用 AI 给 AI 写 prompt 刷 token——同一行剧本，新一茬演员。