研究表明即便资深开发者也会严重高估其收益

本文信息来源：secondthoughts

关于 AI 编程工具的炒作从未停歇。根据各种报道，初创公司正以极小的工程团队规模启动项目，非程序员正在”氛围编程”整个应用程序，初级程序员的就业市场正在崩溃。但根据 2025 年春季进行的 METR 实验显示，至少有一个群体仍未能从 AI 工具中获益。

METR 进行了一项严谨研究( 博客文章 ， 完整论文 )来衡量 AI 工具为成熟项目中的资深开发者带来的生产力提升。结果令人震惊：生产力下降了 19%。甚至连研究参与者自己都感到意外：他们原本估计 AI 使自己的生产力提升了 20%。这项研究最重要的启示或许是：当人们声称 AI 加速了他们的工作时，他们可能错了！

这一结果似乎”糟糕得令人难以置信”——如此惊人的结论几乎让人怀疑其真实性。然而该研究设计严谨，我相信结论是可靠的。与此同时，我也确信那些关于生产力大幅提升的坊间传闻至少部分属实。这项研究并非要揭穿 AI 编程工具的骗局，而是提醒我们（至少目前）它们存在重要局限性——这印证了我同事 Taren 在先前文章 《首先，他们瞄准了软件工程师…》 中阐述的观点。

首先，我将说明研究实施过程及信任其结论的原因。

终于，一项关于 AI 编程生产力的严谨科学实验

该研究采用了近乎最严苛的方式：在真实工作场景下进行严格随机对照试验。受试者均为从事日常工作的资深开发人员。

具体方法如下：

1. METR 从各大开源项目中招募了 16 名开发者。

2. 每位开发者从待办清单中选取了一系列编码任务，将大型项目拆解为可在一两小时内完成的子任务。研究共包含246项任务。

3. 开发者们预估了完成每项任务所需时间：(a)常规条件下；(b)不使用任何 AI 工具。两组数据的百分比差异即为预期加速值 ——开发者预期 AI 工具能提升其生产力的程度。

4. 每项任务被随机分配至两个类别之一：”允许使用 AI”（开发者可使用任何工具）或”禁止使用 AI”（开发者不得使用 AI 编程工具或功能）。

5. 开发人员在进行工作时会录制屏幕以供后续分析。每项任务完成后，他们需上报耗时 1。在允许使用 AI 的任务中，他们还需评估 AI 工具节省的时间——即回溯性加速 。

研究人员通过对比开发者预估耗时与实际完成时间，计算出 AI 工具带来的实际加速效果（确切地说是减速效果！）。他们发现允许使用 AI 的任务中，预估与实际时间的差异比禁用 AI 的任务高出 19%2。需注意的是，开发者在估算任务时间时尚未知晓是否使用 AI，因此其预估数据不存在偏差。

该研究设计唯一未能达到科学黄金标准的重要方面在于其未采用盲法： 一旦工作开始，参与者和研究人员都清楚是否使用了 AI 工具。这当然是不可避免的，因为无法合理提供”安慰剂”式的编程辅助工具。不过，研究人员特别排查并找到了证据，排除了包括研究非盲性可能导致偏差在内的一系列替代解释。看起来确实如此——对于本研究所涉及的工作类型，允许开发者使用 AI 工具反而会拖慢他们的进度。

回应你想到的所有质疑，以及一些你没想到的

当我研读这项研究时，曾想到六种可能导致结果混淆或失效的情况。事实证明我的想象力还不够丰富，因为作者们探讨了更多可能的解释。

约翰·亨利效应 ：或许开发者们被”战胜机器”的念头所激励，在禁用 AI 的任务中格外卖力。若是如此，随着实验过程中新鲜感消退（受试者平均需完成 15 项耗时 1-2 小时的任务），这种效应理应逐渐减弱——但研究中并未观察到这种衰减趋势。

AI 使用不足 。也许开发者即便被允许使用 AI 工具也并未实际使用？但这只能解释为何生产力未见提升，却无法解释生产力下降的原因。而离职访谈和屏幕录像分析均显示 AI 工具被大量使用（在允许使用 AI 的任务中，84%的屏幕录像显示至少部分使用了 AI）。

作弊行为 。或许开发者将 AI 工具用于禁止 AI 参与的任务？但即便如此，最多只能解释中性结果，而非生产力下降。离职访谈和屏幕录像仅发现极少数作弊案例。

