“AI 让我这么做的”辩护：当代码审查悄然停止提出异议

在 2026 年的代码审查（Code Review）讨论串中，最昂贵的一句话莫过于“这是 Agent 这么写的”。这并非因为它本身是错的——有时它确实没错——而是因为它终止了本该由此开启的对话。审查者输入一个问题，作者直接引用模型的推理作为回复，讨论在任何人真正开始争论这项变更之前就结束了。反对一个自信且谈吐得体的模型的社交成本，已经悄然高过了合并一个隐蔽 Bug 的成本，而大多数团队在未来两个季度内都无法在指标中察觉到这种权衡。

这不是一个关于 AI 写代码好坏的故事。它会写代码，其中有些还写得不错。这是一个关于当编写代码的摩擦消失时，质量关卡（Quality Gate）会发生什么的故事。审查速度上升，缺陷率也随之同步上升，而这种关联并不明显，因为没有人在追踪审查耗时与缺陷时会关联作者的类别。曾经是代码库品味核心的资深工程师，在一个悄然转向“模型盲从”的文化中，变成了孤独的坚持者。

缺陷率已经变了——而审查标准还没跟上

在对 470 个 PR 样本的调查中，CodeRabbit 发现 AI 协同生成的变更平均每个 PR 会产生 10.83 个问题，而纯人工编写的 PR 仅为 6.45 个——大约高出 1.7 倍。在最关键的环节，情况更糟：逻辑和正确性问题在 AI 生成的 diff 中多出 75%，安全漏洞高出 2.74 倍，错误处理缺失近 2 倍，可读性问题更是高出 3 倍。GitClear 对 2025 年 1.53 亿行变更代码的分析发现，代码重复率上升了 4 倍，且短期代码流转（churn）也在上升，因为 AI 工具放大了那些 Linter 无法捕捉的复制粘贴模式。

这些数字描述的是进入你审查队列的输入，而非合并按钮产生的输出。审查过程本应是消除输入波动、确保输出质量稳定的层级。过去，它依赖于审查者已经校准过的少量产出物：人类 PR 的典型规模、人类作者的典型置信水平，以及人类犯粗心错误时的典型表现。现在，这些先验经验在 Agent 编写的代码面前全都失效了，但大多数团队的审查清单仍停留在旧的分布模式上。

结果是不对称的。缺陷率首先发生变化，因为编写工具首先变了。而审查标准的提高只能源于审慎的组织决策。在没有这种决策的情况下，合并按钮产生的代码质量已经与以往大不相同。

为什么审查者选择了妥协——作为职场动态的自动化偏见

人因工程学文献对正在发生的事情有一个清晰的定义：自动化偏见（Automation Bias）。今年早些时候，Springer 的《AI & Society》期刊上的一篇系统性综述直接指出了这一点——在使用自动化建议的群体中，遵循错误自动化建议的比例高出 26%，且任务经验不足与对建议的盲从程度呈强相关。你对该领域越陌生，就越信任机器。

但实验室效应低估了职场的动态。在代码审查中，两件事现在同时发生：首先，模型生成的文本读起来比审查者的直觉质疑更自信、更有条理、更善于表达；其次，PR 的作者拥有了前几代作者不具备的借口——“这是 Agent 建议的”——这把升级争议的社交负担转移到了审查者身上。审查者不再是在反对作者，而是在反对模型，而作者成了模型的辩护律师。

认知强迫功能（Cognitive forcing functions）——研究支持的用于减少对错误 AI 建议过度依赖的对策——其效果远好于简单的信任校准反馈。这对团队来说意味着一个令人不安的事实：告诉审查者“对 AI 的建议保持警惕”是没用的。有用的是强迫他们执行某种动作——比如撰写反向解释、运行测试用例、指明该变更会影响的 Eval（评估指标）——之后才能启用“批准”按钮。而默认的 UI 恰恰相反。它把批准按钮放在原来的角落，寄希望于审查者的自律来补偿输入环境的变化。

资深工程师先成了瓶颈，随后变成了“异类”

各团队中上演的模式高度一致。在 Agent 被广泛采用的几周内，审查队列会翻倍甚至三倍，因为工程师提交 PR 的速度超过了阅读速度。那些知道哪些模式至关重要的资深工程师成了瓶颈——团队的开发速度被他们的阅读速度锁死了，这是一个硬上限。

接下来会发生两件事，它们都是本文论点的关键支撑。

首先，组织为了应对瓶颈，提高了资深工程师审查的成本，降低了批准的成本。CODEOWNERS 文件被放宽，“看起来没问题（LGTM）”成了一种完整的审查方式，任何人的批准都被视为可以替代那个原本能抓住 Bug 的人的批准。一家金融科技公司公开报告称，其两个主要代码库中 93% 的 PR 是由 Agent 驱动的，超过 19% 的 PR 是在没有人工审查的情况下自动批准的。他们的变更导致的停机时间下降了 35%，即便部署量翻倍了——这听起来像场胜利，直到你问一个没有他们那种预合并护栏的团队会发生什么，并注意到几乎没有其他公司发布过类似形状的数据。

其次，那些不断阻拦 diff 合并的资深工程师成了社交难题。他们太慢了。他们提出的问题，Agent 的作者无法轻易回答。他们反对模型以高度自信写出的文本。在一个隐含地围绕着“模型盲从”重新校准的文化中，他们被视为团队正试图消除的“摩擦”。团队中最昂贵的工程师——那些判断力构成了公司真正护城河的人——现在成了组织结构上被迫绕过的对象。

