资深开发者用 AI 自觉快两成，实测却慢近两成

AI 编程工具到底让资深开发者更快还是更慢？此前大量讨论停留在感觉层面，近日 METR 的一项随机对照试验给出了一个看似反常识的硬指标：使用当前主流前沿 AI 工具的资深开源开发者，自评开发速度提升约 20%，但与时钟对账后，实际效率反而下降约 19%。体感与实测之间的差距高达近 40 个百分点，且「最确信自己被提速的人，恰恰是被显著拖慢的人」。

METR 这项研究是怎么做的

• 试验设计：METR 对 16 名经验丰富的开源开发者开展随机对照试验，任务数 246 个，开发者均在「自己熟悉的代码库」内工作。
• 使用工具：采用研究开展时所定义的「当前前沿 AI 编程工具」。
• 测量方式：分别在「工作前预期」与「工作后自评」两个时间点由开发者主观打分，同时以任务耗时作为客观计时。
• 关键对比：自评速度提升约 20%，客观测速反而下降约 19%，两者方向相反。
• 作者声明：样本规模较小，结果不能泛化到「所有人在所有场景下」；对于初级开发者和全新代码工作，效果可能反转。

为何体感与时钟会反向背离

文章作者长期追踪自身团队的「感觉与事实脱钩」现象，此次试验让他意识到，问题不是仪表盘噪声太大，而是这把标尺本身就指反了。核心机制有两点：

• AI 真正加速的是「打字」，而对熟悉代码库的资深工程师而言，打字从来不是瓶颈。
• 真正变贵的，是「提示工程、等待生成、审阅并甄别那些细颗粒度错误」的环节，这些恰好落在原本就成本最高的工作阶段上。

因此，自评所捕捉到的「流畅感」并不能换算为真实交付速度，反而在最应当可信的「资深 + 存量代码」场景里指向了相反结论。

更大尺度的数据也在指向同一方向

作者援引三组外部数据与小试验相互印证：

• Faros AI：覆盖超过 1 万名开发者，发现合并的 Pull Request 数量上升 98%、PR 体积上升超过 150%、评审耗时上升 91%，整体交付量几无净增长；其中 31% 的 PR 合并时完全未经评审。
• DORA：更高 AI 采用率对应可衡量的交付稳定性下降，且负面影响延续到本年度。
• GitClear：扫描 2 亿行变更代码，发现复制粘贴式代码上升、代码变更率上升、重构占比跌至 10% 以下；2024 年是首次出现「粘贴多于重构」的年份。

几组数据的共同信号是：生成得更多、合并得更多、变更得更多，但交付量基本未增，落地后的稳定性反而更差。这意味着成本被推到了下游——事故、改动返工、评审人倦怠——而这恰好不在那张「团队速度曲线」所显示的页面内。

对工程团队的启示

• 把「感觉更快」当作未经验证的假设：任何仅靠主观体感支撑的生产力声明，在时钟给出反向证据前都不能算成立。
• 重新配置瓶颈阶段的资源：评审、验证、可信度把关才是当下真正堆积工作量的环节，而这些环节往往没有同步扩编。
• 区分「J 曲线低谷」与「仪表失灵」：效果对初级开发者和全新代码可能为正，DORA 的吞吐量在滞后中回升，符合「爬出低谷」的形态；但这并不意味着可以继续用错误的方向盘。

编辑视角的延伸判断是：行业头部工具厂商的资金流向已经为这一判断投了票。Windsurf 团队被 Google 拆解吸纳至 DeepMind，剩余部分并入 Devin 母公司，创始人另起炉灶的方向是「agent-first IDE」——也就是从「键盘前生成」迁移到「仪表板内评审」。最具侵略性的工具押注，本质上押的就是「下一阶段的瓶颈在验证」。