夜雨聆风摘要：AI 效能指标一旦变成个人 KPI，就会从观测工具变成刷分游戏。本文用 Goodhart、METR、IBM、CMU 的证据，拆掉排行榜冲动，划清度量与监控的边界。
上一篇结尾，你已经能把 ccusage 和 GitHub 拼成一份报表了。cost_per_pr、revert_rate、cache_hit_rate，每人一行，清清楚楚。
报表导出来那一刻，最危险的念头也会冒出来：
「按 PR 数排个名，发到群里，大家就有动力把 AI 用好了。」
打住。
这一篇只劝一件事：别把 AI 效能指标做成个人 KPI，别做排行榜。 它不是“不够优雅”，而是会让指标当场失效，顺手把团队带偏。
先给判决书。
一、五条管理直觉，先判真伪
| 危险 | ||
| 夸大 | ||
| 半真半危险 | ||
| 有害 | ||
| 假 |
这五条里，没有一条能直接拿去给人打分。最像产出的 PR 数，也只是团队级粗代理。
二、案发现场：排行榜发出去以后
抽象地说“指标会失效”没有杀伤力。我们把它演一遍。
你把每个人的 AI 使用数据排了序，发进团队群。第二天开始，真实变化大概率不是“大家更会用 AI”，而是：
有人开始拆 PR。 一个完整改动拆成五个小 PR，账面产出翻倍，代码价值没变。
有人开始灌 token。 既然“用得多”看起来像“更积极”，那就多问几轮、多塞上下文、多跑贵模型。成本上去了，活没多干。
有人开始躲难任务。 会拉高 revert_rate、容易返工的硬骨头没人碰，大家去挑稳的、好看的、容易合的。
有人开始为接受率而接受。 AI 吐出来先点接受，指标抬上去，回头再悄悄改。接受率涨了，质量没涨。
这不是因为团队里的人坏。是指标在教他们这么干。
当一个指标开始承载奖惩，人就会优化数字，而不是优化数字背后的事。 这就是 Goodhart 定律在管理现场里的样子。
三、逐条核查：哪些数字会骗你
1. Goodhart：指标变目标，就不再是好指标
流行说法是：定个量化目标，挂出去，大家自然会朝它努力。
问题在于，AI 效能指标本来只适合观察。一旦变成个人目标，它衡量的就不再是“谁用得好”，而是“谁更会让报表好看”。
token 可以灌，PR 可以拆，接受率可以演，回退率可以靠躲难题压低。指标没有撒谎，是用法改变了行为。
所以判定很直接：把 AI 指标做成个人 KPI，有害。
这些指标在没人为它表演时，确实可能和效率有关。可 KPI 摧毁的正是这个前提。
2. 感知偏差：“我感觉快了”不是证据
METR 在 2025 年 7 月做过一个随机对照实验：经验丰富的开发者，在自己熟悉的真实仓库里做真实任务。开发者事前预测，用 AI 会快 24%；实测却慢了 19%。
这个结果后来要说准。METR 在 2026 年 2 月修订并扩大样本后，差距收窄到约 -4%，置信区间已经包含 0。
所以它不能被简化成“AI 让人变慢”。
它真正钉死的是另一件事：人对自己“用了 AI 到底快了多少”的直觉很不可靠。 连身处实验中的开发者，都可能把方向判反。
AI 秒回、代码刷出来，体感当然爽。但体感测的是爽不爽，不是省没省时间。把自报和问卷当效能证据，风险很高。
3. 接受率：它最多说明“你觉得有用”
接受率是最诱人的指标：工具直接给，0 到 1，天然可排序。
但研究里，代码补全接受率和“感知生产力”的相关系数只有 r=0.24。这个相关性不强，而且预测的是“感知”，不是客观产出。
换句话说，接受率高，最多说明这个人觉得 AI 顺手；说明不了代码真的更好，任务真的更快。
它可以当习惯信号，比如判断某类工具有没有被采用。但把它当“谁用得好”的证书，就是夸大。越是现成、连续、好排序的数字，越容易被误当质量指标。
4. PR 数：比 token 强，但还不够当 KPI
PR 数看起来最实在。毕竟 PR 是交付，不是聊天。
Claude Code 官方自己的效能度量实践里，也用过“每人 PR 数”，并配了“AI 贡献 20% 才算数”的归因规则。但他们也明确承认：PR 数不是完美代理。
原因很简单。PR 粒度因人、因任务、因仓库而异。一次大重构可能只有一个 PR，十个小修小补可能有十个 PR。再加上排行榜压力，拆 PR 会立刻变成最便宜的刷分方式。
所以 PR 数的合理位置是：看团队级趋势，不做个人排名。
它比 token 更接近产出，但“更接近”不等于“足够拿来考核”。
5. 用得多不是高手：差异大到不能一把尺量
“让用得多的人带队，让用得少的人补课”，听起来很顺。
但 IBM 一次 669 人部署里的调查显示，42.6% 的人自评用了 AI 后反而更慢，57.4% 更快。同一个工具，人的收益几乎对半劈。
CMU 2026 年的研究还指出了更关键的混淆变量：熟练阶段。
在面向 Agent 优化过的仓库里，引入 AI 后提交量 +36.25%，且显著；而在只有传统 IDE 使用历史的仓库里，同样引入 AI，提交量只 +3.06%，不显著。
同样一套 AI，落在不同熟练度、不同仓库阶段、不同任务结构的人身上，效果可以差一个数量级。
这时用同一把尺排名，看似公平，实际量到的是起跑线差异。DX 的工程效能研究也反对把使用量指标用于个人绩效考核。
四、真实内核：指标不是废的，用法错了
打假不能打成反向造谣。AI 效能指标不是废物。
废的是这套用法：个人 KPI、公开排名、按单项数字问责。
换一种用法，同一批指标很有价值：把它们当团队健康度仪表盘和培训雷达。
边界先划清：
团队维度，管理层看聚合趋势。效率层有没有变好？质量层有没有一起变好？成本有没有失控？如果产出上去了、回退也上去了，那不是庆功，是该查质量闸门。
个人维度，数据只给本人做自我改进。管理者最多用它发现“谁可能卡住了、需要搭把手”，然后去帮，不是去罚。
培训雷达可以这么用：
revert_rate | ||
看出区别了吗？
同一份报表，做成排行榜，是定罪书；做成培训雷达，是帮人地图。数据没变，管理动作变了，结果完全不同。
五、为什么老板总忍不住排名
道理都懂，真拿到数据，还是想排个名。这股冲动不奇怪。
第一层，是可量化的安全感。管理“人有没有用好 AI”本来模糊、费眼力、要靠对话。一张能导进 Excel 的表，会让人觉得终于抓住了客观抓手。哪怕这个抓手量错了东西。
第二层，是 KPI 惯性。过去很多组织默认“凡事可量化，量化即可考核”。AI 效能指标一进来，很自然就被吸进这条老轨道。
第三层，是公平错觉。“我用统一指标排名，对所有人一视同仁。”这句话听着公平，实际忽略了任务类型、熟练度、仓库阶段、工具链成熟度。起点不同，一把尺不叫公平，叫省事。
这就是为什么“别做成 KPI”听起来都同意，落地时却总犯。不是不知道风险，是排名太顺手。
六、该做 / 不该做
下次有人想把 AI 指标写进个人考核，直接拿这张表对。
一句话：度量是为了帮团队把 AI 用好，不是为了在背后给人装监控。
最后，把这条边界说到底。
度量非监控。 这套指标的正当目的，是发现团队哪里卡住、谁需要帮助，然后去改善流程和训练方法。不是盯梢，不是抓人摸鱼。
不用于个人考核。 可刷、有偏、混淆变量、Goodhart，任何一条都足以让“拿它给个人打分”变成自欺。个人维度的数据，唯一正当出口是交回本人，帮助他自己变好。
守住隐私边界。 采集什么、怎么用，团队和本人都应该知情。团队层面只用聚合，不公开个体明细。任何会让某个人“在群里被指着看”的用法，都该停。
下一篇，我们不再纸上谈兵。我会拿一份脱敏团队数据，把这套指标从头跑一遍：哪些数字会骗你，哪些异常其实正常，人工闸门到底拦下了什么。