这是仪表盘上无法显示的文化失效模式。它不是一个流程 Bug，而是一场关于“谁的意见被允许拖慢合并进程”的悄然重新谈判，而组织达成的共识是：“更少的人，且地位更低。”

必须落地的规范

解决方法并不是“更严格地审查”，因为会说出“更严格地审查”的团队，其审查者往往已经感受到了意见分歧带来的社交成本，并且不愿再承担更多。解决方法是结构性的：改变审查工具和审查文化视为“一等公民”的对象。

追踪作者类别。 每个 PR 都需要一个结构化字段——人工编写、智能体辅助、智能体编写——该字段存在于合并提交（merge commit）中，并可在你的缺陷数据中进行查询。如果没有这个字段，你无法判断事故率的变化是因为智能体生成的差异（diffs），还是因为无关的回归。有了它，你可以按作者类别对审查策略进行分层，并根据每一层实际产生的缺陷数据来定价。这是最简单的结构性杠杆，也是团队抵制最激烈的，因为它让生产力的论点变得可审计。

使“这是智能体建议的”成为无效理由。 这应该是工程手册中写明的规范，而不仅仅是一种氛围。在审查环节中的辩护理由不应该是模型的推理，而应该是作者的推理。如果作者在不引用模型的情况下无法重建论证，审查者应将该 diff 视为未经审查。这是人类因素文献中推荐的“认知强迫功能”在团队层面的体现。

按影响面（Surface）路由，而非按开发速度。 CODEOWNERS 文件是团队风险分类体系在 diff 级别编码的唯一地方。利用好它。鉴权、支付、迁移、面向客户的逻辑，任何涉及资金或个人可识别信息（PII）的内容——无论作者是谁或是什么，都应自动升级给指定的、具备人类判断力的审查者。开发速度指标应分别报告低风险和高风险影响面，以免后者被前者掩盖。

根据作者未运行过的评估，对已合并的智能体 diff 进行审计。 抽取上一季度智能体编写的合并记录样本，让一位之前没看过该 PR 的资深审查者重新审查。将“当时通过的内容”与“现在会被拦截的内容”之间的差异视为一个校准指标。这是唯一能在事故率上升之前，捕获审查标准缓慢漂移的机制。

在 PR 模板中构建一个“反向解释”步骤。 在批准按钮启用之前，审查者必须写下一句话，说明代码库需要发生什么变化，才会导致这个 diff 是错误的。这听起来很繁琐。这种繁琐是刻意设计的。这也是唯一能可靠地发现“审查者的直觉反对是正确的，但被模型清晰的文辞所掩盖”的情况。

重新定义：智能体编写的代码是一种输入类别，而非一类作者

过去二十年里，代码审查的隐性校准是基于人类编写代码的成本。资深工程师编写一个精细的函数需要一两个小时，初级工程师编写一个粗糙的函数也需要同样的时间。两者都受到打字速度、思考以及盯着空白屏幕的摩擦力的限制。审查过程建立在这样一个假设之上：上游的约束完成了大部分质量过滤工作。

这个假设已经不复存在。创作的摩擦力已经瓦解。审查过程现在承担了一个过去部分由编写成本支撑的质量门控职责，而大多数团队尚未更新这个门控。智能体不是一个需要指导的初级工程师；它是一个源源不断产生“看起来像那么回事”的 diff 的消防栓，其分布模式与你的审查者过去所校准的模式并不匹配。

这就是为什么“它是智能体写的”不能作为辩护理由。diff 的作者类别是关于输入分布的信息，而非道德范畴。它告诉审查者这个门控需要做多少工作——对于具有同等复杂度的 diff，智能体编写的比人工编写的需要更多、而非更少的工作。内化了这一点的团队，不再将智能体生成的 PR 视为一种顺带需要审查的生产力提升，而是将其视为一种质量挑战，其审查成本是单位经济效益的一部分。

推论是，你最资深审查者的时间现在价值更高，而非更低。在新体制下，他们的判断力成本就是如果没有它你将交付的回归成本，而回归率正在上升。如果组织结构的反应是通过自动批准、轻量级审查或单纯消耗资深成员的耐心来绕过他们，那么这个组织正在选择一个它尚未察觉的未来事故图谱。

18 个月后不进行重新校准的团队会是什么样子

合并吞吐量爬升。工程师报告的生产力爬升。DORA 仪表盘看起来很健康。然后，事故曲线开始弯曲。前几次被归结为运气不好。第九个月左右的事故集群迫使团队进行事后文化审计，审计结果显示出一个令人不安的相关性：事故集中在那些合并 diff 为智能体编写、且审查者在五分钟内就点赞通过的影响面。

本可以发现问题的资深工程师已经离开了团队——有时甚至离开了公司——因为坚持原则的社交成本高于招聘人员提供的报价。合并按钮继续工作。产品继续交付。悄然断裂的是那个门控。

能平稳渡过这个时期的团队是那些先做了那些不起眼工作的人：记录了作者类别，写下了“智能体建议”无效的规范，诚实地维护 CODEOWNERS 文件以识别风险面，并将资深审查者的地位视为组织资产而非速度税。他们最终建立的审查流程比 2026 年行业其他公司吹捧的流程更重。随之而来的事故图谱则是证明这一选择正确的证据。

在审查环节中的辩护理由是作者的论点，而非模型的。能捕获错误的门槛是那些没有悄然降低标准的门槛。那位曾经作为代码库定海神针的工程师，是你希望当智能体的输出分布再次发生变化时（它一定会变的），仍在阅读 diff 的那个人。