代码审查：在AI作者之上叠加AI审查者是不够的

随着AI编码工具的普及，工程团队面临的并非简单的效率提升，而是风险格局的转变。AI生成的代码往往格式规整、文档齐全，并附有清晰的变更说明，但这些表象无法掩盖其潜在的安全隐患。一篇代码变更可能看起来生产就绪，通过了单元测试，但其中可能隐藏着逃脱用户输入转义的渲染路径，或是一个带有已知漏洞的新依赖项。

近期独立基准测试表明，大型语言模型（LLM）在生成功能正确代码方面表现优异，但在安全代码生成上仍然困难重重。提高功能正确性的技术并未能可靠地改善安全结果。这意味着，一个变更可能看起来滴水不漏，却仍需确定性安全检查才能合并。

Faros AI的遥测研究基于22,000名开发者和4,000多个团队的数据，发现随着组织从低AI采用向高AI采用过渡，事件与拉取请求（PR）的比率飙升了242.7%。同时，无任何审查（包括AI或人工）就合并的PR增加了31.3%。这明确表明，审查实践未能跟上代码吞吐量的增长。

以一个具体场景为例：开发者请求AI辅助添加用户更新个人简介的端点。AI返回了新的路由、数据库迁移、React组件以及一些通过了测试的单元测试。然而，这些代码中可能包含：未经转义直接渲染用户输入的XSS漏洞、带有已知安全建议的新Markdown解析库、测试夹具中的真实凭证（本应为占位符）、以及仅验证了乐观路径而未测试授权边界的单元测试。这些问题在传统的快速浏览式审查中极易被忽略。

那么，在AI作者之上再叠加一个AI审查者是否就能解决问题？研究表明，这远远不够。GitHub上超过五分之一的代码审查现由AI代理参与，但Faros AI的数据显示，仅约1%的PR完全由AI自主开启，其余风险仍通过人类名义上负责的代码流转。更深层的问题是感知差距：METR的随机对照试验发现，使用AI工具的资深开发者完成实际任务所需时间显著更长，但他们自以为效率更高。这种自信与基于验证的自信截然不同，却常被混淆。

AI审查的价值在于作为生产力助手：生成变更摘要、建议测试用例、辅导初级工程师。但它绝不能成为合并决策的权威。对于安全相关的门控，应依赖独立的确定性检查和有责任感的审查者。

构建实用的审查工作流需遵循以下原则：识别AI辅助的PR（如添加标签）；对每个PR应用基线门控（如秘密扫描、依赖扫描、静态分析、测试覆盖）；对高风险的变更（认证、支付、客户数据、基础设施）设置更高门槛和强制人工审查；保持AI审查的咨询性质，合并权限仅授予必需的检查和指定审查者；限制覆盖必需检查的权限，并记录所有例外。

AI编码工具确实提高了吞吐量，但吞吐量改变了工程风险的形式，而非消除了风险。最成功的组织是将AI辅助开发与变更点的一致性执行门控相结合，而非仅依赖AI的自我验证。