研究实证：AI 编程助手无法让你成为 10x 开发者

这个行业里每个人正在告诉自己的谎言

此刻，某位技术 leader 正在制作一份 PPT。上面有一张图，图中显示"AI 生成的代码"呈上升趋势。这张图将被用来支撑下个季度的人员招聘计划。

这张图建立在一系列被广泛传播的误解之上，以至于一群研究人员——Jenna Butler、Margaret-Anne Storey、Travis Lowdermilk、Steven Clarke 和 Emerson Murphy-Hill——专门发表了一篇论文来戳破它们。论文发表在 ACM Queue 上，题为"软件工程与 GenAI 的八个误区"，上线不到一天就登上了 HN 榜首，获得 200+ 点赞和 160+ 评论。它把大家心知肚明但不愿说出口的真相摆到了台面上：大多数你对 AI 与开发者效率的认知，要么未经证实，要么干脆就是错的。

我深入研读了这篇论文、相关原始研究，以及它引发的讨论。以下是经得起数据检验的结论。

Myth 1: "AI 将大幅提升编码速度，因此也提升了工程效率"

这个等式根本不成立，从来就没有成立过。开发者大约只有 14% 的时间在写代码。其余时间花在设计、会议、代码评审、调试和协调沟通上。

即便你把编码速度提升到无穷大，你的总体生产力提升也最多被卡在 15% 以下。实际上，企业层面 AI 工具带来的代码吞吐量提升约为 7.8%——距离厂商在 PPT 里宣传的"10 倍"差得太远了。

如果你的 AI 采用策略只针对软件交付的敲代码阶段，那你只是在优化一份工作中 14% 的环节，却称之为转型。

Myth 2: 代码行数是一个生产率指标

2014 年就有首批研究推翻了这一点，用代码行数衡量生产率从来就不合理。现在 AI 能更快生成更多代码，但这并没有解决这个指标本身的问题。

"用代码行数来衡量软件生产力，就像用飞机的重量来衡量飞行进展一样荒谬。"

然而，AI 生成的代码行数（LoC）正是目前工程仪表盘上出现的指标，因为它是从 Copilot API 中最容易获取的数字。容易测量和有意义根本不是一回事。围绕它优化只会导致 diff 膨胀、评审负担加重——这就引出了：

Myth 3: AI 生成的代码会像人类代码一样被接受

即便在内部大规模运行 AI 编程工具的企业中，AI 生成的 PR 也只有大约一半会被合并。约 15% 被直接放弃。另有 15% 卡在那里等待人工评审——评审者对代码不够信任，不愿意快速通过。

这不是合并流水线。这是一堆没人愿意认领的工作队列。

Myth 4: AI 的收益在不同任务中保持一致

如果你一直在从 demo 推算，这一点最值得警惕。实际效果因任务类型差异极大，在一项著名的对照研究——METR 试验中，有经验的开源开发者在使用 AI 工具后，在他们熟悉的代码库上处理真实任务时，速度反而慢了 19%，而不是更快。

更扎心的是：这些开发者在开始之前预测自己会快 24%，而且即便实际完成得更慢，他们仍然相信 AI 让自己的速度提升了约 20%。自我报告的生产率不是数据，它只是一种感觉——而这种感觉目前正在欺骗你。

Myth 5: Prompt 足够确定性，以至于上下文无关紧要

用两个语义相同的 prompt 跑一遍，你不会得到语义相同的代码：

Prompt A: "Write a function that validates a US phone number"
Prompt B: "Return true if the input string is a properly formatted
           US phone number, false otherwise"

人类读起来这两条完全一样。但实际上，研究人员发现，语义等价的 prompt 产生了不同代码的情况占 46%，导致功能正确性改变的情况占 28%。熟悉的任务比陌生的任务收益更大。你的效果不稳定，不是因为你 prompt 写得不对，而是因为这个工具在本质上是非确定性的——而代码行数仪表盘根本看不到这一层。

Myth 6: 开发者普遍害怕被替代

末日论更多是媒体报道的叙事。只有约 10% 的开发者表示真正担心工作会被取代。大多数人认为 AI 能把他们解放出来，去做架构设计、技术辅导，以及那些本来就不会被自动化的部分。如果你们团队的士气问题是"AI 要来抢工作了"，这是管理层的故事，不是普通开发者的真实心态。

Myth 7: 高使用率意味着高信任度

对于将 AI 生成的代码部署到生产环境的任何人来说，这个鸿沟应该让你夜不能寐：80%+ 的开发者定期使用 AI 工具，但只有 29% 信任其输出的准确性。采用率和信心已经完全脱钩。

更糟的是，有记录显示存在一种"能力惩罚"现象——已知为 AI 辅助的代码，评审者对其比对同等声明为人类编写的代码评估得更加苛刻。你对抗的不只是 bug，还有每个带 Copilot commit 信息的 PR 所面临的信用税。

Myth 8: 企业有了 GenAI 后可以像创业公司一样快速行动

不可能。创业公司的代码库小、新、规整，和这些模型训练所基于的互联网规模开源数据很像。企业有两 decades 的专有代码、模型从未见过的遗留系统、合规要求，以及安全审查关卡。GenAI 不会消解组织惯性——它只是给了你一个更快的办法，来为仍然在卡住那个惯性的员工生成更多工作。

而所有这些误区背后的元误区是：个体优化能带来生产率提升。事实并非如此。工程史上每一次真正的生产力革命——CI/CD、版本控制、更早之前的流水线——都来自系统性的组织重构，而不是个人在孤立状态下更好地使用某个工具。目前，各企业在 AI 许可上投入了数百万，却把整个采用策略"外包"给每个工程师个人去"自己琢磨"。这不是战略，这只是侥幸心理。

到底该怎么做

停止追踪 AI 生成的代码行数。开始追踪 PR 接受率、评审周期时间，以及 AI 辅助代码专项的缺陷逃逸率——41% 的团队在大量推送 AI 生成代码后缺陷率上升，但如果你的仪表盘只衡量产量，你是发现不了这一点的。

别再把自我报告的"我感觉更快了"当作数据。在你根据一种感觉重写路线图之前，先在你的团队内部做一次 METR 风格的对照实验。

别再把采用率等同于信任度。如果 10 个工程师里有 7 个不信任工具的输出，你的推广计划需要一个评审关卡，而不是一道命令。

这项技术确实有用。围绕它构建的那些误区，才是真正会让工程组织做出无法撤回的昂贵决策的元凶。在你搭 PPT 之前，先读读这些数据。

来源：ACM Queue — Eight Myths on Software Engineering and GenAI · Hacker News 讨论 · GetDX 摘要 · METR AI 开发者生产率研究