过度乐观的时间预估 。开发者素来以低估任务完成时间而闻名。但由于开发者在获知能否使用 AI 工具前就已预估任务时间，任何误估效应都应相互抵消。

任务定义偏差 。如果开发者对”允许使用 AI”和”禁止使用 AI”的任务定义方式不同，可能会影响结果。但这种情况已被排除，因为开发者在任务被随机分配到”允许使用 AI”或”禁止使用 AI”类别之前 ，就已明确任务内容并将其分解为耗时不超过两小时的工作单元。

退出效应 。假设某些禁用 AI 的任务在没有 AI 辅助时完成起来很烦人，因此开发者在研究期间没有完成这些任务，导致结果未被记录。这可能会影响研究结果。不过，在总共完成的 246 项任务中，仅有 13 项未完成，且未完成任务在允许使用 AI 和禁用 AI 的组别中均匀分布。

过时的工具 。AI 技术发展迅猛，是否因为使用了过时工具导致结果偏差？但开发者主要使用的是 Cursor Pro 搭配 Claude 3.5/3.7 Sonnet，这些工具在研究期间（2025 年 2 月至 6 月）被视为最先进的技术。

不准确的时间记录 。统计数据基于开发者自述的任务完成时长（包括 PR 评审前后）。但仅使用评审前耗时或屏幕录制时长进行分析，结果依然相似。

上述问题似乎都未影响研究结果。以下是可能导致观测到生产力下降的几个因素。

过度依赖 AI。论文指出”开发者被要求根据自身判断尽可能利用 AI 提升效率”。但部分受试者似乎过度沉迷于此，这可能是导致效率下降的原因之一。在退出访谈中，受试者对 AI 使用方式的描述基本呈三足鼎立态势：”常规使用 AI”（70 项任务）、”尝试性使用 AI”（119 项任务）以及”尽可能多用 AI”（57 项任务）。自述属于第一类别的受试者受 AI 拖累程度较轻（尽管效率仍未获得提升）。

缺乏 AI 工具使用经验 。如果开发者不熟悉 AI 工具，可能会使用不当。结果显示，93%的参与者曾使用过 ChatGPT 等工具，44%接触过 Cursor（当前最流行的专用 AI 编程工具）。这表明参与者的经验水平参差不齐，相当部分人对 AI 工具相对生疏，或许开发者积累更多使用经验后能获得更大收益。但所有开发者在研究过程中都在积累 AI 工具使用经验，从研究开始到结束并未观察到明显的效率提升。（此外，所有参与者在研究开始时都接受了 Cursor 的”实时基础培训”。）

另一个潜在问题在于，部分研究参与者需要从常规开发环境切换至 Cursor 来完成 AI 辅助任务。但”总体而言，开发者反馈这些差异并未对他们的工作流程造成明显不便或影响”。

经验不足似乎不是主要问题，但更擅长充分利用 AI 工具的开发者可能会取得更好的成果。

完整性的差异 。使用 AI 工具的开发者可能扩大了任务范围：例如编写处理更多边缘案例的代码、添加额外功能，或者更彻底地测试或记录代码。作为这一方向的潜在证据，在允许使用 AI 的任务中，开发者编写的代码行数比禁止 AI 的任务多出 47%（按预测任务规模 3 计算）。但研究作者认为，这最多只能算作范围蔓延的薄弱证据。在私下交流中，他们列举了持此观点的若干理由：

• 不同任务间的代码行数差异巨大（有时是由于自动生成的大文件），因此这一测量存在大量“噪音”。将两个含噪数值（允许使用 AI 的任务代码行数与禁用 AI 的任务代码行数）相除，会得出波动极大的结果。观察到的差异“在统计学上不显著”4。

• 研究作者们考察了多种不同指标；可以预见至少会有一项显示出虚假结果（ 这张 XKCD 漫画可谓一针见血）。

• 在人工审查中，作者几乎没有发现 AI 允许任务在本质上存在实质性差异的证据；他们注意到略微倾向于编写更多测试和注释的趋势，但这可能再次是虚假关联。

或许最能证明范围蔓延未导致效率下降的证据是：在开发者未报告范围蔓延的任务中，AI 允许任务的耗时增加更为显著

即使代码行数的差异确实存在，也可能存在负面解释（代码臃肿、重复增多、不必要的花哨功能）和正面解释。

更多时间未必意味着更多付出。 即便开发者使用 AI 工具时耗时更长，他们实际消耗的精力可能更少。审查/修正代码通常（虽非绝对！）比从零编写更轻松，且等待 AI 生成的时间可用于休息或处理其他事务。

