Tokenmaxxing 的兴起：当 AI 指标成为目标

生成式 AI 与企业界的融合已不再仅仅是简单的实验。公司现在正试图量化其员工队伍的“AI 转型”。然而，最近一份关于 Amazon 员工参与“tokenmaxxing”——即故意增加 AI 提示词（prompts）和响应中使用的 token 数量的做法——的报告，凸显了管理不善与大语言模型（LLMs）炒作周期之间危险的交集。

当管理层开始通过原始 token 使用量来衡量 AI 采用率时，他们衡量的不是生产力，而是一个成本中心。这种现象是古德哈特定律（Goodhart's Law）的典型体现：“当一个指标变成目标时，它就不再是一个好的指标了。”

Tokenmaxxing 的机制

对于普通工程师而言，目标是效率：以最小的摩擦力获得正确的答案。但当绩效评估与 AI 使用的 KPI 挂钩时，激励结构就会发生反转。员工不再被激励去追求效率，而是被激励去浪费资源。

正如 Hacker News 上的一位评论者所指出的，这种行为是理性的：

"You measure employees in stupid ways, you're going to get stupid behaviour as a consequence."

“tokenmaxxing”的技术从微妙到荒谬不等。一些员工可能会使用过于冗长的提示词，提供冗余的上下文，或者要求 AI 在处理简单任务时“思考得更深入”。其他人可能会采取更激进的方法，正如一位用户所描述的：

"Each day I send the AI on a fruitless mission like 'summarize the entire codebase' while I do my actual work..."

“我每天都会让 AI 去执行一些徒劳的任务，比如‘总结整个代码库’，而我则在做我实际的工作……”

与传统指标的类比

这在软件工程领域并不是一个新问题。几十年来，管理层一直难以衡量开发人员的生产力，经常退而求其次，使用诸如“新增代码行数（LOC）”或“每日提交次数”等有缺陷的指标。Tokenmaxxing 只是这种谬误的现代、AI 驱动版本。

将 token 使用量作为生产力指标，正如一位批评者所言，“就像衡量击键次数一样”。它忽略了实际产生的价值——代码的质量、系统的稳定性以及工程师解决问题的能力。事实上，膨胀 token 使用量实际上可能导致输出质量降低，因为过多的上下文有时会降低某些模型的性能。

管理层差距：炒作 vs. 现实

非技术领导层与工程一线的现实之间存在着巨大的脱节。虽然领导层可能认为 AI 会带来“10x”的生产力提升，但实际的增益可能更为适中——也许是 40-60%。

这种差距创造了一种恐惧文化。工程师可能会觉得有必要伪装成正在使用这些工具，以避免被视为“落后者”，或者更糟，为了避免裁员。这导致了一种“绩效表演”现象，其主要目标不再是解决技术问题，而是为了满足仪表板（dashboard）上的数据。

前行的道路：基于结果的指标

为了避免 tokenmaxxing 的陷阱，组织必须将关注点从输入（使用的 token）转向结果（交付的价值）。

与其追踪发送了多少次提示词，管理层应该问：

• 代码交付是否更快且质量更高？
• 是否在更短的时间内修复了更多的 bug？
• 系统的整体可靠性是否在提高？

正如一位行业资深人士所建议的，衡量 AI 是否真正为组织发挥作用的唯一方法就是简单地“展示给我看结果”。这需要判断力和品味——即区分“工作的外观”与“实际价值”的能力——而这正是原始指标无法提供的。

结论

Tokenmaxxing 是对任何急于将 AI 集成到工作流中的公司的警示。危险不在于技术本身，而在于围绕它建立的激励结构。当我们奖励手段而非目的时，我们就在创造一个系统，让员工被激励去浪费资源并伪装成高效，而实际的工作却毫无变化。