把代码评审当成缺陷检测工具，是它近年在工程讨论里最常见的窄化。有论文在 2026 年主张编码智能体已经能取代人工检查，做法是把评审拆成四个可测量的功能，缺陷检测、风格执行、知识传递、意识，然后逐项证明机器做得更好。这类论证依赖一个前提，人类的工作能分解成功能单元，每个单元被机器复制之后，人就没有剩余价值。代码评审恰好不是这种结构。它同时是协调、意义建构和治理过程，评审者在这些环节做的事，恰恰发生在我们准备放弃的那个位置上。
代码检查本来就不只是找 bug
把评审变成流程的人是 Michael Fagan。1976 年他在 IBM Systems Journal 上发表了 Design and Code Inspections to Reduce Errors in Program Development，正式把代码检查写成一套有角色、有步骤、有数据记录的正式流程。这个方法的设计目标从一开始就是把缺陷挡在测试之前，但流程里保留了会议，保留了多人对同一份代码的共同阅读。
后来被自动化的那部分，确实是最容易的那部分。风格规范、已知模式、静态规则，工具早就能做，且比人稳定。还有几件事始终没被自动化。
评审者的困惑本身就是一种发现
资深工程师读 diff 时会说"I don't understand this"。这句话在工具眼里是失败，在人这里是最有价值的信号之一。它可能意味着抽象放错了位置，可能意味着命名和实际职责对不上，也可能意味着作者自己也没想清楚这段要解决什么。
模型不会给出这种信号。它总能在某种程度上解释一段代码，哪怕是硬编一个说法。把这段注意力换成工具输出，团队就丢掉了唯一可靠的复杂度报警器。
有研究在 2025 年系统测过模型识别"缺失信息"的能力，AbsenceBench 用四千三百多个测试用例考察语言模型能不能发现本该存在却没出现的内容，结果普遍不理想。对应到评审现场，就是 API 契约改了但错误处理没跟上、文档删了一段但引用还在、分支加了新分支却没处理默认情况。人能看到"不存在的东西"，这是盲区所在。
评审是质疑变更的最后一个时机
代码合并之前，很少有其他地方能问出"这次改动真的必要吗"。它它可以问成这个 PR 该不该拆成两个，也可以问成改动是不是只在治症状。这类问题没有标准答案，只能由了解业务和现状的人提。
合并之后，变更的代价才开始累积。评审是多个人能低代价说"再想想"的最后一个时刻。
谁来签这个字
自动化论证里有一个常被忽略的差别，签署的人不一样。评审通过意味着一个具体的人对这次改动负责，出事故时这个人的判断会被追溯。智能体不承担这个后果，它的"通过"不附带任何责任。
责任不是流程装饰。它决定了评审里那些保守的决定为什么存在，也决定了谁有动力去追问作者没写清楚的部分。
工程上的落点
不是要退回到手工评审。有效率的团队早就把检测交给工具了。
- 风格、格式、已知反模式、依赖漏洞扫描，全部交给 CI，人工评审不再重复。
- 评审的固定成本花在变更必要性、抽象位置、缺失分支这三类问题上。
- 新人和新模块提高评审强度，这种情况评审本来就是知识传递的主通道。
- 仓库之外的上下文要带进评审。上周这个服务出过事故、法务不让再记某个字段，这些信息不在代码里。
- 保留人工合入的最后一道权限，至少对核心路径。
常见问题
工具评审覆盖率上去了，为什么缺陷没少？ 它覆盖的是可检测缺陷。抽象放错位置、拆包不合理这类问题本来就不在检测范围内。
小团队没人手，还要人工评审吗？ 至少要有第二个人在合并前读过一遍。一个人看自己的代码，看不到自己当时的假设。
评审该花多久？ 按变更的风险定，不按代码行数定。改核心计费逻辑和改一段文档注释不该用同一个标准。