AI 生成的代码进生产前，安全审查到底该卡在哪一步？

【背景】 这两年团队里 AI 辅助写代码越来越普遍：补全、整段生成、甚至整模块脚手架，一晚上能刷出上千行。我最近做安全加固复盘时发现一个有点反直觉的现象——漏洞数量没明显涨，但漏洞的「藏法」变了。以前 SQL 注入、硬编码密钥这类「一眼就能看出」的坑，人写代码时最容易犯；现在 AI 写得「很规范」，反而爱把风险藏在「看起来完全合理」的地方：一段逻辑正确的远程调用里悄悄没校验来源、一个「标准写法」的依赖升级里引入了已知 CVE、一段生成出来的鉴权中间件漏了某个边角路由。打个比方：以前小偷翻墙，现在小偷穿着制服、拿着工牌进门，门口的人反而更难拦。

【常见分歧 / 几种做法】 我在不同团队看到过至少三种截然不同的姿势：

1. 「当人写的代码查」：CI 里跑 SAST/SCA，AI 生成的和手写的走同一条流水线，不特殊对待。理由是流程统一、成本低，AI 代码又不是新的物种。
2. 「AI 代码单独加一道卡口」：凡是 AI 生成占比超阈值（比如 50%）的 PR，强制要求安全 review 多签一人，或者补一轮人工 threat modeling。理由是 AI 代码「看起来很对」，自动化工具和习惯扫一眼的人都容易漏。
3. 「源头治理」：不去卡 PR，而是把安全约束写进团队的 AI 提示词模板 / 代码生成规范里，让 AI 一开始就按安全基线产出，事后只做抽检。理由是「左移」，审查是补救，约束是预防。

【我的倾向与理由】 我的倾向是 以 3 为主、1 为底、2 只在关键路径上做，理由有三点：

• 第一，「左移」永远比「右拦」便宜。安全约束写进生成阶段的模板，等于让 AI 一开始就「知道哪些门不能进」，比事后用 SAST 去翻它刚砌好的墙划算得多。
• 第二，自动化工具（SAST/SCA）必须是无差别底座，不能因为「AI 写的」就放松，也不能因为「AI 写的」就怀疑——审查标准应该对代码一视同仁，差异只该体现在审查强度和抽检比例上。
• 第三，人工加签不能撒胡椒面，只该落在鉴权、密钥、外部输入、反序列化这类高危路径上，否则 review 会变成形式。

【想听大家怎么聊】 特别想收集几个具体场景下的取舍：

1. 你们现在对「AI 生成占比」有量化标准吗？还是干脆不看占比、只看代码本身？
2. 有没有遇到过「AI 写得规规矩矩但埋了雷」的真实 case？方便脱敏后分享吗？
3. 如果让你给新团队定一条「AI 代码安全准入」红线，你最先会卡哪一条？
4. 站在安全工程师的立场，我最怕的是「大家都觉得 AI 代码更靠谱」这种错觉——你团队里出现过这种心态吗？怎么破的？

欢迎不同立场一起聊，也欢迎拍砖。