| huozm32831 | 2025-07-13 18:12 |
 新智元报道 编辑：海狸 【新智元导读】别自欺欺人了！METR重磅实测揭穿AI编程真相：GPT等工具让顶尖程序员写代码平均慢了整整19%！效率不升反降、体验爽感成了错觉安慰剂？开发现场变「高科技马车」，AI正在拖垮真正的高手！ 每天来到工位，打开昨天没跑通的代码， 抿一口咖啡，指挥Cursor、GPT、Gemini、Deepseek...吭哧吭哧干活。  AI进化成编程怪物后，这或许是很多程序员/科研人的日常。 但是，用了AI，写代码一定更快了吗？ METR（Model Evaluation & Threat Research）研究发现，如果你够强、对代码库够熟悉，AI工具反而会给你拖后腿！  他们进行了一系列严谨的随机对照试验（RCT），结果惊人—— 哪怕是写过百万行代码的万星repo大佬，使用AI工具时，干同样的任务，也会多花「19%」的时间！  更令人「细思恐极」的是，开发者完全意识不到AI在拖他们的后腿！ 实验前，他们平均预计AI能提升效率24%。 即便在明明白白看到「变慢」的实验结果后，他们还是认为AI让他们快了20%。 METR把所有的实验设计和结果都放在了论文中：  论文链接：https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf 这项研究是怎么颠覆我们对AI写代码的幻 想的？ 「变快」是幻觉：AI让开发者慢了19% 具体而言，METR把研究限制在了「资深开发者」和他们熟悉的「大型、成熟开源代码库」这个范围里。 为了测量AI工具在现实中的开发影响，METR招募了16位长期活跃于大型开源项目的资深开发者。 「资深」二字可不是说说而已，他们人均100万+行代码，维护的GitHub项目有22k+颗星。 这些开发者真刀真枪上阵，从他们日常工作流中收集了246个真实有价值的问题。 这些问题包括bug修复、新功能开发和重构任务等，大概长下面这样👇  METR将每个任务随机分配「允许使用AI」或「不允许使用AI」的对照实验组中。 在「允许」组中，开发者可以使用任何AI工具（主要是Cursor Pro搭配Claude 3.5/3.7 Sonnet等前沿模型）。 在「不允许」组中，他们不得借助生成式AI。 实验选择的每个任务平均耗时2小时。完成任务的同时，开发者需要录屏，并自报所用总时间。  随后，METR计算一个相对变化率，来衡量用不用AI的时间影响。 不过，开发者们也不白干活，METR按每小时150美元给他们付「工资」。 这笔高时薪开得很值，METR分析实验结果后发现了惊人的结论： 当开发者可以使用AI工具时，他们完成任务的平均时间反而增长了19%！ 而且，从下图可以看出，使用AI写代码，全流程都被拖慢了！  这么明显的变慢打破了所有人的预期。 更令人震惊的是，开发者完全感觉不到！ 在实验前，他们预计AI能提升效率24%；但从下图可以清晰看出，使用AI后，开发者用时显著增加。  然而，即便在亲身体验「变慢」后，他们仍认为AI「感觉上」让他们快了20%！ 不过，METR非常严谨，声明实验仅研究特定开发者与项目，不代表整个软件开发行业，更不能推广到非软件类任务（如法律、写作、设计等）。 基准测试、用户体验，都错哪了？ 为确保严谨，METR反复审查了自己的实验设计。 他们严格遵守实验分配规则，没有在AI组更频繁放弃难题，使用的AI也确实都是最强代码模型。 并且，有AI和无AI组提交的PR（Push Request）质量也没什么大差别。 既然实验设计没问题，那在AI写代码这件事上，为何benchmark和用户体验都错了？ METR对实验结果进行了进一步的分析。 首先是更细粒度的思考过程分析： 细细看了这些大佬开发者的屏幕录像后，METR发现，允许使用AI时，开发者在主动编码以及搜索/阅读信息上的时间减少了。 相对应的，开发者将更多时间花在了与AI 交互（如编写提示）、审查AI输出的结果，以及「干等」上。  METR进一步设想了20个可能导致变慢的因素，发现其中有5个可能对结果有显著贡献：  一方面，开发者对项目已经非常熟悉，远超和团队没有默契的AI；另一方面，他们对 AI 效能有点过度乐观。 另外，项目本身也很复杂，导致AI写得快但写得烂，开发者还要花很多时间调试。 最后，METR发现，这项研究与此前观点的矛盾似乎来源于任务的定义和区分。 对AI是否「能干活」这一问题，数据来源不同，得出的结论可能完全不同。  RCT实验聚焦的是「现实开发流程中是否真的更快」，基准测试关心「模型在任务标准下能打几分」，而用户主要反馈「AI用起来爽不爽」的主观感受。 换句话说，结论不一样，是因为本就在回答不同问题。 关心的是「日常提效」，还是「攻坚能力」，换换使用场景，答案可能完全不同。 每一种方法评估的都只是任务空间的子集，组合起来，或许才能客观认识AI编程的真实战力。 上岗两眼懵？AI编程不能只会刷分 METR的RCT实验提醒我们，别被AI基准测试的高分吓到了。 那些所谓的「智能体测评」「编程大赛」，看起来挺能打，实则可能离真实开发差得远。 在不需要背景、不需要理解上下文、不涉及实际部署的测试任务中训出来的AI，未必能赶上人类开发者的表现； 我们不能低估AI的能力，更不能过度乐观，觉得AI能轻松接管开发。 未来，用户对AI编程工具的期待不只是「刷分」。 我们想看的是，AI是否真的能把软件开发推进得更快、更好？ 一旦AI真能做到这一点，那就意味着AI能够「无限赋能」自身的进化。 听起来很酷，但也任重道远。 如何评估AI参与真实开发部署的能力？如何设立监督护城河，保证项目安全？ METR打算继续设计实验，观察AI开发的真实实力。 他们表示，想要集结更多开发者、AI编程用户的力量，一起继续搞实验，看AI到底行不行。 不过，不管AI编程拖后腿的证据有多「实锤」， 研究中的大多数参与者，甚至研究作者本人，都并不介意被GPT之流拖一拖后腿。 面对一张白纸从零开始，或是对着一篇草稿进行编辑，即使前者更快，大家想必也都会选择后者。 毕竟，「奴役」AI写代码，虽然没法更「快了」，但一定更「快乐」。 |
|