采纳率是一个虚荣指标：你的 Copilot ROI 隐藏在敲击键盘后的 90 秒里

仪表板显示，你的工程师在上个季度采纳了 45% 的 AI 建议。管理层将其解读为“节省了开发人员 45% 的时间”，并签署了续约合同。与此同时，工程师们正在悄悄重写他们采纳内容的一半，调试另一半，并纳闷为什么他们的 Sprint 看起来还是和以前一样长。双方都在看同一个数字，但只有其中一方看对了数字。

2025 年引用次数最多的这项研究，本应单枪匹马地终结“厂商仪表板时代”。METR 衡量了经验丰富的开源维护者在有无 AI 的情况下，处理自己代码库中真实问题的表现。开发者预测 AI 会让他们提速 24%。实验结束后，他们仍然认为 AI 让他们提速了 20%。但秒表显示他们慢了 19%。故事与数据之间存在 39 个百分点的差距——而季度评审中采用的正是那个“故事”。

采纳率衡量的是循环中最简单的部分：一次敲击是否节省了另一次敲击？所有重要的指标——达到真正可以交付的代码所需的时间、已采纳 diff 的错误率、采纳后的代码流失（churn）、验证负担——都存在于按下 Tab 键后的 90 秒内，而这些在默认仪表板上都没有显示。

仪表板衡量的是无摩擦的那一半

采纳率、显示的建议、采纳的代码行、节省时间的估算——这些是每个厂商都会提供的指标，因为它们是遥测技术可以免费获取的。IDE 知道什么时候提供了建议，以及光标是否移过了它。但它不知道开发者随后是否花了四分钟盯着采纳的代码块，重写了六行中的两行，在二十分钟后撤销了整段代码，或者合并了一个静默破坏了三个服务外列名的 PR。

报告的采纳率因统计口径而异：Zoominfo 的一项企业研究记录了 33% 的建议采纳率和 20% 的行采纳率。其他部署报告的比例在 21% 到 40% 之间。这种差异本身就应该是一个警示——一个在同类人群中波动近 2 倍的指标，衡量的并不是工具的稳定属性。它衡量的是自动补全触发的频率，以及开发者对“好到不需要删除”代码的容忍度。

更糟糕的是，高采纳率可能与真实的生产力呈负相关。METR 自己的后续观察指出，那些过度依赖 AI 工具的开发者往往是速度变慢最明显的人，因为即使时钟时间在拉长，那些建议仍让他们“感觉有所进展”。研究人员开始将其称为“虚幻生产力”（illusory productivity）——编辑器中的活动让人感觉像是在工作，Tab-Tab-采纳带来的多巴胺分泌取代了实际交付带来的快感，而季度指标奖励的是感觉而非结果。

这就是为什么从教科书定义上来看，原始采纳率是一个虚荣指标：它优化了流水线中原本就很廉价的部分，却忽略了昂贵的部分。节省一次敲击是有价值的。但以十分钟的验证阅读为代价来节省一次敲击，其价值就是负的。仪表板无法区分它们。

钱到底花在了哪里

使用代码助手最昂贵的部分不是打字，而是验证。验证成本通过默认遥测无法触及的四个渠道累积：

验证时间。 每一个非显而易见正确的采纳代码块都会触发阅读。这种阅读是静默的——没有事件触发，没有计数器增加，也没有仪表板渲染它。但这正是 METR 研究中 19% 减速的来源。资深工程师在顺风局可以写得比模型快；但他们无法超越自己的审慎。

采纳后编辑率。 一个你采纳后又重写的建议并没有为你节省时间；它只是给了你一个存在缺陷的模板让你去回应。微软自己的研究项目以“持久率”（persistence rate）为名跟踪这一指标——即采纳的建议在提交的代码中保持不变的比例。有趣的是，他们得出的结论是：采纳率与自我报告的生产力相关性比持久率更高。这个发现值得反过来理解：与“自我报告”生产力相关的指标才是会被刷数据的指标，而不是衡量现实的指标。

