AI 编程到底提效了吗？别把三种证据当一个结论

一个开发者说，AI 让他十分钟搭好了原型；另一个开发者说，检查 AI 的改动比自己写还慢。这两句话可以同时成立。原型搭建、成熟项目修改和长期维护，本来就不是同一种工作。“提效”如果没有说明任务、完成标准和计时方式，很容易变成各说各话。

对技术负责人，更有用的问题是：在我们的任务上，AI 减少了哪部分投入，又把工作移到了哪里？本文以 METR 的几次公开研究为线索，解释怎样读懂看似冲突的结论，并给出一份团队可以采用的评估方法。资料截至 2026 年 9 月 5 日；这里没有 EveryInfra 内部效率实验，也没有对任何模型做排名。

“慢了 19%”究竟测量了什么

METR 在 2025 年 7 月发布的研究中，让 16 位熟悉各自开源项目的开发者完成 246 项真实任务，并按任务随机分配是否允许使用当时的 AI 工具。在这个研究条件下，允许 AI 的任务完成时间增加了 19%。研究涉及的是 2025 年初的工具和特定工作场景，不是 2026 年所有开发活动的统一结果。

这个限定不是为了淡化结果，而是为了保留结果的用途。一个熟悉大型仓库的维护者，已经知道项目惯例、历史取舍和容易出错的地方。模型给出的第一版改动即使看上去合理，也可能需要对照这些背景重新检查。另一方面，进入陌生项目、做一次性数据处理或快速验证想法，面对的约束可能不同。

因此，拿这项实验直接宣布“AI 编程没有用”，超出了证据；把它解释成“只要会写提示词就一定能提效”，同样没有依据。它更适合提醒我们：主观感觉和完成任务所需的时间，不一定一致。

在当时的 Hacker News 讨论中，读者也提出了样本规模、项目熟悉度和后续返工应该如何计时的问题。这些评论可以帮助补齐评估问题，但不能当成新的实验结果。尤其不能把一句形象的经验比例，写成适用于所有项目的统计规律。

2026 年的后续材料，为什么不能只截取一个新百分比

到了 2026 年 2 月的实验设计更新，METR 明确指出：后续实验出现了参与者和任务的选择偏差，多 Agent 并发也使时间记录更困难。部分开发者不愿参与需要放弃 AI 的任务安排。研究者认为工具带来的帮助可能在增大，但现有数据不足以可靠估计增长幅度。

这不是“旧实验被推翻了”。旧实验依然描述它当时研究的场景；后续材料则提醒我们，新环境下连研究对象和测量方式都在变化。更积极使用 AI 的人可能没有进入样本，最适合 AI 的任务也可能没有被提交。

对企业试点，这个问题很实际。如果只统计愿意展示成果的使用者，容易漏掉失败或放弃的任务；如果只让对 AI 不熟悉的成员参与，又可能把学习阶段的摩擦当成长期效果。两种选择都可能改变结论。

我们的建议是：先记录任务如何进入试点，再看平均结果。保留哪些人没有参加、哪些任务被排除、排除原因是什么。这里不需要收集无关个人信息；一张按任务类别归纳的记录，就比只展示几个成功演示更有解释力。

做得快、产出多、价值高，不是同一个数字

METR 在 2026 年 5 月的技术工作者调查中进一步区分了速度与价值。调查覆盖 349 名技术工作者，受访者自报的工作价值倍数中位数，按不同问法在 1.4–2 倍之间；速度倍数的自报中位数为 3 倍。这里说的是问卷中的主观估计，不是经过随机实验确认的团队生产力提升。

为什么这两个指标可能不同？设想团队用 AI 很快生成了多个内部演示页面。如果这些页面帮助确认了一个重要需求，价值可能很高；如果它们没有进入任何决策，代码和页面数量虽然增加了，业务价值却未必跟着增加。这是假设示例，不是某家公司的研究样本。

反过来，AI 帮工程师少查几次文档、减少频繁切换工具，可能改善工作体验，即使项目最终交付日期没有明显变化。体验改善值得记录，但不应被改写成已经节省了同等比例的人力预算。

我们倾向于把三个问题分别问清楚：同样的任务是否更快完成，达到相同标准需要多少人工投入，完成的任务是否更值得做。把它们合成一个“效率提升倍数”，反而会丢掉最能帮助团队调整工作方式的信息。

团队自己的评估，先把“完成”定义好

在接入新工具前，先固定一个双方都认可的完成标准。例如，一个 API 接入任务可以要求：正常路径能工作、关键失败能够解释、必要测试通过、交接者能理解限制。具体项目可以增减条件，但不能在看到 AI 输出后，为了让结果好看而降低要求。

随后分开记录两种时间。第一种是任务从开始到被接受的日历时间，包含等待；第二种是人实际投入的时间，包含理解需求、准备上下文、审查和返工。多个 Agent 并发时，机器各自运行的分钟数不能直接相加当作人的工时，也不能把等待时间全部当成已经节省的时间。

一份足够开始试点的记录，可以只包含这些字段：

• 任务类型、复杂度判断，以及成员对代码库的熟悉程度。
• 使用的工具和版本、是否有 AI 辅助、由谁负责最终验收。
• 首版产生时间、达到既定完成标准的时间、实际人工投入。
• 审查发现的问题、返工次数，以及后续发现的缺陷。
• 任务的业务目的；是否最终采用，未采用时为什么。
• 中断、失败和主动放弃的任务，不能从记录里消失。

这份清单是我们的评估建议，不是 METR 的实验复刻，也不保证能从很小样本中得到显著结论。它的首要用途，是发现工作具体卡在生成、验证还是交接阶段。

如果现在最大的摩擦来自接口不匹配，先换一个更强的模型未必解决问题。例如，SDK 能构造请求，不代表服务支持同样的参数或响应方式。站内的 OpenAI SDK 与 Gemini 迁移边界讨论了这类兼容性判断；这些接入约束也应进入试点任务的完成标准。

小样本应该帮助决策，不应该制造宣传数字

评估一段时间后，先按任务类型拆开看。如果低风险、结构明确的任务节省了人工，而跨模块修改带来了更多审查，那么下一步可能是调整 AI 的使用范围，而不是对所有任务统一加大或停止使用。

看到结果时，还要检查是否改变了任务难度和质量要求。原来一个任务需要完整处理错误，现在只完成正常路径，两者不该直接比较。原来写一份能够交接的方案，现在生成十份无人采用的草稿，也不能仅按份数判断产出增长。

工具成本可以作为一个维度，但要与人工复核、失败重做和维护投入一起看。没有可靠记录时，就承认暂时无法计算，不把 API 调用次数或生成代码行数包装成投资回报。有关如何把任务适配、失败行为和费用口径放在一起比较，可以参考 API 选型指南。

METR 另有一篇科学传播说明，专门讨论如何呈现容易被误读的研究结果。对企业内容同样适用：保留不讨巧的限制，往往比挑一个最醒目的数字更能让读者判断是否适合自己。

“AI 编程是否提效”不会因为增加一篇观点文章就有统一答案。但团队可以把问题变得更可回答：在哪类任务、什么工具版本和完成标准下，人工投入减少了多少，质量有没有变化，结果是否真正被采用。先得到这种有边界的答案，再决定扩大使用范围，比争论一个脱离任务的效率倍数更有用。