一次合并请求里，AI 提了十四条意见：命名不统一、少了一个空行、日志级别用错。真正的问题——同一个回调被重复触发时会重复扣款——一条都没提，因为代码里看不出「这个回调可能被调两次」。代码审查接上 AI，收益和风险都在这条缝上。下面说清三件事：哪些问题适合交给工具、一轮审查按什么顺序走、哪些判断只能由写代码和懂业务的人来做。
形式问题归工具，语义问题归人
把审查意见按「能不能只靠代码本身判断」切一刀，界线就出来了。空值没判、数组越界、除零、异常被吞、连接没关、锁的范围过大、同类逻辑在两处写法不一致——这些在代码里有确定的形态，规则工具和模型都能识别。另一类问题需要代码之外的信息：这段改动要解决什么、这个抽象该不该存在、这里为什么绕成这样。工具拿不到这些，它只能按通用最佳实践评，评出来的东西放在任何一个仓库都成立，也就等于没针对你的仓库。
这一刀还决定工具选型。形式检查用规则引擎比用大模型划算：确定、可复现、毫秒级、不产生幻觉。让模型去做 lint 的活，得到的是时好时坏的建议，还得逐条判断真假。模型的位置在规则管不到的地方——读 diff 猜意图、找「这段改动和周围代码风格不一致」这类模糊模式。写这类判断要求把背景交代清楚，提示词里角色、目标、约束怎么写直接决定它给的是通用套话还是贴着仓库的建议。
一轮审查的五步
从拿到 diff 到清单更新，五步各有产出物，也各有各的塌方点：
| 步骤 | 产出物 | 常见坑 |
|---|---|---|
| 定分层 | 一张「规则工具 / 模型 / 人」各管什么的分工表 | 让模型干 lint 的活，慢、不稳定，还要人复核 |
| 交代背景 | 一段固定的变更说明：改动目的、涉及模块、已知约束 | 只贴 diff，它按通用规范评，意见与仓库无关 |
| 出候选 | 按形式、语义、待确认三组分类的意见清单 | 几十条平铺，评审人看到第八条就开始麻木 |
| 人工裁决 | 必须改 / 建议 / 不成立 三档结论 | 把不成立的直接删掉，不追问它为什么误判 |
| 回填清单 | 一条带失败样例的新检查项 | 只写「注意边界」，下次照样漏 |
裁决环节最容易走过场。模型给的候选里通常有一半不成立——它按通用规范提的意见，在你的项目里可能正是约定俗成的写法。把「不成立」的判断当场记下来，是清单能变准的唯一途径；只把成立的写进去，同样的误报下次还会来。误报和漏报的取舍本身有代价，混淆矩阵里那四个格子说的就是这件事，审查清单只是在用文字做同一道权衡。
它读不出的，是代码外面那层信息
业务语义错是最常见的一类。代码符合规范、测试也过，但它实现的规则和真实需求差了一层——比如优惠券的叠加顺序，需求方说的是「先打折再用券」，代码写成了反过来。模型没有需求文档，也没有那次会议的上下文，它看不出这个偏差，只能看出「这里的命名不够达意」。
设计层面的判断同样交不出去。这个工具类该不该存在、这个模块该不该拆、这层抽象是不是过度——这些要放到整个系统的演进里看，而它看到的只有你贴进来的那几百行。历史包袱更典型：一段绕得离谱的兼容代码，背后可能是三年前某次线上事故，原因没写进注释。模型会认真建议你「简化这段逻辑」，照做就等着事故重演。
四类判断它交不出来
把边界收拢，有四类问题基本别指望它：需求是否被正确实现（它不知道真实需求）、抽象与拆分是否合理（它看不到系统全貌）、某段代码为什么长成这样（历史原因不在代码里）、这次接受多少技术债划算（涉及进度、人手、上线时间）。第五类更隐蔽——跨服务的隐含契约。A 服务假设 B 一定返回非空数组，这个假设写在哪都可能没写，只有出过事的人知道。
还有两个技术性失效点值得记住。diff 太长时上下文会被截断，它只评了前一半，却不会告诉你漏了哪段，上下文窗口装不下时模型的表现是安静地丢掉中间部分。它也会编造不存在的函数名和字段，尤其是你只贴了片段、它看不到完整定义的时候；这类虚构跑一次就报错，反而好发现，难发现的是那种能跑通、却断言了错误行为的测试建议，模型编造细节时不会标注哪句是推测。
清单从漏项里长出来，不从模板里抄
网上的审查清单大多长一个样：命名、注释、异常、日志、性能。照着抄一遍，能挡住的问题你在第一周就挡住了，剩下的漏项一条也补不上。有效的做法是反向生长：每次线上出问题，回到那次合并请求，问一句「如果当时清单上有哪一条，这个问题会被拦住」。答案写进去，带上这次的失败样例。半年下来，清单会变成这个仓库特有的东西——它记录的是你们犯过的错，不是别人的通用建议。
清单还要能被机器执行。一条「注意并发安全」没法执行，一条「凡是对共享计数器做读改写的，检查是否用了原子操作或加锁」就能落到具体的 diff 行上。写得越具体，越能交给工具预筛，人只需要看筛出来的那几条。
意见怎么写，决定评审会不会变成走流程
同一条问题，「这里写得不好」和「这个分支在超时后会重试三次，下游没做幂等，可能重复下单」收到的反应完全不同。前者让人防御，后者让人去查。审查意见分两档就够：必须改（会导致错误、安全问题、数据不一致），建议（可读性、风格、更优写法）。混在一起，每条都像在挑刺，作者会开始逐条争辩，评审时间全耗在低价值的分歧上。
改动规模也要控。几百行的合并请求，认真看完的人很少，多数人扫一眼标题就点了通过。拆成几个小批次，每批只做一件事，审查质量会明显不一样。这一点和工具无关，但比换哪个模型影响更大。
速查：代码审查清单的分工
- 规则工具管确定的事：空值、越界、未释放资源、类型错误
- 模型管模糊的模式：与仓库写法不一致、可疑的重复逻辑、待确认的业务点
- 人管代码之外的事：需求对不对、抽象合不合理、这笔技术债值不值
- 每次漏检都回填一条带失败样例的检查项，清单才有本地性
- 意见只分「必须改」和「建议」两档，避免评审变成情绪对抗
