AI 编程 Agent 让代码量涨了 30%，交付却原地踏步：一项 700 家公司的研究复盘
赵达最近 AI 编程助手已经是标配了：Copilot、Claude Code、Cursor、Codex，团队里不用都不好意思说自己是 2026 年的程序员。但有个扎心的问题一直没人好好回答：代码是写得更快了，软件交付真的变快了吗？
上周（10 月 12 日前后）在 AI 资讯圈流传开的一项哈佛相关研究，给出了一个反直觉的答案，值得每个写代码、带团队的人认真看看。
研究发现了什么
这项被称为 “review-bottleneck study” 的研究，观察了 700 多家引入 AI 编程 Agent 的公司的工程数据。核心数字很直白：
- AI 让代码产出增加了约 30%
- commit 数量增加了约 20%，PR 数量增加了约 23%
- 但在 Jira 这类项目管理工具里，被标记为完成的 issue 和 epic 数量，没有统计意义上的增长
翻译一下：更多的代码进了流水线，更多的 commit 被提交，更多的 PR 被打开，但真正”做完”的需求，原地踏步。
瓶颈不在写代码，在看代码
研究者把原因指向了一个每个工程师都感同身受的环节：代码评审。
AI Agent 几秒钟就能生成函数、测试甚至整个模块，但每一行代码仍然需要人（或者另一个 AI）去检查：逻辑对不对、有没有安全问题、跟现有代码是否融洽。当评审请求量的增长速度超过评审能力的增长速度，工作就在队列里排队——排队吃掉的，正是生成速度带来的全部收益。
这其实是个经典的系统思维问题：流水线的吞吐量取决于最窄的那个环节，而不是最宽的。我们过去几年一直在拓宽”写代码”这个环节（从 IDE 补全到 Copilot 再到 Agent），却很少有人去拓宽”评审”这个环节。
给工程师团队的四个启示
1. 度量”交付”，而不是”产出”
如果你的效能看板还在看代码行数、commit 数，那 AI 时代这些指标会好看得让你误判。真正该看的是：需求从提出到上线的时间（lead time）、每周关闭的 issue 数、线上事故数。产出涨 30% 而交付不动，就是这项研究描述的症状。
2. 把评审能力当一等公民建设
- PR 粒度变小：让 Agent 一次只做一件事，生成小而完整的 diff。review 一个 50 行的 PR 和 500 行的 PR，成本差的不只是 10 倍。
- AI 先审一遍：用另一个模型做第一轮 reviewer，检查风格、明显 bug 和安全问题，人只看 AI 标出来的可疑点和业务逻辑。
- 评审规则代码化：把团队约定写成 lint 规则和自动化检查，能进 CI 的就别用人眼。
3. 给 Agent 立规矩
Agent 是不知疲倦的实习生，但也是个需要管的实习生：
- 一次只派一个任务，任务描述写清楚验收标准
- 要求它先写测试，或者至少解释”为什么这么改”
- 别让它一次性重构大片代码——大 diff 是评审的噩梦
4. 人在回路的位置要前移
别等 PR 堆了 20 个才开始看。让 Agent 在关键决策点停下来确认（比如”这个方案有两种实现，选 A 还是 B”），比事后返工便宜得多。这也是为什么各家 Agent 工具都在加强 approval 和人机协作流程——每一步确认不是累赘，是血泪换来的设计。
结语：工具在进化，流程也要跟上
有意思的是，就在同一周，开源社区也没闲着：Earendil 发布了 MIT 协议的 Pi 1.0 Coding Agent，号称能把 prompt token 砍掉约 40%；Ruflo 这样的”meta-harness”甚至能把一个 coding assistant 编排成上百个 Agent 的 swarm。工具侧的军备竞赛还在加速。
但这项研究的提醒是：如果评审和交付流程不跟着变，再强的生成能力也只是在给队列添砖加瓦。AI 时代的研发效能问题，已经从”怎么写得更快”变成了”怎么审得更快、交付得更稳”。
你的团队引入 AI 编程助手后，是交付变快了，还是 PR 列表变长了？欢迎聊聊。
参考：AI Coding Agents Add 30% More Code, Not Software（Tech Insider，2026-10）