之前有个工单刚分配下去11分钟，就提交了一个1140行代码的合并请求。描述里只有四个简单的要点。

我盯着这个请求看了整整四十分钟，最后批准并合并了它，但我其实并没有完全看懂里面的逻辑。

从那一周起，我开始记录团队的数据。数据表明，我们的团队卡在了一个“AI 代码审查瓶颈”上。就像路中间停了一辆大卡车：我们产出的代码比以往任何时候都多，但发布速度却比以往任何时候都慢。

核心结论

• AI 代码审查瓶颈：AI 写代码的速度远远超过人类审批的速度。写代码的效率提升了，但这部分提升并没有转化为产品上线的速度，而是全都堆积在了代码审查的队伍里。
• 真实数据：在我一个6人团队的一个季度里，每周提交的代码合并请求从约31个涨到了约68个。但平均合并时间从4小时飙升到了14小时，最慢的从1.5天涨到了5天。
• AI 代码更难审：AI 写的代码看起来全都“理所当然”，没有人类写代码时那种犹豫或不确定的痕迹，审查者很难抓到重点。
• 破局方法：真正的解法不是技术上的，而是沟通上的。限制代码量、要求作者说明“我到底验证了什么”、以及拒绝审查作者自己一句话都解释不清的代码。
• AI 审查机器人没用：加一个 AI 机器人来审查代码，只会让你多读一段看起来很对的废话。

什么是 AI 代码审查瓶颈？

就是“写代码”和“接受代码”之间的速度差。这一年里，让 AI 生成代码的成本便宜了大概5倍，但人类的注意力成本一点没降。所以，瓶颈从键盘上转移到了审查者的眼睛上。上游每一个“生产力提升”，都只是在让审查队伍排得更长。

你花十分钟看看你们自己的代码仓库：把每周提交的请求数量和平均合并时间画在同一张图上。如果两条线都在往上涨，那你们的问题不是速度慢，而是队伍排得太长了。

为什么代码写得多了，上线反而慢了？

因为人类审查代码的时间是固定的，而且队伍排队的增长不是直线的。这是很基础的排队论数学，每个开发团队都得吃一次苦头才懂。

我们团队有三个问题叠加在了一起：

提交量翻倍。 还是那6个人，但合并请求多了一倍。当队伍接近满负荷时，等待时间不是缓慢上升，而是垂直飙升。审查者从“60%的时间在忙”变成“90%的时间在忙”，带来的可不是30%的变慢，而是好几倍的阻塞。

代码块变大。 平均代码改动量从90行涨到了310行。而且审查代码的难度是超线性增长的。看一个300行的代码，可不是看三个100行代码那么简单，因为你必须同时在脑子里记住三倍的上下文，才能发现潜在的交互Bug。

审查者开始“囤积”任务。 如果只有两个请求在排队，你会立刻去看。但如果有9个，你就会想等一段完整空闲的时间再看。但这段完整的时间永远不会来，于是代码就被扔在那过夜了。代码过夜，就是信任破产的开始。

最恶心的是这会形成恶性循环：审查慢，导致开发者把更多功能塞进一个请求里（反正打开小请求也要等一天）；请求变大，审查更慢；循环往复。

为什么 AI 写的代码比人写的更难审查？

这是我低估的地方。不仅仅是数量多，AI 生成的代码，每一行读起来都更费劲，有四个原因：

1. 看起来全都很合理。 人类写的代码有破绽。一个命名奇怪的变量，一段被注释掉的代码，或者一个长得离谱的函数。这些都是作者不确定的地方，有经验的审查者会顺着这些气味去抓问题。但 AI 输出的代码在每个地方都显得一样自信。第12行和第812行看起来都经过了深思熟虑，你的注意力无处安放，最后只能走马观花。

