每天来到工位，打开昨天没跑通的代码，

轻啜一口香浓的咖啡，启动Cursor、GPT、Gemini、Deepseek等工具，它们便忙碌地运转起来。

AI进化成编程怪物后，这或许是很多程序员/科研人的日常。

但是，用了AI，写代码一定更快了吗？

METR（模型评估与威胁研究）的研究揭示，一旦你实力出众且对代码库了如指掌，AI工具很可能会成为你的绊脚石。

他们进行了一系列严谨的随机对照试验（RCT），结果惊人——

即便是有百万行代码编写经验的万星repo领域的大师，在运用AI工具执行相同任务时，仍旧需要额外耗费「19%」的时间。

更令人深感忧虑的是，开发者竟然毫无察觉，AI正悄然拖累着他们的步伐！

实验前，他们平均预计AI能提升效率24%。

即便他们已经清清楚楚地观察到了实验中速度降低的现象，他们依旧坚信AI使他们感觉速度提升了20%。

METR把所有的实验设计和结果都放在了论文中：

该研究论文的链接为：https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf，其中详细探讨了2025年早期人工智能在操作系统开发领域的应用情况。

这项研究是怎么颠覆我们对AI写代码的幻

想的？

「变快」是幻觉：AI让开发者慢了19%

具体来说，METR的研究对象被限定在“资深开发者”群体，以及他们所擅长的“大型且成熟的开源代码库”领域。

为了评估AI工具在实际应用中的开发所产生的作用，METR组织了一次招募活动，特别邀请了16位在大型开源项目中长期积极参与的资深开发者。

“资深”二字并非空谈，他们平均每人编写了超过一百万行代码，所维护的GitHub项目更是获得了超过两万颗星。

这些开发者全力以赴，投入实战，从他们日常工作中提炼出了246个具有实际意义的问题。

这些问题涵盖了漏洞修正、新增功能的开发以及架构重构等多项任务，大致情形如下所述。

METR会将每个任务随机分配到两个实验组中，一组可以采用AI技术，另一组则不能使用AI。

在“允许”这一类别里，开发者得以运用各式AI工具，其中以Cursor Pro配合Claude 3.5/3.7 Sonnet等尖端模型为主。

在「不允许」组中，他们不得借助生成式AI。

每个实验任务平均耗费两小时时间，在完成这些任务的过程中，开发者需进行屏幕录制，并且需自行报告所用的总时长。

接着，METR会计算出一个相对变化率，以此作为评估使用AI与否对时间产生影响的指标。

开发者们并非徒劳无功，他们通过METR项目每小时获得150美元的报酬。

这份高额薪资的投入非常划算，经过METR对实验数据的深入分析，我们得出了一个令人震惊的发现：

当开发者得以运用人工智能辅助工具，他们完成任务的平均所需时间却意外地增加了19%。

而且，从下图可以看出，使用AI写代码，全流程都被拖慢了！

这么明显的变慢打破了所有人的预期。

更令人震惊的是，开发者完全感觉不到！

在实验开展之前，他们预期人工智能技术能够将效率提高24个百分点；然而，通过下方的图表，我们可以直观地观察到，在应用AI技术后，开发者的工作时间明显延长了。

尽管他们亲自感受到了“变慢”的体验，但仍然觉得AI“给人感觉”上让他们提速了20%。

然而，METR的研究态度极为审慎，明确指出该实验仅针对特定的开发者群体和项目进行，并不能代表整个软件开发领域的状况，更不适用于推广至其他非软件类任务（诸如法律、写作、设计等领域）。

基准测试、用户体验，都错哪了？

为确保严谨，METR反复审查了自己的实验设计。

他们始终遵循实验的分配规定，并未在AI小组中比其他小组更常放弃难题，而且他们所使用的AI模型也确实是最顶尖的代码版本。

而且，无论是AI协助还是人工操作，两组提交的代码修改请求在质量上并没有显著差异。

既然实验的布局没有出现瑕疵，那么为何在AI编写代码的过程中，基准测试和用户的使用感受却出现了偏差？

METR对实验结果进行了进一步的分析。

首先是更细粒度的思考过程分析：

仔细观摩了这些行业巨擘的屏幕操作视频，METR团队观察到，在启用人工智能辅助后，开发者们在主动编码以及搜索和阅读信息方面所花费的时间显著缩短。

开发者投入了更多的时间在与人工智能进行交流（比如撰写提示）、核实AI生成的输出，以及单纯的等待之中。

METR提出了20种可能导致速度降低的潜在因素，并从中筛选出5个，这些因素可能对最终结果产生重大影响。

一方面，开发者对项目了如指掌，其熟悉程度远胜于那些与团队缺乏默契的AI；另一方面，他们对AI的性能表现抱有过于乐观的预期。

此外，该项目的复杂性较高，这使得AI虽然能快速完成写作，但质量往往不尽如人意，进而导致开发者需要投入大量时间进行调试。

最终，METR研究发现，该研究与以往观点的冲突可能源自于对任务定义及其差异性的界定。

针对AI能否胜任工作这一议题，由于数据来源的差异，所获得的最终结果可能会有很大的出入。

RCT实验关注的核心问题是“在实际的开发流程中，这种方法是否真的能够带来速度上的提升”，基准测试则侧重于考察“模型在既定任务标准下的表现能获得多少分”，而用户们更倾向于表达他们对“使用AI的体验是否愉悦”这一主观感受。

换句话说，结论不一样，是因为本就在回答不同问题。

关注的焦点是日常工作效率的提升，抑或是攻克难题的能力，若转换到不同的应用场合，得出的结论或许会有很大差异。

每种评估方式仅考察了任务空间的一部分，将这些方法综合运用，或许才能全面地了解AI编程的实际能力。

上岗两眼懵？AI编程不能只会刷分

METR的随机对照试验警示我们，切勿因AI基准测试取得的优异成绩而感到惊愕。

所谓的“智能体评测”和“编程竞赛”看似实力不俗，但实际上可能与实际开发水平相去甚远。

在那些无需背景知识、无需深入理解上下文、且不涉及具体实施部署的测试场景中培养出的AI，其表现可能无法与人类开发者相媲美。

对AI的能力不能小觑，同时亦不可过于乐观，误以为AI能够轻易地承担起开发的重任。

未来，用户对AI编程工具的期待不只是「刷分」。

我们想看的是，AI是否真的能把软件开发推进得更快、更好？

若AI真的能够实现这一目标，则表明它具备了不断自我增强进化的能力。

听起来很酷，但也任重道远。

如何衡量人工智能在真实开发与部署过程中的实际能力？又该如何构建一道有效的监管防线，确保项目的安全性？

METR打算继续设计实验，观察AI开发的真实实力。

他们透露，意图汇聚更多开发者和AI编程用户的智慧，共同持续进行探索，以验证AI的实际能力。

不过，不管AI编程拖后腿的证据有多「实锤」，

研究的大多数参与者，包括研究发起者自己，对于被GPT这类技术暂时落后并不感到介意。

面对一张空白的纸张从头开始创作，抑或是在已有的稿件上进行修改润色，尽管前者在速度上可能占优，但大多数人还是会倾向于后者。

归根结底，利用“奴役”AI进行编程，尽管无法提升速度，却必定能带来愉悦。

参考资料：