采用高 AI 编码的团队合并的拉取请求多 98%——但在代码审查上花费的时间多 91%。拉取请求大小增加 154%，而审查吞吐量下降。算术很简单：你大幅增加了需要审查的代码量，同时将其生产分散到人机配对中，而不是集中在深刻理解自己所写内容的工程师身上。
一个令人不安的事实使问题更加复杂：AI 生成的代码比人类编写的代码更难审查，而不是更容易。表面上它干净、符合惯用法、注释完善。错误埋得更深。人类编写的函数可能有明显的变量命名不一致，暗示"仔细看这里"；而 AI 输出表面上均匀精良，以一种压制该信号的方式。审查者必须对每个函数深入检查，而不是浅尝即止。
Sonar 的调查直接捕获了由此产生的认知失调：
96% 的开发者不完全信任 AI 生成的代码
48% 在没有验证的情况下提交它
38% 表示审查 AI 代码比审查人类编写的代码花费更长时间
59% 将他们的验证工作评为中等到大量
这不是漠不关心，而是过载。当每个拉取请求都包含 AI 生成的部分，而你的审查队列增长了 98% 时，对每个部分保持深度审查在认知上是不可能的。开发者不是选择跳过验证，而是在压力下做出分诊决策，而 AI 代码在视觉上与值得较少审查的代码没有区别。
每条内联建议呈现一个二元选择：接受或忽略。接受有下游验证成本。忽略有可能做出错误判断的风险。两种选择都没有自然的认知锚点。好的代码审查积累了规范——命名约定、测试覆盖要求、架构模式——让有经验的审查者能够快速形成判断。内联 AI 建议先于这些规范。你在实时评估半成品想法，没有建立什么使建议值得接受的标准。
学术评审 AI 辅助同行评审的研究发现，AI 辅助评审将论文接受率提高了 3.1 个百分点，对于边界提交上升至 4.9 个点。AI 辅助评审在 53.4% 的比较中得分优于人类评审。这不是成功的故事，而是揭示了当评估者在认知负载下运作时，他们会默认接受看起来最自信和连贯的输入——而 AI 输出经过校准看起来两者兼具。
同样的动态在代码审查中上演。一个表述良好的 AI 生成函数通过审查，不是因为它正确，而是因为审查者的决策疲劳默认接受看起来自信的输出。生产事故随之而来。
建议量作为旋钮，而非开关。 部署 AI 辅助最常见的错误是将其视为二元：开或关。关于分散的、增量 AI 辅助与完整分类自动化的研究显示出一致的模式。跨许多任务的小型、分散建议产生最差结果——完整的认知负载加上协调开销，但没有释放高阶思维的能力。完全自动化一个任务类别——完整处理而不中断——产生最佳结果，因为它创造了真正的认知空间。如果你不能完全自动化一个类别，请仔细考虑部分建议是否在增加净价值还是只是增加审查工作。
不确定性呈现，而非不确定性隐藏。 信任-行动差距（96% 不信任，48% 验证）部分存在是因为 AI 输出在视觉上不传达其置信度分布。在拉取请求中，94% 置信度生成的函数和 61% 置信度生成的函数看起来相同。明确的不确定性标记——视觉区分、置信度注释、覆盖率指示器——允许审查者按比例分配注意力。这反直觉地减少了总审查工作：高置信度部分得到较轻审查，低置信度部分得到适当深度。
