AI 代码评审进 PR：4 步降噪只留真问题

多数团队接入 AI 评审的结局都一样：前三天人人点赞，两周后所有人折叠评论、直接点 Approve。不是模型不行，是你让它当了「评论刷屏机」。AI 评审的价值不在评论数量，而在把某一类问题提前拦住。下面 4 步，是从「全量开喷」走到「只留真问题」的最小可行路径。

一、先划边界：只让它管四类事

AI 最擅长、也最容易被人类忽略的是：安全（SQL 注入、密钥硬编码、路径穿越）、资源（连接未释放、文件句柄泄漏、N+1 查询）、并发（共享状态、竞态、缺锁）、错误处理（吞异常、空 catch、失败无回滚）。

反过来，命名、缩进、注释多少、要不要拆函数——这些交给 formatter 和 linter，AI 一句都别说。经验数据：把风格类评论全关掉，评论量通常掉一半以上，投诉量掉得更多。规则要写进评审规则文件（如仓库里的 AI_REVIEW.md），而不是靠 prompt 里一句「请客观」。

二、分置信度：高置信才留 inline

不要让每条发现都变成行内评论。设置三档：

• blocker：高置信、可复现、有明确修法 → 行内评论 + 请求修改；

• suggestion：中等置信 → 汇总成 PR 描述里的一条列表，不打断阅读；

• nit：不输出。

硬性门槛：一条评论必须同时包含「为什么这是问题（触发场景）」和「具体怎么改（最小 diff）」。缺少任一项就直接丢弃。这条规则能砍掉大半模棱两可的「建议考虑优化」。另外记住：门禁只放 blocker 中的极少数硬规则（如密钥检测），其余都是建议，不阻塞合并，否则开发者会想办法绕过你。

三、补上下文：只喂 diff 必然误报

AI 评审最大的误报源，是它只看到 diff。你把一个有意的默认值改动提交上去，它看不到调用方，就会报成 bug。

给模型补齐四类材料：

1. 被改文件的完整内容，而非仅 hunk；

1. 调用方签名（grep 出被改函数的引用位置）；

1. 相关测试文件，让它先读断言再判断行为；

1. 项目约定文件，把「本项目允许的写法」写清楚。

补充后误报率往往明显下降。成本与延迟方面：按目录或文件分片评审，设置超时上限；触发时机只在 opened 和 ready_for_review，不要每次 push 都跑，否则同一问题会被重复贴三次。

四、做反馈闭环：让误报不再出现

每条 AI 评论都要能被一键标记：有用 / 无用 / 忽略此类模式。每周花十分钟回看被标记无用的评论，把高频误报写进规则文件的排除清单。

设两个可观测指标：

• 评论采纳率 ≥ 60%（低于这个数说明规则太吵）；

• 每条 PR 的 AI 评论数 ≤ 3（超过就说明你在制造噪音）。

另外盯一个反向指标：blocker 漏检。抽查已合并的 PR，看是否有本该被拦住的问题，用来调 prompt 和规则，而不是靠感觉。

结语

把 AI 评审当成一个值夜班的初级工程师：它守规则、不知疲倦、从不抱怨，但它需要一份写得足够清楚的手册。你要给的正是这份手册——边界、置信度、上下文和反馈。做对这四步，AI 评论才会从「已读忽略」变成团队真正会停下来看一眼的那几条。