代码审查：让 AI 先过一遍什么，别让它过什么

先跑工具，再让它看

格式、命名、明显的静态问题，交给 lint 和类型检查。这些活它做得慢、还可能漏，工具一秒出结果。

它该看的是工具看不出来的：这段逻辑对不对、边界处理全不全、错误处理合不合理、有没有并发问题。

顺序反了会浪费一轮。先让它看格式，它会给你三十条缩进建议，淹掉要紧的问题。

工具跑完还有一类它看不了：业务逻辑对不对。这需要它知道需求，把需求文档或者验收条件一起给它。

空值和边界。数组越界、除零、空字符串、时区。这类问题它见得最多，命中率高。

异常处理。catch 了但没处理、吞掉错误只打日志、finally 里又抛异常。

资源释放。连接没关、文件句柄没释放、锁没解。

明显的性能问题。循环里查数据库、N 加 1 查询、大对象反复拷贝。

风格偏好。它觉得应该用早返回，你的团队习惯嵌套 if。这类意见不改也行。

不存在的性能问题。看到一个循环就说 O(n²)，可数据量只有十条。

过度防御。给每个参数加校验，代码变长一倍，实际调用方已经保证了类型。

误报多了会让人不看它的意见。要求它每条标注严重程度，只处理高和中的，低的扫一眼就行。

必须改：会导致数据错误、会崩、会泄露、会死锁。这四类没有讨论空间。

可以不改：风格、命名、注释多少、日志格式。这些按团队规范来，不按它的偏好来。

判断方法只一条：这条不改，线上会不会出问题。会，必须改；不会，记下来下次重构再说。

还有一点：它给的建议要能落地。让它给具体改法，别只说“建议增加校验”。给不出具体代码的，多半它自己也没想清楚。

还有一条：让它说清“什么情况下这个建议不成立”。说不出来，说明它只是按套路提的。

补充一句让它审查 diff，不要审查整个文件。diff 超过五百行，先让作者拆。一次看五百行，人和模型都会漏。文件太大，它会盯着无关的老代码提意见，噪音盖过信号。

它提的问题要不要都回？

不用。挑必须改的回，其余记进技术债清单。逐条争论比改代码还费时间。

能不能让它直接改？

小改动可以，它改完你要看 diff。大改动让它给建议，人来落笔。

团队怎么统一用法？

定一条规则：AI 审查的意见分三级，高级必须处理，中级看情况，低级忽略。规则统一了，争论就少了。