Skip to content
Published on

AI 真的让开发者更快了吗 — 被测量出来的数字说了什么

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
分享
Authors

引言 — 互相打架的两个数字

关于 AI 编程工具到底能把生产力提高多少，我们手上有两项设计精良的随机对照试验（RCT）。而它们给出了截然相反的答案。

一项说，用了 AI 的开发者 快了 55.8%。另一项说，慢了 19%。

而这里还有一层反转。后面那个数字，已经不再是"现在"了 — 说这话的，正是造出这个数字的研究团队自己。测出 19% 慢下来的 METR，在 2026 年 2 月发布后续研究的同时，在 2025 年的结果上挂起了一条警告横幅："These results are out of date"（这些结果已经过期），而且它们 "no longer reflect the current impact of AI models"（不再反映当下 AI 模型的影响）。

所以先把本文站的位置说清楚。19% 不是一个错误的数字，而是一个过去的数字。 它是 2025 年上半年真实测出来的值，作为那个时点的记录，至今依然有效。但把它读成"现在用 AI 会慢 19%"，就是误读。METR 自己正是为了让人别这么读，才挂上了那条横幅。

常见的反应是二选一。乐观派引用前一个数字，怀疑派引用后一个数字。可两项都是真实的实验，两项都是真实的结果。有意思的问题不是"谁对"，而是 "什么把这两个数字分开了"；而现在又多了一个 — "为什么把这件事测准，会难到这个地步。"

先把话说在前面：本文最重要的发现，并不是 19% 这个慢下来的数字本身。它一开始就不是，而在 METR 给这个数字贴上有效期之后，就更不是了。最重要的是 人对自己的认知是错的。 而这个发现，没有被挂上任何横幅。之前在 关于 LLM 倦怠的文章 里我说过，生成变便宜了，验证却没有；这一次要看的是，当那道不对称真的被人拿数据测出来时，它长什么样子。

实验之一 — 快了 55.8%

2023 年，Peng、Kalliamvakou、Cihon、Demirer 针对 GitHub Copilot 做了一次对照实验。他们招来 95 名专业开发者，只给其中一半人 Copilot，然后给所有人出了同一道题：用 JavaScript 尽可能快地实现一个 HTTP 服务器。

拿到 Copilot 的那一组，比对照组 快了 55.8% 完成任务。而且好处并不是均匀分摊的：经验越浅的开发者、年纪越大的开发者、工作负担越重的开发者，效果反而越明显。论文作者把这读作一个信号 — AI 也许能帮助更多人进入软件开发这一行。

这个数字至今仍被频繁引用。可每次被引用的时候，几乎总有一样东西被漏掉：这场实验的任务，到底是哪一类任务。

  • 它是绿地项目。 没有既有代码库。没有会缠上来的遗留代码，也没有会被弄坏的调用方。
  • 它是自足的。 整道题一次就能装进脑子里。
  • 规格是明确的。 对于"HTTP 服务器"该做什么，几乎没有可争论的余地。
  • 验证便宜得不像话。 服务器能起来、能响应，就结束了。几秒钟就能确认。
  • 测的是速度，不是质量。 半年之后由谁来维护这段代码，不在实验的范围之内。

也就是说，55.8% 不是谎话，而是 一个在极其特定的条件下为真的数字。 问题在于，大多数一线开发者一天里的大部分时间，都待在那些条件之外。

实验之二 — 2025 年初，慢了 19%

2025 年，METR（Becker、Rush、Barnes、Rein）测的正是那个"之外"。论文题目是 "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"。请记住，题目里钉着 Early-2025 这几个字。后面会变得很重要。

设计是这样的。16 名 资深开源开发者，各自带来 自己维护的仓库里真实存在的 246 个 issue。 每个 issue 被随机分配到"允许使用 AI"或"禁止使用 AI"。参与者主要使用 Cursor Pro 和 Claude 3.5/3.7 Sonnet，实验从 2025 年 2 月一直进行到 6 月。

