## 受到质疑的主张
arXiv 上的一篇论文《代码审查的终结：编码智能体取代人类检查》由 Martin Monperrus 撰写，该论文认为大语言模型编码智能体已达到一个能力阈值，使得传统的代码审查不再是软件质量流水线中的必要组成部分。该论点基于两个主张：代码审查的每一个既定目标都可以由智能体以更低的成本和更高的吞吐量来完成；而那种智能体编写代码、人类仍作为强制审查者的幼稚整合方式是一个死胡同，因为它既无法提供有意义的保证，也无法随 AI 辅助的吞吐量而扩展。
该论文将同行代码审查分解为四个既定功能：缺陷检测、风格强制、知识传递和意识感知。由于智能体可以执行每一个功能，结论随之而来：智能体因此具备取代人类审查者的能力。
## 这些功能所忽略的内容
反驳观点并非认为智能体无法检测缺陷或强制风格——事实上，它们通常可以做到。相反，审查中不可约约的人类维度仅存在于跨功能的*整合*中，而这种分解抹去了这种整合。以下几种截然不同的能力超出了可自动化检测所涵盖的范围：
- **作为信号的困惑。** 当经验丰富的审查者阅读 diff 并说“我不理解这里”时，这种困惑本身就是发现。它预示着代码过于复杂、抽象层级错误或意图不明。LLM 将始终在没有产生暴露这些问题的合法困惑的情况下处理代码。 - **质疑必要性。** 审查者经常挑战更改是否真的需要： “这应该分成两个 PR 吗？”或者“这只是解决了症状，而不是问题。”此类判断发生在验证之前，并依赖于对系统方向的共同理解，而孤立的智能体缺乏这种理解。 - **看到缺失的内容。** 人类会注意到 API 契约发生了变化但错误处理没有变化，或者预期的分支缺失了。这种对缺失的识别是一类失败——“缺失盲点”——LLM 在处理时很吃力，因为它们只审查存在的内容。 - **基于作者历史的校准注意力。** 初级工程师对支付模块的首次提交，自然会受到与资深工程师常规重构不同的审查。这种校准取决于关系和对过去表现的记忆，而非仅仅取决于 diff 本身。 - **双向性与协同学习。** 代码审查是一种共同的认知活动：审查者学习作者的方法，作者从审查者的提问中学习，从而产生双方最初都不具备的共同理解。智能体的摘要是传输，而不是改变心理模型的对话。 - **仓库之外的操作上下文。** 审查者知道上周二该服务发生了故障，下游消费者正在弃用一个接口，或者法律禁止记录某个特定字段。这些组织上下文很少出现在测试、文档或版本控制中，但它们塑造了关于“改变什么”的每一个决策。
## 责任作为治理而非形式
该论文将人类责任视为一种合规产物——为了法律目的而标注的人员。但个人责任塑造了审查的进行方式：“利益相关”产生了认真的评估，而非机械式的签字。批准 pull request 的智能体不承担任何后果，也没有奖励仔细判断的激励结构。将伦理担忧转向“需求工程和部署后监控”并不能恢复这种责任；它只是推迟了责任。
## 替代的迷思
代码审查不仅是一个检测过程。它同时是一个协调过程、一个意义构建过程和一个治理过程。替代的迷思遵循一个可识别的模式：将人类的贡献分解为可衡量的功能，展示机器可以复制每一个功能，然后宣布人类是多余的。这种模式在每个领域都失败在同一点上——最重要的人类贡献是跨功能的*整合*。人们能够适应计划外的环境和上下文，并且他们承担着正式门禁无法捕捉的社会责任。这些适应能力在最初的分解中缺位，并且在机器替代孤立功能时也不会重新出现。
因此，该批评同意论文的分解，但拒绝其推论。智能体确实可能以更低的成本和更高的吞吐量来服务于检测、风格、知识传递和意识感知目标；尚未解决的问题是，整合层——它决定了一项更改是否必要、是否符合系统的轨迹、以及团队是否保留对其代码的集体所有权——是否可以在不付出代价的情况下被放弃。