Bug 逃逸差值。 AI 生成的代码看起来不像是 Bug。它看起来很“合理”，这是一种更不同且更危险的属性。GitClear 对 2.11 亿行代码的分析发现，在 2020 年到 2024 年间，重度使用 AI 的代码库中，重复代码块增长了 4–8 倍，重构率崩盘了 60%，而整体代码流失率（两周内重写或撤销的代码比例）几乎翻倍，从 3.1% 增加到 5.7%。CodeRabbit 的采样发现，AI 生成代码的问题是手写代码的 1.7 倍。Uplevel 对 800 名开发者的研究报告称，拥有 Copilot 使用权的团队，其 Bug 率增加了 41%。随便选一个你喜欢的数字，没有一个是零。

采纳后拒绝。 这是指那些在 IDE 中没有显示，但发生在 Pull Request 中、一周后的提交里或一个月后的热修复中的撤销。最初的采纳事件仍被计为一次“胜利”。而清理工作则被计为正常的工程工作。这套算法被操纵了。

把这些加起来，你会得到一个具体的图景：如果 45% 的团队是在激进采纳并防御性复读，那么一个采纳率为 45% 的团队，其每次交付变更所花费的周期时间很容易比采纳率为 25% 的团队更多。仪表板永远不会告诉你这一点。它只会说：使用量在上升，你的钱花得值，续费吧。

真正能揭示真相的指标

如果你想要一个能毫不犹豫地交给领导层的数字，从这里开始：

平均已验证变更时间 (MTVC)。 衡量从“开发者开始任务”到“变更通过自身审查并进入主分支”的完整周期。不是“建议到接受”，也不是“提交到合并”。这段时间包括键入、接受、阅读、怀疑、重写、测试以及在审查中进行辩护。剥离那些无摩擦的时刻，你剩下的就是 AI 工具真正与之竞争的时间预算。

接受后编辑率。 对于每一个被接受的建议，观察其中有多少在提交时、合并时、7 天后、30 天后依然保持原样且未被修改。合并时的持久性是一个质量信号；30 天后的持久性是一个耐用性信号。如果一半的已接受代码在一个月内被重写，那么接受率就是一个假象。

AI 接受代码与手写代码的 Bug 逃逸率对比。 为提交打上标签，标注它们是否源自 AI 建议（通过 IDE 遥测、提交消息元数据、PR 描述公开——选择一种并强制执行）。在接下来的 90 天内，将其与你的故障追踪系统进行交叉比对。如果带有 AI 标签的代码每行产生的缺陷率高于手写代码，那才是你真实的 ROI 数字，而且它可能是负数。

接受后拒绝数。 统计在 IDE 中被接受，随后在合并前被删除、回滚或大幅重写的行数——再加上针对已合并至生产环境的代码在 14 天和 30 天内的相同统计。这能捕捉到被接受率掩盖的“我接受它只是为了浏览一下”的行为模式。

审查者信心调查，而非审查时间。 将“你是否独立验证了此变更？”作为 PR 的必选复选框。如果在 AI 密集的 PR 中，超过 20% 的回答是“否”，那么你就遇到了伪装成速度的质量问题。这就是 Stack Overflow 2025 年调查发现的痛点：46% 的开发者主动怀疑 AI 工具的准确性，但他们仍然交付了代码。这种差距——怀疑与交付的结合——正是故障率滋生的温床。

这些指标都不是什么新鲜事。它们只是衡量起来很昂贵，这就是为什么供应商仪表板不提供这些数据的原因。每一个指标都需要关联 IDE 并不拥有的数据源：提交日志、故障追踪系统、审查系统、部署流水线。这种关联工作才是核心所在。

如何实际落地这些测量

工具并不难，难的是规范。你需要将三个数据层面连接在一起：

