代码审查中的人机分工

审查的两个层次

代码审查从来不是一个单一的活动。它至少包含两类截然不同的任务：模式匹配和判断力。

模式匹配是确定性的：这个变量名不符合命名规范、这段代码有未处理的异常、这个 SQL 查询存在注入风险。这些问题有明确的规则可以判定——给定规则和代码，结论是唯一的。

判断力是概率性的：这个抽象层级划分是否合理、这个设计决策在当前业务阶段是否正确、这段代码的可维护性在六个月后会不会成为问题。这些问题没有唯一正确的答案——它们需要审查者结合业务上下文、团队能力和系统演化方向来判断。

将这两类任务混在一起，由同一个人在同一轮审查中完成，是当前代码审查中最浪费效率的做法。审查者的注意力被格式问题和命名不一致分散，以至于没有精力去想真正重要的设计问题。

AI 的可靠领地

AI 在模式匹配层面的审查能力已经超越了大多数人类审查者。因为模式匹配任务有两个特征本身就适合 AI：规则的形式化程度高，只需要局部上下文。

格式与风格一致性。 缩进、空行、导入排序、括号风格——这些规则可以完全形式化，AI 的检查结果和 linter 一样确定性。AI 相比传统 linter 的增量价值在于它能理解语义层面的风格一致性：同一个代码库中，有些模块用工厂模式创建对象，另一些模块直接调用构造函数——这种不一致 linter 抓不到，但 AI 可以基于上下文识别。

常见 bug 模式。 资源泄漏（打开文件未关闭）、空值解引用、越界访问、类型不匹配——这些 bug 模式在数十年的软件工程历史中已经被充分编目。AI 可以在一次审查中同时检查所有已知模式，而人类审查者的注意力是串行的、有限的。

安全反模式。 SQL 注入、XSS、硬编码凭证、不安全的反序列化——安全审查的核心是模式识别，AI 在这方面有两个结构性优势：它不会遗漏（不受注意力疲劳影响），它的模式库可以持续更新（新的 CVE 转化为新的检查规则）。

文档与代码的一致性。 函数签名变了但文档没更新、参数名改了但注释中还是旧名字、返回类型声明与实际返回不一致——AI 可以自动检测代码与文档之间的偏差，这是人类审查者在时间压力下最容易忽略的问题。

把这些任务交给 AI，根本原因是"AI 做这些事情的边际成本趋近于零"。人类审查者花在格式检查上的每一分钟，都是从设计审查中偷走的一分钟。

人的不可替代领地

判断力层面的审查，AI 目前做不了——这些判断需要的上下文，一个上下文窗口远远装不下。

架构适配性。 一段代码单独看可能完美无缺，但放到系统整体中可能是一个错误的决策。这个模块应该是独立服务还是库？这个依赖方向是否会在未来制造循环？这些问题需要的是对系统演化方向的判断，远超代码层面的模式匹配。AI 没有这种系统级视角——它能看到提交上来的代码，但看不到代码背后的技术意图。

业务逻辑正确性。 代码正确实现了需求规格，但需求规格本身是否合理？一个折扣计算逻辑在数学上没有 bug，但折扣规则本身是否符合商业意图？这类判断需要领域知识，而且是那种从来没写进文档的隐性知识——团队共识、历史决策的背景、产品方向的权衡。

权衡评估。 软件工程中大量的决策是权衡而非对错：性能与可读性的权衡、灵活性与简单性的权衡、短期交付压力与长期可维护性的权衡。第二章讨论的"Strategy 大于 Analysis"在这里直接适用——权衡评估是战略层面的判断。AI 可以列出各选项的利弊（分析），但无法代替人做出取舍（决策）。

团队和组织上下文。 这段代码的作者是新人还是资深工程师？审查的目标是教学还是把关？团队当前是在赶交付日期还是在偿还技术债？这些因素深刻影响审查的策略和反馈的方式，但它们完全不在代码之中。

工作流设计：串行流水线

人机协作审查的正确拓扑是串行：AI 先审查，过滤掉模式级问题，人在此基础上专注设计级问题。

选择串行的理由：并行模式下，人仍然会被模式级问题分散注意力——哪怕 AI 已经指出了这些问题，人在阅读代码时仍然会注意到它们。串行模式的关键操作是：AI 审查通过后自动修复格式和风格问题，人看到的代码已经是通过模式级检查的干净版本。

两个层次的分工可以显式化为一张分类表：

层次	责任方	审查类别	特征
模式层	AI	格式一致性、命名规范、未使用的导入、资源泄漏、空值安全、SQL 注入风险、硬编码凭证、文档与代码不一致	规则可形式化，判定结果唯一，可自动修复
判断层	人	架构适配性、业务逻辑正确性、设计权衡、抽象层级合理性、性能策略选择	依赖上下文，无唯一正确答案，需要领域知识

置信度与升级机制

AI 审查层不应该只输出"有问题"或"没问题"，还应该输出自己的置信度。低置信度的模式级发现应该自动升级到人类审查层，而非被自动修复或自动忽略。

原理跟测试分层一样：结构层面的检查可以自动化并完全信任，语义层面的检查需要人的参与。审查流程要做的是把人的注意力集中到最需要判断力的地方。

模型的简化

这个分层模型假设模式级问题和判断级问题是可以干净分离的。现实中，两者经常纠缠在一起。一个命名问题可能反映了概念理解的偏差（判断级），一个架构决策可能表现为一个常见的反模式（模式级）。碰到边界模糊的情况，分层模型需要人为裁定，这意味着流程设计中必须保留升级通道，而非假装边界是清晰的。

另一个实际限制是工具成熟度。截至目前，能够可靠执行模式级审查的 AI 工具仍然需要大量的配置和调优，其误报率在某些代码库上可能高到降低团队对审查结果的信任。工具的可靠性本身需要持续的投入来维护——这是一个经常被低估的运营成本。