Tokenmaxxing：当 AI 采用指标成为目标时

最近关于 Amazon 员工的报告凸显了一个奇怪的趋势：员工正在使用内部 AI 工具来创建无关紧要的任务和代理，目的不是为了提高生产力，而仅仅是为了推高他们的 AI 活动指标。这种现象被一些人称为 "tokenmaxxing"，它是当一家公司优先考虑工具采用的 测量 而非工具实际提供的 价值 时，所发生的典型案例。

这种趋势并非某一家公司所独有。在整个科技行业，高管要求 "integrate AI" 的指令与软件实际构建和维护的现实情况之间存在着日益增长的紧张关系。当使用指标成为绩效或创新的代理指标时，员工自然会调整其行为以满足指标，而不管工作的实用性如何。

Goodhart's Law 的体现

这一问题的核心是 Goodhart's Law："当一个衡量标准变成目标时，它就不再是一个好的衡量标准。" 在 Amazon 以及其他与 FAANG 相关的公司案例中，衡量标准通常是 "tokens used" 或 "AI activity levels"。

当领导层创建排行榜或暗示高 AI 使用率与生产力挂钩时，他们无意中激励了浪费。正如一位评论者所指出的，这创造了一个超现实的环境，员工感到压力，必须在毫无价值的任务上消耗大量 tokens，仅仅是为了避免显得停滞不前：

"我在我的工作中也做过类似的事情，管理层希望我们在 tokens 过期之前用完它们。我通常将其设置为文档任务和其他次要任务，仅仅是为了消耗 tokens。"

这导致了一种 "speculative labor"（投机性劳动）的循环，即使用 AI 生成一系列没人打算使用的代码或文档，仅仅是为了让 "dashboard green"（仪表盘保持绿色）。

"Forcing Function" 的论点

并非所有观点都认为这种趋势纯粹是破坏性的。一些人认为，这些指令充当了 "forcing function"（强制功能），旨在推动不情愿的员工进行实验。其逻辑是，通过迫使人们 "play"（玩耍）这些工具——即使最初的使用场景是毫无意义的的——他们最终会偶然发现真正的生产力提升。

"学习一段软件、工具或流程的好方法是去玩它... 指令在很多方面都显得很蠢。但它们会迫使人们去发现除了编程之外，AI 是否能带来其他有用的东西。"

然而，这种论点与专业工程的现实相冲突。迫使一名高级开发人员使用 LLM 来执行一个只需要单个 CLI command 的任务，这并不是 "experimentation"（实验）；这是一种增加了开发周期摩擦的低效行为。

人为活动带来的隐藏成本

除了人类生产力的损失外，"tokenmaxxing" 还带来了显著的外部成本：

1. 环境影响

LLMs 计算成本高昂。在 "worthless stuff"（毫无价值的东西）上消耗数百万个 tokens 会导致不必要的能源消耗和碳排放。批评者将其比作苏联时代的鲸鱼肉配额，当时为了满足配额，无论肉是否真的被需要或消耗，都会大量猎杀鲸鱼。

2. 基础设施压力

高容量的人为流量可能会降低 AI 服务本身的性能。人们担心内部的 "token burning"（消耗 tokens）可能会削弱提供商（如 Anthropic）处理合法用户流量的能力，尤其是当该公司本身就是提供商的投资者时。

3. 文化侵蚀

当员工被鼓励去钻营系统时，它会侵蚀功绩制和交付成果的文化。它在真正交付价值的人与那些通过 24/7 运行消耗 tokens 的脚本来 "comfortably in the #1 spot"（安稳地占据排行榜第一名）的人之间制造了隔阂。

结论："Day 2" 心态的危险

对于像 Amazon 这样以 "Day 1" 哲学（坚持不懈的创新和客户至上）而闻名的公司来说，转向钻营内部指标的行为，感觉像是向 "Day 2" 的转变——一种停滞和由流程驱动的衰退状态。

当目标从 "solve the customer's problem"（解决客户的问题）转向 "increase the AI usage metric"（增加 AI 使用指标）时，公司就已经停止了创新，开始转向表演。对于技术领导层来说，教训是显而易见的：激励结果，而非活动。如果 AI 确实能提供 10x 的生产力提升，这种提升将体现在更快的交付周期和更好的产品中——而不是仪表盘上更高的 token 计数。