这里最关键的，是 开发者与代码库之间的关系。

  • 这些仓库平均已有 10 年以上历史，是成熟项目，代码超过 100 万行，star 数超过 2 万。
  • 开发者们在这些仓库里平均工作了 5 年，累计提交平均达到 1,500 个。
  • 也就是说，他们身上装着大量关于这份代码、却从未被写进文档的隐性知识。

结果是 允许使用 AI 时，完成任务的时间反而多出了 19%。 也就是变慢了。用作者们的话说，"allowing AI actually increases completion time by 19%" — AI 工具让开发者慢了下来。置信区间为 +2% 到 +39%，并不包含 0。这意味着在统计上，方向也是清楚的。

这一段的动词全部用过去时，是有原因的。这是对 2025 年 2 月到 6 月那个世界的一次测量。而那个世界，后来变了。

后来发生的事 — METR 的 2026 年后续研究

2026 年 2 月 24 日，METR 公布了把同一个实验继续跑下去之后的结果。题目是 "We are Changing our Developer Productivity Experiment Design"。也正是在同一时间，2025 年那篇论文的上方多了一条警告横幅。一个研究团队亲手把自己代表作的头条数字摘下来，这种事并不常见。所以，我们直接来看新的数字。

  • 老参与者（returning developers） — 提速 -18%，置信区间 -38% ~ +9%
  • 新招募的参与者（newly-recruited developers） — 提速 -4%，置信区间 -15% ~ +9%

这里必须同时读出两件事。

第一，点估计值依然是负的。 即便换上 2026 年初的工具，在这个设定下测出来的均值，依然不是"变快了"。所以这次更新，并 不是 在说"原来 AI 真的让开发者更快"。那样读，只是把原来的误读朝反方向再犯一遍。

第二，可是这两个置信区间都跨过了 0。 和 2025 年的 +2% ~ +39% 不同，2026 年的数值把变慢和变快同时装了进去。也就是说，统计上无法确定符号。2025 年还能断言"变慢了"，用 2026 年的数据却说不出这句话。

不过，比数字更重要的东西还在后面：METR 一并报告的 参与者自我选择偏差。

要做这样的实验，就得对开发者说："这项任务请不要用 AI 做。"可到了 2026 年，拒绝这么做的人变多了。用 METR 的说法，退出研究的开发者显著增加，理由是 "because they do not wish to work without AI"（因为他们不想在没有 AI 的情况下工作）。在留下来的参与者内部也一样：30~50% 的开发者告诉 METR，有一部分任务他们干脆没有提交，理由是 "they did not want to do them without AI"（因为他们不想在没有 AI 的情况下做那些任务）。

看出为什么这是致命的了吗。所谓"不想在没有 AI 的情况下做的任务"，恰恰就是 AI 最可能帮上大忙的任务。 而正是这一类任务，被系统性地从样本里剔了出去。METR 自己明确写出了这个偏差的方向 — 它会把 AI 提速的估计值往下拽（"likely biases downwards our estimate of AI-assisted speedup"）。

所以 2026 年的 -18% 和 -4%，本身并不构成"AI 让人变慢"的证据。它们是 从那些没有拒绝无 AI 工作的人身上、在他们自己判断"不用 AI 也没问题"的任务上 得出的数值。

那么 METR 究竟得出了什么结论。他们认为，和 2025 年初的估计相比，如今的开发者很可能确实因为 AI 而变快了（"developers are more sped up from AI tools now"）。但紧接着就补上了限定 — 由于实验中的选择效应，"our data is only very weak evidence for the size of this increase"（我们的数据对于这个增幅的大小，只是非常微弱的证据）。

这就是我们目前能拿到的最好的答案。大概是变好了。到底好了多少，我们也不知道。 这是全世界最认真测量这个问题的团队，在跑完第二轮之后交出来的结论。请记住它。本文的最后还会再用一次。

