一项发布于今年7月10日的对照实验，给AI编程效率的争论投下一颗炸弹：METR找来16名有经验的开源开发者，让他们在自己熟悉的代码库里处理246个真实issue，允许用AI的一组，完成任务反而比不用AI的一组多花了19%的时间。更奇怪的是,这些开发者事后被问及感受时,几乎所有人都坚信自己因为用了AI而快了20%。
感觉和实测,方向完全相反。这不是"AI有时好用有时不好用"的老生常谈,而是一个可以被量化、可以被复现的认知偏差:开发者对自己是否被AI帮到,判断力本身就不准。这比"AI偶尔端出焦炭却自信满满"的比喻更进一步——现在连吃这道菜的人,都会被自己的味觉骗了。
两份相反的研究,谁在说真话
METR的发现不是孤例,但也远不是全部真相。GitHub自己做的受控实验显示,用Copilot完成一个JavaScript HTTP服务器任务,比不用快55.8%;另一项针对Python资深开发者的代码质量实验里,202份有效提交中,用Copilot的一方通过全部单元测试的可能性高53.2%,盲审专家还评价其可读性、可维护性更优。Google内部一项针对96名工程师的RCT,处理复杂企业级任务时,AI组耗时估计减少约21%,只是置信区间很宽。
三份研究,三个正向结果,再加上METR一份负向结果。摆在一起看,方向不是巧合,是变量不同。
前三份研究的共同点是任务边界清晰、有测试可验证——写一个函数、跑一批单元测试。METR的任务恰恰相反：真实issue、真实历史包袱、开发者对代码库已经很熟。AI在这种场景里帮不上什么忙，反而因为要理解上下文、核对生成代码，拖慢了节奏。原文那个"牛排机"的比喻,其实模糊了这个区分——AI的表现从来不是均质的好或均质的坏,而是随任务结构剧烈摆动。
感觉会撒谎,这才是最该记住的一条
- 结论.METR的核心发现不是"AI慢了19%"，而是开发者的主观速度感和实测速度可以系统性地对立。
Stack Overflow 2025年的开发者调查佐证了这种撕裂感。52%的受访者认同AI工具提升了生产力,但66%把"差一点就对"的输出列为头号挫败感,45%表示调试AI生成的代码反而更耗时,约75%说自己不信任AI答案时仍会去问真人。生产力提升和体感疲惫,是同一批人同时给出的两个答案。
感觉自己变快了,和真的变快了,是两件不同的事
这也是为什么单靠"我觉得AI帮了我"这种自我报告,不该被当成采购或KPI的依据。企业评估AI编程工具时,如果只看"代码接受率""生成行数"这类自我感觉相关的指标,很容易复制METR实验里那个被戳破的错觉。
厂商研究和排行榜,同样靠不住
GitHub与Accenture的一份企业级研究显示,用AI后拉取请求数量增加8.69%,合并率提高15%,构建成功率提高84%——数字漂亮,但研究方本身就是AI工具的厂商。这不代表数据造假,但意味着读者该多问一句:任务是怎么选的、对照组是怎么设的、结论有没有利益冲突。独立评测和厂商赞助研究给出相反答案时,更该信谁,METR式的第三方RCT至少给了一个参照系。
- 风险.SWE-bench之类的基准测试排名,依赖agent scaffold、prompt设计、token预算等配置,分数高低更多反映"评测环境搭得好不好",不必然代表产品在真实生产环境里的可靠性、可维护性和安全性。
原文说学会写代码才能用好AI,这句话在数据里是有支撑的——但支撑点不是"写更多代码",而是设计出能验证AI输出的工作流:清晰的任务边界、可运行的测试、明确的review标准。METR实验里表现差的那批任务,恰恰是缺少这些验证机制的"糊涂账"。会写代码的人,更容易把任务拆成AI擅长的样子,也更容易在结果出来时看出这是不是"焦炭"。
至于原文那句"每家餐厅都雇了同一个AI厨子"——底层模型趋同确实是行业现实,但差异化会越来越落在谁能设计出更靠谱的验证流程上,而不是换了哪家AI产品。对开发者来说,这意味着基础判断力不会因为工具变强而贬值,反而是唯一不会被同质化模型拉平的东西。对企业管理者来说,采购AI编程工具前,该问的不是"提速多少",而是"这类任务的测试覆盖够不够、代码库熟悉度够不够"——METR已经证明,答案不够时,连感觉本身都会骗人。