“当审计员第一次问你‘你们审查AI生成代码的流程是什么’，而你答不上来时，你就会意识到缺口。”大多数团队对此只有不成文的默契——“我们像审查其他PR一样审查它”——但这种做法在AI生成代码仅偶尔出现时还行得通，当一份差异中有40%来自AI助手时，就彻底崩溃了。

一份书面政策能解决两件事：给团队一个可执行的统一标准，也给审计方一份能读的东西。而这套政策需要定义三道门槛，缺一道就会留下一个窟窿。

为什么“像审查普通PR一样”会失效？因为AI生成的代码会在人类代码罕见的问题上翻车：幻觉包导入，pip install能装但运行时报错；示例块里硬编码的凭证，审查者会因为像有意为之而跳过；在小数据集上根本看不出的O(N²)性能反模式。标准的PR审查规范从来不是为了抓这些问题而设计的。

Stack Overflow开发者调查一直在追踪一个不断扩大的裂口：AI编码工具的采纳速度远超团队为其建立治理的速度。“再多一双眼睛看差异”这种非正式审查规范，默认审查者知道要留意哪些失败模式。可AI生成的代码让失败模式变了，而审查规范还在原地。

当相当大一部分代码来自AI助手时，会引发三件事。审查者校准丢失：每个函数看着都像那么回事，审查者那种“不对劲”的感觉就被钝化了。坏模式的爆炸半径扩大：AI助手会稳定地重复自己的错误，一个坏模式常会蔓延到多个文件。而纸质线索也消失了：“这是模型生成的”——这句话根本无法成为安全团队能评估的解释。

政策用明确的关卡来替代丢失的校准。

一支纳入了AI编码的团队，其代码审查政策需要定义三道关卡：预提交检查，在开发者推送前于本地运行；CI关卡，必须在PR合并前通过；以及人工审查阈值，标明何时人类审查从可选项变为必选项。

预提交关卡在最坏问题进入仓库之前就拦下它们。CI关卡让扫描成为合并必需项，而不是一条建议。人工审查阈值则处理模式扫描器因缺乏上下文而无法评估的情形——逻辑错误、架构决策，以及任何涉及鉴权或资金的部分。每一道关卡对付不同的失败类型，抽掉任何一道都会留下空白。

最后，把这一切落到文件上，你需要一页政策模板。它不必长篇大论，只需要清晰地说清三道门槛分别检查什么、用什么工具、在哪个节点触发，以及哪些情况下必须由人来拍板。这一页纸，就是你的团队从“默契式审查”走向“可审计治理”的起点。