总体而言，AI 工具的影响可能没有表面数据那么糟糕：测量到的 19%生产力下降中，部分可能转化为更彻底的工作成果和开发者精力的节省，另部分可解释为研究对象过度关注研究参与而滥用 AI 所致。但这些工具似乎并未带来显著助益，反而可能实质性地损害生产力。这该如何解释？

某些所谓的帮助，实则是我们都不需要的负担

根据离职面谈和屏幕录像分析，研究团队发现导致生产力下降的几个关键因素。最主要的问题是 AI 工具生成的代码通常达不到这些开源项目的高标准。开发者们耗费大量时间审查 AI 的输出结果，这往往导致多次循环：向 AI 提交提示词、等待生成代码、审查代码、因存在致命缺陷而弃用、再次向 AI 提交提示词。（论文指出 Cursor5 生成的代码仅有 39%被采纳；值得注意的是，开发者们可能仍需修改那些”被采纳”的代码。）许多情况下，开发者最终会选择放弃，转而亲自编写代码。

根据屏幕录像显示，以下是开发人员的时间分配情况：

请注意，此图表反映的是任务总完成时间的百分比，而允许使用 AI 的任务平均耗时更长，因此相同高度的绿色柱状图所代表的时间比紫色柱状图更多 6。可以看出，在允许使用 AI 的任务中，开发者花在研究及编写代码上的时间更少（但由于比例问题，实际差异比视觉呈现更为微小）。按比例调整后，他们在”测试与调试”和”git 与环境配置”上花费的时间大致相同，而在空闲状态耗费的时间明显更多——或许是因为等待 AI 工具导致工作流中断。无论如何，在研究及编写代码上节省的有限时间，远不及向 AI 输入指令、等待其生成代码以及审查输出所耗费的时间。

我们该如何调和这些结果与 AI 编码工具创造奇迹的持续报道之间的矛盾？

这就是我曾向你们描述的不均衡未来

去年十二月，我撰文论述过当前 AI 工具在某些方面表现优异，在其他方面却相当糟糕，而这条分界线蜿蜒穿过了我们称之为”软件开发”的工作领域。

在 《首先，他们瞄准了软件工程师…》 一文中，塔伦写道：

通常，生产力的大幅提升主要出现在小型、定义明确的新建项目中，或者当工程师刚开始学习新语言或 API 时。对于其他类型的工作，使用当前 AI 工具带来的收益往往要小得多——甚至可能完全被增加的审查、调试、集成和管理 AI 特性所需的时间所抵消。

该研究的多个方面暴露了当前工具的局限性。首先，研究针对的是拥有庞大代码库的成熟项目。参与研究的项目平均有 10 年以上历史，代码量超过 100 万行——与”绿地开发”形成鲜明对比。完成任务可能需要理解代码库的大部分内容，而这正是当前 AI 工具的短板。（这可能不完全是 AI 模型的内在缺陷，更多是某些编程工具为控制成本、加快响应速度而采取的设计选择——限制发送给模型的”上下文”信息量。）研究还涉及编辑大型文件，这对多数 AI 模型而言可能属于”分布外”情况（即它们可能缺乏针对大型文件的充分训练）。论文中引用了一些开发者的实际案例来佐证这一观点：

在软件开发中，开发者常依赖自身对代码库未文档化的理解来辅助设计和实现决策。我们的研究发现，开发者普遍指出 AI 缺乏这种隐性代码库知识，导致其输出实用性降低。一位开发者表示 AI 的表现如同代码库的新贡献者，并指出”AI 总是选不对需要修改的位置 “。另一位开发者则强调” 我们了解代码交互的数据，但模型不知道这些数据。它不知道我们需要处理这种特殊的向后兼容情况，[因此]必须保留这行特定代码。而这类上下文信息极难[向模型]传达 “。

我们推测，所包含代码库的规模和成熟度会增加经验丰富的开发者在完成工作时所依赖的隐性知识量——由于人工智能系统可能较少接触这类知识，它们在这些问题上为资深开发者提供协助可能会更加困难。

其次，这些开源项目大多有严格的代码风格规范。研究中经验丰富的开发者已习惯按项目规范编写代码，但 AI 工具却做不到——这迫使开发者必须审查并修正 AI 生成的代码。

第三，参与研究的开发者都拥有多年项目经验，意味着他们能以极高效率工作——这为 AI 设定了极高的竞争标准。

