代码多了三成，软件没多：七百家公司的实测

写代码这一环变快了，交付这一环没有。中间那段被吃掉的效率，藏在代码评审里。

一、发生了什么

据 Ars Technica 报道，哈佛大学的研究者 Fiona Chen 与 James Stratton 分析了一家工程效能平台 Jellyfish 的聚合数据：约 3 亿条工作事件（提交、拉取请求、任务管理记录），覆盖 700 多家软件公司的 70 多万名员工，时间从 2021 年到 2026 年 3 月。

研究把 AI 工具分成两类：一类是补全式的编程助手，人还在写，工具帮着补；另一类是会自己写、自己提交的编程 agent。用双重差分的方法比较不同时间引入工具的公司，前后发生了什么。

引入编程 agent 之后，公司层面的平均变化是：代码总行数增加约 30%，提交量增加约 20%，拉取请求增加约 23%。而在 Jira 这类工具里跟踪的任务和史诗（epic）的解决率，没有统计上显著的变化。研究也没有发现任务规模或复杂度发生变化，也就是说，团队并不是改去做更小更简单的活。

多出来的代码去哪了？去了下游。报道提到，拉取请求从提交到被接受的平均时间上升约 49%，每个 PR 收到的评论数上升约 35%，需要返工的 PR 明显变多。研究几乎没有找到「公司整体软件产出增加」或「因此裁员」的证据。

另一份来自美国国家经济研究局的工作论文（编号 35275，作者 Mert Demirer、Leon Musolff、Liyuan Yang）用 50 多万名 GitHub 开发者的数据得出相似的走向：每一代工具的提交量都在涨，累计效应约为补全类 30%、交互式 agent 180%、自主 agent 240%；但收益沿生产链递减，自主 agent 的 240% 到项目层面只剩约 80%，到发布层面只剩约 30%。

二、跟你有什么关系

写代码的人：你个人的产出确实变高了，但你的时间被重新分配了——写得更少，读得更多。具体说，是从敲键盘挪到了读 diff、跑测试、写说明。这不是错觉，是结构变化。

技术负责人：如果你的考核还看代码行数或提交数，这套指标现在会奖励「生成更多待审代码」。该换成已解决问题数、发布频率、线上事故率。

买工具的老板：这项研究不是说工具没用，是说工具的价值止步于评审环节。不改造评审流程，采购预算买到的是更多待办。

三、怎么用：三件今天能改的事

1. 把评审当产能来投。 分出专门的评审时段，把大 PR 拆成小 PR，让 AI 先做一遍静态检查和测试，人只看逻辑与边界。经验上，几百行以上的 PR，评审质量就会明显下滑。评审不加速，前面快多少都白搭。

1. 换考核指标。 用「本周解决了几个用户能感知的问题」替代「写了多少行」。这项研究里最关键的一句是：任务解决率没变——那就该盯这个数。

1. 让 agent 少写一点、写准一点。 要求它先给方案再动手，改动控制在单个文件或单个函数，附上验证方式。这条对 agent 尤其有效，它天然倾向一次改完所有相关文件。产出少一点，返工少很多。

四、三个别信的说法

「代码量涨 30%，效率就涨 30%。」 代码是中间品，不是结果。真正的结果是上线了多少功能、修好了多少问题。这项研究恰好测了这一步，没动。

「等模型再强一代就好了。」 瓶颈不在生成质量，在验证成本。模型再强，人还是得读、得信、得负责。工具升级能把一部分检查自动化，但评审是人的活动，人不会因为模型变强而看得更快。NBER 那份论文的数据更直接：收益沿链条递减，越靠近发布衰减越厉害。

「这说明 AI 编程是泡沫。」 反了。提交量、PR 量都实打实在涨，说明工具确实在被使用，而且用得很深。它说明的是组织流程没跟上，不是技术没用。泡沫的特征是没人用，这里恰恰相反——用的人太多，流程接不住。

五、一句话结论

AI 把写代码变成了便宜的事，于是评审成了最贵的那一环。

信息来源

• Ars Technica《AI coding agents generate more code but not more software》，2026-10：https://arstechnica.com/ai/2026/10/ai-coding-agents-generate-more-code-but-not-more-software/

功能与价格以官方公告为准。本文写于 2026 年 10 月 17 日。