真正的发现 — 认知与实测之间的落差

19% 已经是过去式了。但 2025 年那项研究里，还有一个没有被挂上横幅的发现。而本文的建议，真正踩着的正是那一个。

  • 实验 开始之前 开发者们预测，AI 会让自己 快 24%。
  • 等实验 全部做完 之后，也就是亲身经历了实际慢下 19% 的过程之后，他们估计自己 快了 20%。
  • 顺带一提，经济学专家预测能缩短 39%，机器学习专家预测能缩短 38%。所有人连方向都搞错了。

这不是"预测错了"的故事。这是 连事后回顾都错了 的故事。对刚刚做完的事情，他们的记忆和秒表指向了完全相反的方向。认知与实测之间，裂开了大约 40 个百分点的缝隙。

为什么会这样。一个说得通的解释是：因为生成是看得见的，而验证是看不见的。

模型在 3 秒里吐出 40 行代码的那个瞬间，是强烈的，会留在记忆里。而读那 40 行、怀疑它的前提、对照这个仓库的规矩、最后扔掉一半的那 20 分钟，不会留在记忆里。那感觉就只是"在干活"而已。我们用多巴胺跳动的瞬间给一天打分，却不把被悄悄磨掉的时间记进账本。

METR 的数据支持这个解释。开发者最终接受的 AI 生成代码 不到 44%。其余的时间，都花在读、判断、丢弃上了 — 而且没有留下任何产出。此外，参与者中真正因为 AI 而变快的，只有 大约四分之一 的人。

这里要再强调一次。这个发现上面，没有挂任何有效期横幅。 METR 说过期的是提速的幅度，而不是"人有多读不懂自己的提速"。工具已经过了一代，但没有任何证据表明，使用这些工具的人，其自我计量的能力在这期间变好了。

是什么把两个实验分开了

把两个实验的差别压缩成一句话，是这样的。AI 在替你补上你没有的上下文时会赢，在必须追上你已经拥有的上下文时会输。

Copilot 实验的参与者面对的是一块空白屏幕。模型填进去的每一样东西，都是净收益。METR 实验的参与者，脑子里已经装着 5 年份的隐性知识。模型不知道那些上下文，要让它知道就得写提示词，拿回来的结果又得重新对照那些隐性知识去检查。一个人的上下文越丰厚，让模型追上他的代价就越高。

METR 作者们戳中的最锋利的一点就在这里。在 2025 年的实验里，开发者们 在自己越熟悉的 issue 上，反而慢得越多。 熟悉不是盾牌，而成了一笔税。

2026 年的数据也没有和这个方向相悖。长期守着自己仓库的老参与者是 -18%，新加入的参与者是 -4%。熟悉的那一边慢得更多。不过两个置信区间重叠得很厉害，把这称为"证据"就过了。与假设不矛盾 — 只写到这个程度为止。

所以，实务上能用的坐标轴有两条 — 熟悉度 与 验证成本。

  • 陌生领域 + 验证便宜 — AI 赢得最稳的那一格。第一次用的语言、不熟的 API、一次性脚本、搭脚手架。错了立刻就看得出来，而模型补上的正是你原本不知道的东西。放手用。
  • 熟悉领域 + 验证便宜 — 样板代码、重复模式。收益不大，但损失也不大。无功无过。
  • 熟悉领域 + 验证昂贵 — METR 的那一格。微妙的逻辑、老代码里的不变式、只有你才知道的坑。自己直接写，可能还更快。
  • 陌生领域 + 验证昂贵 — 最危险的一格。 你没法评审自己看不懂的东西。在这里，AI 的输出会悄悄变成技术债，而账单通常几个月之后才寄到。如果你正站在这一格里，该换的不是工具 — 得先去把那个领域学会。

这四格现在依然是一张能用的地图。只是如今必须补上一句：这是假设，不是被测量出来的定律。 所以你在哪一格，只能由你自己去测、自己去确认。

