AI 并未将瓶颈从编码转移到代码审查
为什么我们忽略了真正的改进机会
自从 AI 出现以来，很多人都在说瓶颈已经从编码转移到了代码审查。这个说法并不准确——因为编码本来就不是瓶颈，现在代码审查也不是。我们之所以认为某个环节在制约价值流动，是因为我们总盯着远处的山，而忽略了脚下长满苔藓的小山丘。
做个简单的测试吧。针对你正在开发的应用或服务，有多少变更已经通过了代码审查，但还没有被部署上线、让用户用上？如果答案是 0 或 1，那我道歉：在你们这个具体场景下，我是错的。但我几乎没得到过这个答案。通常答案都是大于 1 个，这说明瓶颈根本不在那里。
我们正在这个领域进行原创研究，发现一半的团队每次部署会积压 2 到 10 个变更，四分之一的团队会积压 11 到 50 个。总体来看，超过 90% 的团队采用批量部署，而不是一次只发布一个变更。
“编码本来就不是瓶颈，现在代码审查也不是。”
这个数字暴露了整个行业的可见性缺口。大家相信 Claude Code、Cursor 和 GitHub Copilot 已经把瓶颈从编码转移到了代码审查，但这忽略了审查之后发生的所有事情。这并非个人失误，而是行业性的认知偏差。
我们已经太习惯批量工作了，以至于这种做法看起来像是天经地义的。它就像长满了苔藓，和周围的山丘混在一起，几乎分辨不出来。当你搜索如何加速软件交付时，你不会注意到它——因为它根本不像一个问题，它看起来就是一直以来的样子。
当AI涌入批量变更，会发生什么
写代码只是更长价值流中的一小部分。这条价值流从抓住机会开始，到用户获得所需价值结束。整个价值流上的影响并不均匀——AI在某些环节的帮助更大，而端到端的收益取决于你是否能察觉工作在哪里积压。
GitLab《2026年AI问责报告》发现，85%的受访者认为AI已将瓶颈从写代码转移到代码审查。但从部署批次来看，这92%的人很可能错了——如果代码审查之后还有积压，说明代码审查根本不是瓶颈。这也意味着加快审查速度反而会让真正的瓶颈变得更糟。
这并不是说编码速度提升不会给代码审查带来压力。Faros AI针对10,000名开发者的研究发现，AI使用率高的团队合并的PR（拉取请求）数量增加了98%，但这些变更的审查时间却增加了91%，平均PR大小也增加了154%。Cursor与芝加哥大学经济学家合作的研究也发现，一旦其编程助手成为默认工具，公司合并的PR数量增加了39%。
然而，加快审批变更只有在变更能顺利流入生产环境时才有效。在大多数情况下，变更是进入了一个等待进一步处理（如测试和部署）的队列。如果你提高通过审查阶段的变更速率和体量，压力只会被转移到真正的瓶颈上。
“如果你提高通过审查阶段的变更速率和体量，压力只会被转移到真正的瓶颈上。”
代码审查看起来像是一道瓶颈，只是因为它有可见的队列，而下游的队列由于被行业普遍接受而被隐藏了。流水线的职责是把变更送到生产环境——在那里它们能被使用，而不是把它们堆积在“等待部署”的队列里。
而随着所有这些未发布的变更不断累积，风险也在同步增长。
批次就是路标
问一问批次规模的问题，你就会发现真正制约价值流的是什么：可能是某个手动验证环节、繁琐的变更审批流程、发布列车流程，或是没有便捷的部署方式。而不是编码，也不是代码审查。
很可能在引入 AI 之前，你已经在用批次方式工作了。AI 的引入会进一步加大批次规模，从而引发问题。提高代码审查的通量并不能解决问题，只会让变更更快地堆积到瓶颈前。
用真实的约束条件来设定整个价值流的节奏，能帮你把投入花在解决正确的问题上。如果你的复盘回顾总也看不到明显改进，那很可能就是没抓住批次问题。这也是为什么有些 AI 项目能成功，有些却失败的原因。
研究报告也忽略了这一点
关于 AI 影响的研究很有用，但和其他许多同类研究一样，它们只分析到代码合并这一步。它们看的是打开的 Pull Request、合并的 Pull Request、以及审查花费的时间。但没人问：变更在审查之后等了多久才上线？或者有多少变更被捆绑在一起，直到用户看到它们之前从未分离？没有这个数字，你就找不到真正的约束条件。
既然已经投入了 AI 来加速编码，你接下来很自然就会想优化代码审查，或者干脆放弃代码审查。但如果你仍然按批次发布，这两种做法都无法显著缩短风险消除的时间，也无法加快把价值交付给用户的速度。
你的组织之所以抗拒解决批次问题，这本身才是真正需要解决的问题。