2. 没有意图可供质问。 最好的审查问题是：“你为什么这么写？” 问人类，你要么得到一个你不知道的好理由，要么看到对方心虚的表情。但问一个由 AI 生成代码的作者，你要么得到一个耸肩，要么得到 AI 那个听起来最顺耳的回答。审查者成了整个流程中唯一的判断者。

3. 废话太多。 AI 会写出“能跑通”的版本，而不是“最小可跑通”的版本。多余的抽象层、只用了一次但单独拎出来的辅助函数、为不可能发生的情况写的防御性代码。这些全都不算错，但全都是你以后要永远阅读和维护的负担。

4. 测试和代码同流合污。 如果 AI 对需求的理解是错的，它生成的测试通常也包含了同样的错误理解。绿色的测试通过标志不再是代码正确的证据，它只告诉你代码内部是自洽的。

到底怎么解决这个瓶颈？

没有什么高深的技术。就是五条规则，其中四条是关于人类行为的：

硬性规定代码改动不超过400行。 如果超过，自动阻断合并，直到有个人写一句话解释为什么没法拆分。大概每15个请求会有1个获得特批。其他14个都被拆开了。拆分其实很简单，因为能写代码的 AI 也能帮你拆代码。

在模板里加一个“我实际验证了什么”的板块。 只写三行，且明文规定不准写“测试通过了”。必须是作者亲自做的事情，比如：用一个错误的参数请求了接口、在测试数据的副本上检查了数据库迁移、确认了旧的缓存键还能用。这一个改动比其他所有方法加起来都管用。它是“AI 写完了”和“我要占用你时间”之间的减速带。

“一句话解释”规则。 审查者可以指着任何一段代码问它是干嘛的。如果作者一句话答不上来，请求打回。这不是惩罚，只是如果对话里没一个人懂这段代码，那审查就是走过场。两周后，那种随手用 AI 生成一堆代码就交差的现象就消失了。

对着需求审，而不是对着风格审。 我们最高效的审查问题变成了：“这个改动里有什么是我们没要求的？” AI 特别喜欢自作主张地重构代码。如果你不专门盯着找，AI 代码里的需求蔓延是看不见的。

按“谁做的决定”来拆分提交记录。 第一个提交：AI 生成的机械性代码（占80%）。第二个提交：人类在上面做的判断和修改。审查者先读第二个提交。90%的风险都在这里，而且通常只有三十行。

最终，平均合并时间回到了大约6小时。不是以前的4小时。这多出来的2小时，就是保持诚实所需的成本。

什么方法没用？

加一个 AI 审查机器人。 我真的很希望这招有用。但结果是我们有了更多废话要读，还多了一个隐秘的失败陷阱：一个解决了8条机器人评论的请求，会让人“感觉”已经被审查过了。我们的机器人会热情地指出命名问题和缺失的文档，却完全忽略了一个循环里的数据库查询问题，而人类只要9秒就能发现。它当个代码检查工具还凑合，但它不是审查者，因为它根本不关心系统下个季度还能不能跑。

增加审查人员。 审查同一个请求，多加人手是没法并行的。两个人看一个改动，结果就是一个仔细看，一个走马观花，而且两人都不知道自己是哪种状态。

“相信测试就行了”。 前面说过了，测试是那个误解了需求的 AI 写的。

总结：为什么 AI 让代码审查成了瓶颈？

因为 AI 拆掉了原本遮住这个问题的限制。以前写一个功能要两天，审查时间在排期里就是个零头，没人去量它。现在写代码只要二十分钟，审查成了流程里唯一还在人类速度运转的环节，所以原本分散在整个周期里的延迟，全都集中到了审查这一步。

真正从 AI 身上拿到效率提升的团队，不是那些生成代码最多的团队，而是那些意识到“接受代码”而不是“写代码”才是现在稀缺资源的团队。他们重新设计流程，让代码变得易于“阅读”，而不是易于编写。小请求、明确的验证、以及一条铁律：没人能解释清楚的代码，绝不合并。