据报道Meta 本周更新了工程师的绩效指引不再用AI 采用率仪表盘或Token 消耗量来评估员工删掉了此前对具体 AI 工具和任务使用的要求。与此同时Meta 内部 93% 的代码变更已经由 AI 智能体辅助完成。一边是 AI 用量高到接近饱和一边是公司主动放弃用 AI 用量当 KPI——这两件事放一起比单看任何一件都更有意思。这件事的事实细节先把已知信息摆出来消息源主要是 The Information 的报道后被多家媒体转引Meta 高管 Maher Saba 与 Santosh Janardhan 发布了新版绩效指引明确不会用 AI 工具采纳率仪表盘或 Token 消耗量来评估员工的影响力目前 Meta 内部约 93% 的代码变更由 AI 智能体辅助完成公司特别强调采用 AI “本身并不是最终目标”目标是更高质量的交付和更快的迭代。注意措辞“由 AI 智能体辅助完成”不是AI 自己写完的。补全、生成样板、写单测、改 bug 都算辅助。93% 这个数字说明在 Meta 这种体量的公司里AI 编程已经不是要不要用的问题而是默认就在用。技术本质指标一旦成为目标就会失效这事的内核其实是一个老掉牙的规律——古德哈特定律当一个指标变成考核目标它就不再是好指标了。推理链条是这样的AI 编程刚普及那阵公司担心大家不用于是把AI 使用量设成 KPI鼓励工程师多用一旦用量与绩效挂钩理性人的最优策略就变了不是把活干好而是让数字好看——凑 token、反复生成、无意义调用当 93% 的代码变更都走 AI 辅助之后用量指标彻底失去区分度——大家都满分等于没考。Meta 这次调整等于承认了这套度量逻辑走到头了。AI 参与度饱和之后能拉开差距的只剩结果交付质量、迭代速度、缺陷多少。指标从你有没有用 AI退回到你用 AI 干出了什么。这里有个代码层面的直观例子。假设某个内部看板用Token 消耗量给工程师打分统计逻辑类似这样# 示意代码某个AI 使用量看板的简化打分逻辑非任何真实产品代码defusage_score(prompt_chars:int,reply_chars:int)-float:# 按字符数粗估 token 消耗真实场景会用分词器return(prompt_charsreply_chars)/4# 想拿高分最理性的做法是把问题描述写长、多生成几版# 而一次问清楚、一次改对反而得分低——这就是指标失效的过程分数催生出来的不是效率是注水。这不是哪个人品有问题是度量设计本身的问题。Meta 撤掉这个指标等于承认了这一点。对普通打工人有什么用说句实在的这两年不少公司内部也立了类似的规矩“每人每天至少要用多少次 AI”“AI 生成代码占比要达到多少”。Meta 这波反向操作等于给所有跟风搞AI 用量考核的团队提供了一个反例。如果你所在的公司还在拿用量排名可以参考下面这套思路自己判断不该拿来看绩效的Token 消耗量、调用次数可注水无区分度AI 生成代码的行数占比行数是经典的虚荣指标工具采纳率排名会诱导为用而用可以看的PR 交付周期、需求吞吐是否真的变快线上缺陷率、回滚率有没有变差代码评审的返工次数如果真想追踪 AI 的效果单独统计一段时间AI 生成代码的缺陷密度而不是混在总量里对个人来说有三点比较实用把 AI 用在 ROI 高的地方写测试、解释老代码、生成胶水代码、批量改格式这些活省时明显为了显得积极而无效调用浪费的是自己的时间。留痕产出别留痕用量晋升述职写我用 AI 把 XX 模块的测试补全率从 60% 提到 95%比写我本月消耗了 XX 万 token有说服力得多——好在 Meta 这类公司现在也这么认了。警惕刷量文化当团队开始比拼谁问 AI 问得多说明管理信号出了问题这时候别跟着卷数字把活干利索才是稳的。结尾93% 这个数字其实比考核口径本身更值得琢磨当 AI 参与度逼近饱和程序员的核心产出正在从写代码本身转移到定义问题、设计架构、守住质量这些 AI 暂时替不了的事上。你们公司还在用 AI 用量考核吗你怎么看评论区聊聊。