橡皮图章式崩溃：为什么 AI 编写的 PR 正在掏空代码审查

一位资深工程师在四分钟内批准了一个 400 行的 PR。diff 很整洁。命名很合理。测试通过。两周后，值班工程师翻阅一个查询时发现，它返回的行形状是对的，但取错了列 —— 本该用 user.created_at 的地方用了 user.updated_at —— 队列分析仪表板已经对 CFO 撒了九天的谎。审查者很称职。代码结构良好。这个 bug 在 diff 中是不可见的，因为它不是语法异味，而是语义问题。审查者无从着力，因为没有人写下这个变更原本打算做什么。

一旦你代码库中的大部分 diff 都源自模型输出，这种失效模式就会出现。审查者不再问“这正确吗？”，而是开始问“这看起来像代码吗？”。答案几乎总是肯定的。AI 编写的代码在语法上极其流畅，这种流畅性绕过了工程师们花费十年时间在人类编写的烂代码上磨练出来的审查启发式规则。

数据并非微不足道。一项针对企业级仓库中 Pull Request 的大规模研究发现，AI 辅助的 PR 总体上产生的 issue 多出约 1.7 倍，其中严重级别 issue 增加了约 40%，逻辑与正确性发现增加了 75%。在 90 分位处，AI 编写的 PR 每次变更包含 26 个 issue —— 是人类基准的两倍多。另一份覆盖 2.2 万名开发者的 2026 年遥测数据集报告称，每个 PR 的事故数上升了 242.7%，而个人产出指标也在攀升。吞吐量上去了，逃逸缺陷上升得更快。

为什么会出现橡皮图章

“橡皮图章”（随手批准）并不是因为懒惰。它是对信噪比变化的一种理性反应。当大多数 PR 还是人类编写时，审查者的大脑会运行一个后台分类器：草率的命名、不一致的缩进、一个函数做两件事、一个带有否定含义的布尔变量名 —— 这些都与深层问题相关联。语法异味是语义风险的廉价替代指标，而且它很管用，因为在形式上偷工减料的人通常在逻辑上也会偷工减料。

AI 的输出打破了这种关联。模型生成的代码看起来像是出自一位细心的工程师之手：符合项目风格的 docstrings、与项目基调一致的错误信息、从合适的词典中选取的变量名。形式与其产生的推理过程是脱节的。一个习惯于扫描语法异味的审查者，现在是在扫描一个已经不复存在的信号。

更糟糕的是，失效模式往往是人眼难以捕捉的。幻觉出的 API 虽然能编译，但对应的却是你所使用的库版本中并不存在的方法。一个查询关联了正确的表，却投射了错误的列。一个 except 子句吞掉了一个特定的错误，而调用者正依赖该错误进行重试。一个运行 N+1 查询的循环，因为模型默认选择了逐行查找，而不是代码库中已有的批量查找。这些在 diff 层面都不显现为问题。它们表现为普通的、看似合理的代码 —— 这正是 AI 优化的目标产物。

再加上规模的变化。AI 编写的 PR 平均体积更大；一项研究指出，PR 大线的中位数上升了 51.3%，中位审查时间增加了 441%。一旦超过 400 行，审查者就不再是审查，而是在抽样。diff 越大，橡皮图章就盖得越果断，因为在某些时刻，审查者的选择要么是敷衍的批准，要么是诚实地说“我无法在合理时间内审查完这个” —— 第一种选择没有政治成本，而第二种则会被视为阻挠主义。

没人绘制的信号退化曲线

橡皮图章式崩溃在组织上的表现是：在 AI 编写的变更中，有一对指标正朝着相反的方向运动。单个 PR 的审查时间下降（审查者没有深入参与，因为无从下手）。同样是这些 PR，Bug 逃逸率却在上升。这两个变动单独看都不足为奇，但结合在一起就是其特征签名。

大多数团队不会按作者模式切分他们的审查指标，因此这种趋势是不可见的。领导层看到总体吞吐量提高、总体周期时间缩短，便得出 AI 推广卓有成效的结论。事故曲线会在三到六个月后追上来，由于事故具有噪声且由多因造成，因此很容易忽略其与审查流程之间的联系。六个月的时间也足以让那些原本能察觉到偏差的工程师习惯这种新常态。

以下是一些先行指标，表明你的审查质量已经跨过了红线，而还没人公开指出来：

• 审查者越来越多地批准那些涉及他们从未接触过的代码库部分的 PR，且不提任何问题。
• 评论偏向于细枝末节（命名、导入顺序、单行重构），而不是“这到底是在做什么？”。
• 回滚原因从“误解了需求”（审查可发现的类别）转变为“生产数据中的边界情况”（通常并非如此，但现在成了一个方便的托辞）。
• 在站会中出现“AI 写了大部分，我只是清理了一下”这类话，且从未受到质疑。
• 事故后审查（Post-incident reviews）不再揭示审查漏洞，因为没人愿意对同事写下“审查者没有仔细阅读”，而怪罪“AI 幻觉了一个方法”则容易得多。

这些迹象单独看都不是问题。但这种模式本身就是问题。

加载中…