关于 AI 工具在实际工作环境中对生产力的影响，已有其他相关研究。2024 年的一项研究发现”完成任务数量增加了 26%”，尽管受试者使用的是旧版工具，而 AI 工具在过去一年已取得显著进步。该研究方法严谨性稍逊 7，但或许更重要的是，这项研究涉及经验较少的开发者参与更广泛的项目。研究指出”经验较少的开发者表现出更高的采用率和更大的生产力提升”，这与新 METR 研究中当前 AI 工具对资深开发者帮助较小的结论一致。

LLMs 在竞技编程中的表现如何评判？

观察到的 19%生产力下降现象，与 AI 在编程基准测试中的优异表现形成鲜明对比——后者在编码竞赛中常达到人类精英水平（尽管近期研究已对此提出质疑 ）。编程竞赛题目具有高度微型化、定义明确、独立性强且属于”绿地开发”（从零开始而非基于现有代码库）的特点，这恰好放大了 AI 的优势。

关于 AI 工具节省时间的热情传闻往往源自大型 AI 实验室内部。这或许部分反映了错位的热情——请记住，这项研究的参与者认为 AI 工具提高了他们的效率，实际上却拖慢了进度。但另一方面，这些实验室中的部分工作确实更适合 AI 工具处理，无论是编写小型训练实验代码，还是为聊天机器人添加 UI 元素。（值得注意的是，并非所有实验室内部人员都报告 AI 编程工具带来了显著价值；这可能反映了工作内容的多样性。）此外，AI 实验室的工程师可能更擅长使用自家工具，并能通过与同事分享技巧而获益。

以下是几篇近期论文的参考资料，内含更多数据点；我尚未阅读这些论文：

兹维·莫肖维茨（ 来源 ）：

新论文介绍了 LiveCodeBench Pro，该研究表明 AI 在竞技编程中的表现并不像我们被引导相信的那样出色 。部分顶级模型看似未经测试，但同一模型的所有得分全面偏低且在难题上均为 0%，因此结论显而易见。[该基准测试值得注意，因为部分题目未公开发布至互联网，从而避免了困扰许多编程基准测试的”记忆化”问题。]

德里克·汤普森（ 来源 ，含论文链接）：

最新研究：当企业使用 AI 编写的代码比例从 0%提升至 30%时，关键生产力指标仅增长 2.4%

伊桑·莫里克（ 消息来源 ）：

尽管个人持续反馈 AI 带来巨大生产力提升，多个行业的对照实验也证实这种提升确实存在，但大多数企业并未观察到显著效果。原因何在？因为从 AI 中获益需要组织层面的创新。

关键要点

这项研究于 2025 年初至中期开展。AI 模型只会在此基础上不断进步。基于这些模型构建的编程应用（如 Cursor）将持续改进，以更好地利用模型 8。开发者也将更高效地使用这些应用——提出正确类型的任务，并为工具提供足够的上下文来实现目标。变化可能来得很快；基于 LLM 的现代编程工具浪潮才兴起短短几年！

AI 工具还将进一步扩展，覆盖软件开发者的更多工作环节，包括审查其他开发者编写的代码、进行测试，甚至审核和测试其他 AI 生成的代码。

这项研究发现 19%的效率下降乍看令人沮丧，但仅适用于 AI 工具面临的困难场景（经验丰富的开发者在高质量标准的复杂代码库中工作），部分原因可能是开发者选择放慢节奏保存精力，或利用 AI 进行更彻底的工作。当然，随着时间推移结果会改善。这篇论文不应被解读为”否定”AI 引发 2027 式软件爆发的可能性，但它可能表明：AI 进步的重要反馈循环可能比预期更遥远——即便某些 AI 研究涉及的小型临时项目或许更适合 AI 编码工具。与此同时，AI 是否正在生成臃肿或有问题的代码，随着 AI 编写代码越来越多，这些问题是否会不断累积，仍有待观察。

但或许最重要的启示在于：即便开发者使用 AI 时完成任务的速度慢了 19%，他们却自认为效率提升了 20%9。许多关于 AI 影响的评估都基于调查或轶事报告，而这里我们获得的硬数据表明，这类结果可能存在显著误导性。

感谢 Nate Rush 和 Joel Becker 让我们提前接触这项研究、回答我不间断的提问并为本文提供反馈，同时也感谢 Daniel Kokotajlo、Joyce Er 和 Taren Stinebrickner-Kauffman 提供的额外视角与建议。