AI 写代码、AI 来审代码并不够：一份审视代码评审链路的工程提醒

在 AI 编码助手广泛进入工程团队之后，「AI 写的代码由 AI 来审」看似顺理成章，但一份来自工程社区的讨论提醒：这条链路并不足以保证交付质量。AI 生成的拉取请求（PR）往往格式整齐、说明详尽，CI 绿灯，这恰恰可能掩盖功能正确之外的安全与合规风险。文章结合 2026 年公开的遥测数据，论述了为什么 AI 辅助 PR 需要一条独立于传统流程的评审路径。

AI 代码为何「看起来就可投产」

大语言模型擅长产出格式规范、文档齐全且附带解释的代码改动。一个让模型新增「个人资料编辑接口」的需求，可能一次性得到路由、数据库迁移、前端组件与一组通过的单元测试。但代码 diff 中可能藏着未对用户输入做转义就直接写入 DOM 的渲染路径，也可能引入一份带有未处理漏洞公告的 Markdown 解析依赖。

这种模式已被多项独立基准观察到：现代 LLM 经常能生成功能正确的代码，但「安全的代码生成」仍是显著更难的子问题；提升功能正确率的技术，不一定能同步改善安全结果。因此，一处变更即便测试全绿、看起来可投产，仍需要在合并前通过确定性的安全检查，而非依赖「新一代模型默认更安全」这一未经数据支撑的假设。

2026 年的运营侧证据

Faros AI 基于 22,000 名开发者、超过 4,000 个团队数据的遥测研究显示，组织从低 AI 采纳走向高 AI 采纳的过程中，「每生产事故对应的合并 PR 数」比低采纳基线高出 242.7%。换言之，在高 AI 采纳阶段，相对合并量而言的生产事故数翻了三倍有余。

同一份报告还指出，未经过任何评审（无论是人工还是 AI）就合并的 PR 增加了 31.3%。这说明当代码进入评审的速率超过评审实践演进的速率时，原本为人均节奏设计的流程会被冲垮，质量指标在下游承压。

作者同时提醒读者将这些数字视为方向性参考，尤其警惕带有商业立场的厂商基准；更值得工程负责人去做的事，是把自己的漏洞密度、评审时延与逃逸缺陷率在 AI 采纳前后做一次重新比对。

AI 生成 PR 如何绕过现有的安全护栏

以「让用户更新公开简介」为例，模型一次性产出接口、迁移、渲染组件、Markdown 库与一组单元测试。一个快速浏览配合 AI 生成的 PR 说明，可能错过以下几类风险：

• Markdown 渲染器把未净化的 HTML 直接写入页面，对未专门排查不安全渲染模式的审阅者而言，看似普通 React 代码却藏着 XSS 路径。
• 新引入的 Markdown 依赖可能带有未处理漏洞公告，或拉入有风险的传递依赖，只有软件成分分析（SCA）能识别。
• 测试 fixture 中可能夹带看似占位、实则为真实形态的凭据，而审阅者恰恰最不倾向于打开这类文件。
• 测试可能只覆盖了「用户能更新自己的简介」这一正向路径，未验证同一接口是否允许用户改写他人简介。

这些缺陷都不会出现在「代码看起来干净」的目视评审里。能拦住它们的，是一组无论代码外观如何都会强制执行的护栏：在包括 fixture 在内的每个文件上跑密钥检测、对新依赖运行 SCA、用静态分析标记不安全渲染模式，并在合并前真正评估这些检查的结果，而不是把 CI 绿灯当作充分证据。

工程团队可以立刻做的几件事

针对 AI 辅助 PR 这条独立评审路径，作者给出的实践建议包括：为 AI 生成 PR 打标签，强制运行专门针对顽固失败类别的安全检查；让分支保护真正评估扫描结果而非放行绿灯；按团队自身指标重新校准质量基线，把为人均节奏设计的护栏，重建为适应机器节奏的护栏。AI 编码工具不会自动变安全，安全的责任最终仍要落回工程流程与确定性检查之上。