一项针对16名资深开源开发者、246个真实任务的对照试验给出了一个反直觉的结果:这些人用AI工具干活时,自己觉得快了约20%,可秒表量出来的结果是慢了19%。感觉和事实,相差了将近40个百分点。

更扎眼的是限定条件——参与试验的都是在自己熟悉的代码库里干活的老手,用的是当下最主流的前沿AI编程工具。换句话说,不是新手不会用,也不是工具太烂,是在最该发挥优势的场景里,仪表盘读反了。

主观“更快”,实测“更慢”

这项由METR主导的随机对照试验,方法上不复杂:开发者先预估AI会不会提速,干完活再回报感受,同时后台用时间记录实际用时。三组数字对上,出了偏差。

感觉与事实,反向了40个百分点 开发者自我感觉 +20% “我更快了” 秒表实测结果 −19% 实际更慢 样本:16名资深开发者 / 246个真实任务

研究方自己也承认样本小,结论不能推广到所有场景——对初级开发者、对全新项目(greenfield),AI的加速效果其实是正的。但没打上但书的那句话更狠:越确信AI在给自己提速的人,越是被实测拖慢的那批人。

打字从来不是瓶颈

原因不难想明白。AI真正擅长的是生成代码,而生成速度对一个已经熟悉代码库的资深工程师来说,从来不是瓶颈。他慢在理解上下文、判断设计取舍、审查别人(或AI)写的东西对不对。

AI恰恰在这个环节添了新负担:写提示词、等输出、然后逐行核对一段“看着对、细节可能错”的代码,而这一步原本就是最耗脑力的一步。省下的打字时间,补进了审查时间,账面没有变快,只是把成本从一个环节挪到了另一个环节。

团队和代码库层面的证据对得上

METR的16人样本够小,但把镜头拉远到几千个团队、几亿行代码,方向是一致的。

Faros AI追踪超过一万名开发者的遥测数据发现:高AI采用团队的任务完成量涨了21%,但PR合并量涨了98%,PR平均体积涨了154%,审查耗时涨了91%——产出没多多少,审查环节先被压垮。DORA的年度报告算出更精确的代价:AI采用度每提升25%,交付吞吐量反而掉1.5%,交付稳定性掉7.2%。GitClear拉了2.11亿行代码变更做长期观察(原文有引用写作两亿行,口径上略有出入),看到的是重构占比从四分之一跌到不足一成,复制粘贴代码的比例反超了代码整理,这是有记录以来头一次。

数据来源关键指标变化指向
Faros AI(超万人团队)PR合并量+98%,审查耗时+91%产出未增,审查环节吃紧
DORA年度报告AI采用+25% → 稳定性−7.2%交付质量下滑
GitClear(2.11亿行代码)重构占比25%→不足10%代码越堆越多,越少整理
  • 结论.三条互相独立的数据链,从个体、团队、代码库三个层面,指向同一个机制——生成变便宜了,验证变贵了,而组织没有为审查这个新瓶颈重新配置人力。

仪表盘为什么没人换

这事有意思的地方在于,几乎没有团队专门为“审查”这一环重新调配资源。管理者还在用团队自我报告的“感觉变快”作为AI采购和绩效评估的依据,而这份研究说得很直白:这个感觉,在最资深、最该被信任的人身上,读反了。

工具厂商这边其实已经用真金白银投票。今年夏天,Windsurf这类编程编辑器背后的资本动向,清一色押注“agent-first”——把人从生成代码的键盘前挪开,放到一个专门审查AI产出、决定取舍的驾驶舱里。这个细节缺乏独立信源交叉验证,但方向和METR的结论对得上:市场判断真正的瓶颈已经不是写代码,是审代码。

越自信AI提速的老将,越是被实测拖慢的那批人。

也得说句公道话。这更像是新工具磨合期的阵痛,不必然是终点。J曲线假说站得住脚的地方在于:对初级开发者、对全新项目,试验结果本来就是正的,DORA的吞吐量数据也没有一路走低。但这个假说目前只是假设,没有独立数据验证或证伪,不能当结论用。

  • 风险.如果团队继续拿“感觉变快”当决策依据,大概率是在一个已知会读反的信号上做资源分配。

孙子说“兵者,国之大事,死生之地,存亡之道,不可不察也”,搬来这里未免夸张,但道理相通:决策依赖的仪表,如果本身在系统性说谎,越自信的人反而越危险。停止用感觉判断速度,回头看生产环境里到底稳不稳、审查投入够不够,这才是眼下能立刻做的事。