换到组织的尺度看 — DORA 与 Stack Overflow

个人层面的错觉，到了组织层面会长成什么样子。2025 年的 DORA 报告（State of AI-assisted Software Development）调查了大约 5,000 名技术专业人士。

采用率这件事基本已经没什么好争的了。约 90% 的开发者在用 AI，超过 80% 的人回答生产力提高了。而 DORA 认为，AI 确实提高了吞吐量（throughput） — 到这里为止都是乐观的。

问题在于，同一份报告也说，AI 同时也把不稳定性（instability）一起抬高了。 代码被更多、更快地造出来，下游那些薄弱环节就会原样暴露出来。如果没有自动化测试、成熟的版本管理、快速反馈回路这类控制装置，变更量的增加会直接变成不稳定。

所以 DORA 的结论是：AI 是一台放大器。 AI 会把组织既有的长处和短处一起放大。架在健康的工程系统之上，成果会累积；架在坏掉的系统之上，就只是 更快地量产低质量的产物 而已。只有速度而没有稳定性，那不过是被加速的混乱。

Stack Overflow 的 2025 年开发者调查（约 4.9 万名受访者）补上了最后一块拼图。使用率和信任度，正朝相反的方向移动。

  • 正在用或打算用 AI 工具的受访者占 84% — 比上一年的 76% 有所上升。
  • 但是，不信任 AI 输出准确性的回答占 46%，高于 信任 的 33%。
  • 回答"非常信任"的只有 3.1% 而已。
  • 最大的不满，是 66% 的人选出的 "几乎正确，但并不完全正确的答案"。第二位是 45% 的人选出的 "调试 AI 写的代码反而更花时间"。

"几乎正确，但并不完全正确" — 这就是贯穿全文的那句话。明显错误的代码，筛起来很便宜。贵的是那种 像得让你想去相信、错得让你要付出代价 的代码。而筛掉它们的那份劳动，不会出现在任何仪表盘上。

那么，该做什么

这些数据并不是在说"别用 AI"。真正该做的事，另有其事。

1. 别信感觉，去实际测量你自己的工作。 这项研究的教训正是"回顾会撒谎"，所以你需要的不是记忆，而是记录。而且 METR 2026 年的后续研究非但没有削弱这条建议，反而加强了它 — 如果一支专职研究团队把随机对照试验跑了两轮都还确定不了符号，那么你在一天结束时的印象，就更确定不了。工具不必搞得很隆重。开始一项任务之前写一行预估耗时，做完之后写下实际耗时和有没有用 AI。哪怕只攒两周，它对你来说也比任何问卷都准确。没有被测量的生产力提升，不过是一种心情。

2. 用熟悉度和验证成本来挑选任务。 拿上面那四格当尺子就行。陌生而验证便宜的活，尽管用；熟悉而验证昂贵的活，用得吝啬些。而对陌生且验证昂贵的活，先投入学习，再投入工具。

3. 把评审当成一等的工作，写进预算里。 生成越接近免费，瓶颈就越是整体挪向验证。只要还把评审当作"真正的工作做完之后的杂事"，多出来的成本就会一直留在账本之外。这一点在 LLM 倦怠那篇文章 里谈得更细。

4. 把厂商给的数字当成基准测试来对待。 也就是说：抱着怀疑。只要你记得 55.8% 是从什么样的任务里跑出来的，下次看到营销材料上的数字时，你就会问同样的问题 — 是什么任务，谁测的，漏掉了什么。而现在，问题又多了一个：这个数字是什么时候测的。 评测数字会如何摇摆，在 在 AI 编程模型评测中分辨信号与噪声 里谈过。

5. 写让人能读懂的代码。 如果验证是瓶颈，那么可读的代码就不再是品味问题，而是吞吐量问题。这正是 即使 AI 来维护你的代码，也要为人类而写 里说的事。

