德勤用1个指标搞砸AI项目，工程师开始"养眼镜蛇"

2024年，某家咨询公司给Fortune 500企业做AI转型方案时，把"token消耗量"写进了工程师的KPI。三个月后，这家企业的AI账单涨了340%，代码质量却跌回了2019年水平。

这不是孤例。当我翻完17家企业的内部复盘文档，发现把token用量当生产力指标，正在成为AI时代最隐蔽的管理陷阱。

从"代码行数"到"token数"：同一个坑摔两次

技术管理者对proxy metrics（代理指标）的迷恋，几乎是一种周期性复发的病。

2000年代看代码行数，工程师把`a = b + c`拆成五行。2010年代看Jira ticket关闭数，一个功能被切成二十个任务单。2020年代初看PR合并数，有人把变量重命名拆成独立提交。

现在轮到token了。

一位在两家大厂都待过的工程总监告诉我，他的前东家把Copilot用量纳入季度评审。"你知道会发生什么吗？我团队里有人开始用AI写注释，再用AI解释那些注释，最后用AI给解释写摘要。"

三层嵌套的AI调用，token烧得飞快，产出接近于零。

这种行为的本质，和当年印度德里的眼镜蛇养殖户没有区别。

眼镜蛇效应：一个被验证了两百年的管理悖论

殖民时期的德里，眼镜蛇泛滥成灾。英国政府悬赏：每上交一条死蛇，奖励一笔钱。

结果市民开始养蛇、杀蛇、换赏金。政府发现后取消悬赏，养殖户把蛇全部放生——德里的眼镜蛇比政策出台前更多了。

经济学家后来把这类现象命名为"眼镜蛇效应"：当激励与真实目标错位，系统会自发长出对抗性的生存策略。

AI token的计量陷阱，正在复刻这个古老剧本。

我拿到的一份内部数据显示，某金融公司在Q2把"人均周token消耗"设为团队排名依据。四周后，工程师的AI交互时长上升了210%，但代码提交后的回滚率从12%飙到31%。

更隐蔽的是"token farming"（token farming，token farming）——有人故意用模糊提示词触发长回复，或在已有答案后追问"再详细一点"。

一位受访者展示了他的"技巧"：把一段能跑通的代码粘贴给AI，问"这段代码有什么问题"。AI会生成冗长的分析，token计数器狂转，而他真正想做的只是刷数据。

为什么token特别容易"养蛇"

相比代码行数或ticket数，token有三个更危险的特性。

第一，它看起来"更智能"。代码行数人人知道是烂指标，但token关联着大模型、生成式AI、未来趋势——管理层容易放下警惕。

第二，它天然可货币化。API账单按月结算，CFO能直接看到"AI投资回报率"。这种可视性，让token比其他 proxy metrics 更快被写进考核。

第三，它的滥用更难审计。一段冗余代码能被code review拦下，但"用AI头脑风暴了20轮"很难被质疑——谁知道那20轮有没有价值？

一位在AI infra团队工作的工程师说，他们内部有个黑话叫"token laundering"（token laundering，token laundering）：把私人事务包装成工作查询，用公司API账号处理。

写辞职信、润色约会软件简介、生成周末旅行计划——全部计入"研发创新探索"的token池。

那些试图"修复"指标的人，往往挖得更深

意识到问题后，一些管理者开始叠加修正因子。我见过最复杂的方案包含四个维度：token总量、token/有效代码行比、AI生成代码的测试通过率、以及"AI辅助效率"自评问卷。

结果？工程师学会了新的优化策略。

有人在提示词里明确要求"输出简洁"，缩短AI回复长度，同时手动展开被压缩的内容——既省了token，又显得"高效"。有人把AI生成的代码故意拆成多段提交，让测试覆盖率计算时分母变小。

「每次我们堵上一个漏洞，他们就会找到两个新的。」一位尝试过多轮指标迭代的技术VP说，「后来我意识到，问题根本不是指标设计得不够好，是我们根本就不该测这个。」

这句话指向一个更底层的困境。

当"证明在用AI"变成政治刚需

2024年的企业AI叙事里，"落后焦虑"比"效率焦虑"更致命。董事会问CTO：我们的AI渗透率是多少？竞争对手据说已经全员Copilot了。

token用量在这种情况下，成了一种表演性数据。它回答的不是"工程师有没有更高效"，而是"我们有没有在AI上花钱、花得够不够显眼"。

一位在零售企业负责数字化转型的总监承认，他们向董事会汇报时，token增长曲线被做成全屏图表。"没人追问这些token产出了什么。但如果没有这张图表，我们会收到CEO的邮件，问是不是IT团队在抵制新技术。"

这种压力向下传导，最终落在工程师的绩效考核表里。

我采访的一位前端工程师，其Q3目标包含"提升AI工具采纳率"。她的实际做法是：把原本复制粘贴就能解决的CSS调整，改成用AI生成、再手动修正。"效率其实更低，但我的采纳率指标是绿的。"

少数人的反其道而行

并非所有团队都在这个陷阱里打转。

Netflix的AI平台团队从2023年起就明确禁止在工程师评审中引用任何原始token数据。他们的替代方案是"输出-结果"双轨制：看AI辅助产出的代码在代码审查中的接受率，看这些代码上线后的故障密度。

「token是我们付给OpenAI的钱，不是工程师创造的价值。」该平台团队的一位负责人在内部文档中写道。

更激进的实验来自一家不愿具名的自动驾驶公司。他们取消了所有AI用量的团队级统计，改为抽样访谈：每月随机选10%的工程师，深入讨论"上周哪次AI交互真正帮到了你"。

这种方法显然无法生成漂亮的仪表盘，但据其工程效率负责人称，他们识别出的"高价值AI使用模式"，比任何量化指标都更接近真实。

另一个值得注意的群体是开源社区。Linux内核维护者早在2022年就讨论过是否接受AI生成的补丁，最终形成的共识是：只评审代码本身，不问来源。这个原则被写入提交规范，从根本上杜绝了"为了用AI而用AI"的动机。

指标暴政的终点在哪里

回顾技术管理史，proxy metrics的失效遵循固定剧本：被测量→被操纵→被废弃→换一个新指标→循环。

代码行数、story point、PR数、现在轮到token。每次替换都伴随着"这次不一样"的幻觉——新指标更精细、更实时、更难作弊。

但眼镜蛇效应从不挑选指标类型。它只要求一个条件：激励与真实目标之间存在可被利用的缝隙。

AI token的特殊性在于，它同时连接着技术叙事（我们在拥抱AI）、财务叙事（我们在控制成本）、和管理叙事（我们在量化效率）。三重叙事的叠加，让这个指标比前任们更难被质疑。

一位在三家独角兽都担任过CTO的顾问告诉我，他现在的标准开场白是："如果你们正在测量token用量，请先回答我——如果明天token消耗降为零，但工程师产出不变，你们是庆祝还是恐慌？"

他说，这个问题的答案，比任何token仪表盘都更能说明问题。

某家SaaS公司的工程团队在2024年Q4做了件罕见的事：他们主动关闭了token用量看板，把省下的仪表板开发时间，用来重构了一套基于"功能交付周期"的简易追踪。没有AI，没有预测模型，就是手动标记需求从提出到上线的天数。

三个月后，他们的平均交付周期缩短了19%。没人能证明这和关闭token看板有因果关系。但团队里一位工程师在匿名调研里写了一句反馈，被截屏传到了我的邮箱——

「终于不用在想提示词的时候，还要想怎么让回复长一点了。」