插桩化的 IDE 遥测。 捕获接受事件以及被接受的代码差异 (diff)。在接下来的 N 分钟内，跟踪该 diff 内部或相邻的每一次后续按键。当变更进入提交时，为每个被接受的块发送一个事件，记录：已接受的字节数、存留的字节数、编辑次数、从接受到提交的实际耗时。这用一个分母更值得信任的指标取代了“接受率”。

提交与故障的关联。 每次部署都有一个 ID。每次故障都有一个事后分析。每次事后分析都会指定一个提交。构建一个流水线，在给定提交 SHA 的情况下，能告诉你“这是否在 90 天内引入了故障？”——并且是在查询时完成，而不是在季度回顾中。一旦你拥有了这些，通过为提交打上 AI 来源的元数据标签，你就可以通过一条 SQL 查询来计算每个来源的 Bug 逃逸率。

结构化的审查者调查。 不是问“这个 PR 怎么样？”。开放式调查只是噪音。设置两个必选复选框：你是否独立验证了非琐碎变更的正确性，以及你是否专门抽检了 AI 建议的代码块。收集这两项数据，并与逃逸率进行交叉比对，当审查者在 AI 密集的工作中开始懈怠时，你就会得到一个领先指标。

这是基础设施，而不是仪表板。构建好它需要一个季度的时间，一旦你拥有了它，在任何重要的事务上，你都不会再回到原始的接受率指标上。

无人排练过的领导层对话

在某个时刻，一位总监会看着你这些新数字，询问为什么以前 45% 的接受率变成了 MTVC 没有改善，而且带有 AI 标签的 diff 里的 Bug 逃逸率还增加了 15%。诚实的回答分为三个部分。

首先：45% 的接受率并不等同于节省了开发者 45% 的时间。从来都不是。流出的厂商营销策略将“接受”和“节省”混为一谈，而两者之间的差距就是整个验证阶段。Google 的 2025 年 DORA 报告发现，超过 80% 的开发者自认为 AI 提高了生产力，而对工具本身的正面情绪却从 70% 以上下降到 60%。开发者报告的数字与他们感受到的数字已经在背离。再过一年，自评报告就会赶上现实。

其次：DORA 指标是正确的交叉核对方法。InfoWorld 对公司规模推广的分析发现，即使在大规模采用的情况下，部署频率和交付周期往往也没有变化。如果 AI 真的节省了时间，流水线会反映出来。流水线是事实真理；Copilot 仪表板只是表象。

第三：一个显示 45% 接受率但 Bug 逃逸率上升的团队可能正在损失时间，因为验证被接受的建议比验证他们自己写的代码更难。这是该领域一直回避的一句话。有些被接受的代码验证成本很低，因为它只是你本来就会写的样板代码补全。而有些被接受的代码验证成本很高，因为它使用了一种开发者以前不知道的 API 模式，现在他们必须先学习它才能进行审查。接受率将这些视为相同的事件。但它们并非如此。

这样做会带来什么改变

那些重建度量层的团队并没有停止使用 AI 工具 —— 他们改变了使用这些工具的方式。高置信度的补全（导入、样板代码、类型良好的存根）保持开启。低置信度的补全在敏感目录中被关闭。审查者在标记为重度 AI 的 PR 上获得明确的 AI 对抗轮换。关于采纳的讨论不再是“我们用得够不够多”，而是“我们是否接受了正确的东西”。

与领导层的沟通也变得更加容易，因为你不再争论工具是否好用，而是开始讨论带有具体数字的特定失败模式。在 AI 标记的 diffs 中，9% 的 Bug 数量增长是可以缓解的。而 45% 的接受率只能让你要么庆祝，要么怀疑。

这个领域最终会趋向于真实的指标，就像 Web 性能领域最终汇集到核心 Web 指标（Core Web Vitals）一样 —— 这不是因为供应商的引导，而是因为少数团队衡量了真正伤害他们的东西，并拒绝发布那些虚荣指标。Copilot 领域对这种拒绝的对等做法早已该出现。按键后的 90 秒是你的 ROI 生死存亡的关键；衡量它，正是你找出答案的方式。