AI Code Review 接 CI/CD，门禁怎么设

01一个反共识：门禁不是"全过或全挡"，是分级

很多人接 AI review 到 CI，第一反应是"AI 说有问题就挡 PR"。结果第一周所有 PR 都被挡——因为 AI 总能挑出点问题。全挡等于没接，团队会直接关掉这个门禁。

门禁的精髓是分级：高危硬挡（如 SQL 注入、密钥泄露），中危警告（如 N+1 查询、缺失测试），低危放行只记录（如命名风格）。这样 AI 挑出的 80% 低危问题不挡路，20% 高危问题真挡住——团队既不被烦扰，又拦住了真危险。门禁不是过滤器，是分级路由。

02CI 门禁演示：勾选门禁看哪些 PR 被拦截

下面是 5 个 PR 和一组可勾选的门禁。勾选哪些门禁开启，看每个 PR 是被挡、被警告还是放行。注意分级的效果。

03硬门禁 vs 软门禁：挡的是行为不是意见

硬门禁和软门禁的区别不是"严不严"，而是挡的是什么：

• 硬门禁挡的是客观事实：测试没过、有未解决的高危评论、安全扫描报警。这些是机器能判定的"是/否"，挡了没人不服。
• 软门禁挡的是主观判断：AI 觉得这段代码可维护性差、命名不好。这些是意见，挡了会引发"AI 凭什么挡我"的争论。

所以硬门禁可以挡，软门禁只能警告。把软门禁设成硬挡，等于让 AI 当代码警察，团队会反抗。正确做法：软门禁只发评论、标"建议看"，最终拍板权在人。门禁的合法性来自"挡的是事实不是意见"——这是 AI review 接 CI 不被团队抵制的关键。

04门禁的演进：从全开到收敛

接 AI 门禁不是一次配好，是逐步收敛的过程：

1. 第 1 周：全软门禁。所有级别都只警告不挡，观察 AI 报的问题准不准、团队认不认。
2. 第 2-4 周：调阈值。看误报率，把误报高的门禁降级或关掉，把准的升硬门禁。
3. 第 2 月：开硬门禁。只对高危且误报率<5% 的开硬挡，其余保持软门禁。
4. 持续：定期复盘。每月看哪些门禁从没挡过（可关）、哪些挡太频繁（误报高，降级）。

关键认知：门禁配置是活的不死的。团队代码风格在变、AI 模型在升级、业务在迭代，门禁阈值要跟着调。设好就不管的门禁，半年后要么形同虚设要么怨声载道。把门禁配置纳入"每月 review"清单，是 AI review 长期有效的保障。

05带走这套清单