读这些数字时，诚实的注意事项

本文的论点不该被读成"研究已经证明 AI 没用"，所以我把双方的局限都明明白白写下来。

METR 2025 年研究的局限。 参与者只有 16 名。样本很小。它测的只是一个特定设定（大规模、成熟的开源仓库，高水平的维护者）。参与者中有 56% 从未用过 Cursor，模型是 2025 年上半年的 — 按今天的标准，已经是隔了一代以上的工具。作者们自己就明确写过，这个结果 并不 说明以下几件事：AI 无法让大多数开发者变快；在别的领域也是如此；不久的将来的 AI 在同样的设定里也会失败；以及不存在把现有 AI 用得更好的方法。这四条都不是这项研究的主张。而如今，作者们还在上面又加了一条有效期警告。

METR 2026 年后续研究的局限。 在某种意义上更严重。自我选择偏差正在啃食实验的骨架。拒绝无 AI 工作的开发者越多，留下来被测量的东西就越是偏向"不用 AI 也没关系的任务"。METR 明确指出这个偏差的方向（把估计值往下拽），这很诚实，但知道方向并不等于知道大小。所以 2026 年的数值，是带着更宽的置信区间和更弱的结论出来的。而且这个问题不会随时间好转，只会 越来越糟。 AI 越有用，能凑齐的"无 AI 对照组"就越难找。METR 把后续文章的标题干脆定成"我们要改实验设计"，原因就在这里。

Copilot 研究的局限。 任务只有一道，是绿地项目，而且自足。测的是完成时间，不是代码质量，也不是可维护性。作者中包含 GitHub 的研究者，这一点也值得记下来。

DORA 和 Stack Overflow 的局限。 两者都是自我报告的问卷。而正因为 METR 揭示的那个理由，恰恰在这个主题上，自我报告是最不可信的工具。

所以诚实的结论不是"AI 会让你变慢"。诚实的结论是三句话：效果会随上下文而变，连符号都会翻转。这个符号，即便用设计良好的随机试验也读不干净。而靠你的感觉，就更读不出来。

结语

我们习惯对工具发问："它好还是不好。"这些数据说的是，这本身就是个错的问题。同一件工具，在一场实验里带来 55.8% 的收益，在另一场实验里造成 19% 的损失。工具没变，变的是 任务的种类，以及做这件事的人所处的上下文。

而在这之上，还叠着一层。就连 19% 这个数字，如今也已经不是"现在"，而是"那时"的值了。是造出这个数字的人自己这样标注的。后续实验没能确定符号，原因不是数据不够，而是 因为拒绝无 AI 工作的人越来越多，干净的对照组本身正在消失。

到这里，你可以变得谦逊，也可以反过来把结论攥得更紧。我认为是后者。想一想：一支专职的研究团队，设计了随机对照试验，从真实仓库里收集了数百个真实 issue，试了两次。而他们最后交出来的结论是："大概是变好了，只是关于这个幅度，我们只有非常微弱的证据。"

如果他们手里握着秒表都无法确定符号，那么你光凭感觉，是不可能知道的。 这才是本文真正的结论。而 2026 年的更新，并没有动摇这个结论，只是把钉子敲得更深了一寸。

而那些慢了 19% 的人，却相信自己快了 20% — 那道裂缝，至今还在原处。我们大多数人，此刻依然站在和他们相同的位置上：对自己的生产力抱着确信，却从来没有把那份确信真正测量过一次。

所以，如果这篇文章你只带走一样东西，我希望是这个。多用 AI 也好，少用 AI 也好，都无所谓。只是 接下来的两周，请把你的工作时间真正记录下来。 你有一个 METR 没有的优势：你要处理的样本只有一个，而且 那个样本不会拒绝参与。 那份数据，会比任何基准测试、任何厂商材料都准确 — 而最重要的是，会比你自己的感觉准确。

参考资料

Discuss on Twitter • View on GitHub