代码审查变快了，但资深工程师累倒了

时不时会去读一些已经上线到我们平台的代码。不是为了 review——那艘船早就开走了……只是想看看系统正在往什么方向漂移。

最近我发现了很多问题。不是吹毛求疵的代码风格问题，而是影响应用性能和扩展能力的基础设施和功能问题。

坐下来仔细想了想（也读了一些资料），我不觉得我的团队变马虎了。要说有什么的话，他们的 code review 能力其实是变强了……

真正发生了什么

当 coding agent 引入工作流之后，代码量几乎立刻飙升。现在团队里每个工程师每天都在和一个或多个 agent 协作，平台里大部分代码都是这样生成的。

和很多团队一样，首先被打破的是吞吐量。每个人还是有自己的活要干，除此之外他们突然多了一大堆 pull request 要处理。速度明显变慢了。关于这个很多人都在写，我们也一样经历了。

然后我们做了调整。我的团队现在处理 code review 的速度比以前快多了——在这件事开始之前就快。

所以队列问题得到了改善。但从另一头出来的代码，确实存在真正的问题。

团队里没有人不再用心

我要小心地把锅甩对地方，因为我觉得 Review 的人不应该是被责怪的那一方。

MSR '26 有一篇论文（Huang, Jaisri, Shimizu, Chen, Nakashima and Rodríguez-Pérez, "More Code, Less Reuse"）研究了 3858 个 Python pull request，对比了 agent 生成的和人写的。Agent 的 pull request 大约承载了 1.87 倍的语义冗余……代码重复了代码库里已经存在的逻辑。

好吧，这个我能猜到……但第二个发现让我惊讶。

Reviewer 对 agent pull request 的反应比对人写的更温和。Agent PR 上有更多中性反应和正面反应。而人写的那些则招来更多的厌恶、愤怒、恐惧和惊讶。作者的解读是 agent 输出是基于概率生成的，所以表面看起来很合理，reviewer 也就相应地放松了警惕。

把这个发现和我团队发生的情况放在一起看，就有意思了。我们 review 变快了，是因为我们 review 的代码非常擅长「看起来没问题」。这和「review 能力变强了」是两回事……但从内部感受来看，两者毫无区别。

真正的代价

目前大多数讨论都集中在开发者被淹没、筋疲力尽上。我确实也看到了同样的趋势。压力很大，人们很累。

但 burnout 不会出现在业务审查的数字里……

高级工程师把大量时间花在要么 review 所有动过的代码，要么去修那些漏网之鱼——那些本来需要高级工程师过目但没能得到关注的改动。这些时间他们没有花在架构上，没有花在高复杂度的、真正创造价值的、只有他们能做的工作上。你最贵的人在 review 队列和 bug 工单里埋头。

就拿我自己来说，因为我可以说实话。我是团队里最资深的人。我也是 manager，是系统的架构师，最近还在做一个稳定输出问题的 IC，这些问题最终流到了生产环境。我需要在 review 上花更多时间……但根本没有更多时间可以花了。

说实话，我正在溺水。除非我找到一个办法更清楚、更准确地判断我的注意力实际上需要放在哪里，否则我不认为这会自己变好。

坏掉的是模型，不是团队

在这整个过程里，我们继承的那套 review 模型悄悄地失效了。

那个模型把 pull request 视为大致可互换的。它们进入同一个队列，都被看到，都从某个人那里得到一个 approval。很长一段时间里它运行得还不错，因为每个人写的每一行代码都得有人坐下来先写。写作本身是一个非官方的限流阀。现在不是了。

所以同样的注意力现在要覆盖好几倍的量，而且它在每个地方同时变薄了。安全的改动得到了仔细的阅读。危险的改动也得到了同样的阅读。我是几周之后滚动已合并的代码、看到刺眼的问题瞪着我的时候才发现哪个是哪个的。

问题出在模型本身。它假设每种改动都值得大约同等的审视，但它运行的这个世界里代码量翻了三倍，而风险从未均匀分布在这些改动上。

这就是我在做 Merge Lantern 想要解决的问题，所以说我有点私心也无妨。它把 review 交给你。现在有几十个 AI review 工具声称能帮你完成 review 流程。Merge Lantern 不是做这个的。取而代之的是，它按照你打开的 pull request 承载的风险大小进行排序，这样你真正拥有的高级工程师注意力就能落在最需要它的改动上。

我确定的是问题的形态。注意力现在是稀缺资源。把它均匀地铺在所有事情上一直有点浪费，过去代码量低的时候还能运转。显然现在不行了。

所以这是我这周在思考的问题……

你如何决定哪些 pull request 值得仔细阅读？是成文的规则，是直觉判断，还是看谁当天下午有空？如果你找到了一个办法让这个决策变得有意识的，我很想知道你是怎么做的。

Huang, Haoming, et al. "More Code, Less Reuse: Investigating Code Quality and Reviewer Sentiment towards AI-Generated Pull Requests." arXiv:2601.21276, arXiv, 29 Jan. 2026. _arXiv.org, https://doi.org/10.48550/arXiv.2601.21276._

我正在做 Merge Lantern，针对小型工程团队的风险情报。它标记哪些打开的 pull request 最需要在合并前得到高级工程师的关注，每天一条简短摘要。产品还很早期，前 5 位设计合作伙伴头 3 个月免费。如果你的团队也感受到这个问题，欢迎加入等待列表 mergelantern.com。