AI 把一次改动从半天压缩到十几分钟后，代码审查很容易成为新的瓶颈。更麻烦的是，产出速度提高会让“看起来没问题”的改动快速堆积。单靠审查者逐行阅读，既跟不上，也不可靠。

成熟的交付流程并不是找到一个更聪明的审查工具，而是让风险逐层收敛。

第一层在提交前。格式化、静态检查、单元测试、依赖漏洞和密钥扫描应该自动运行。AI 生成的代码还要额外检查：是否绕过现有封装、是否偷偷扩大权限、异常路径有没有测试、生成的依赖是否真实且必要。

第二层是合并门禁。短分支或主干开发都可以，但主分支必须受保护；至少一名理解模块的人审查高风险改动，CI 全部通过后才能合并。审查重点从“每行像不像人写的”转向接口变化、数据一致性、并发、权限和回滚方式。

第三层是只构建一次。同一个 commit 生成带版本号的制品，经过测试后在环境之间晋级，而不是到生产环境重新拉代码、重新构建。这样出问题时，才能准确知道运行的是哪一份东西。

第四层是渐进发布。常见做法是蓝绿或金丝雀：先让少量实例或流量进入新版本，观察错误率、延迟、资源使用和业务指标，再逐步扩大。Argo Rollouts 一类工具可以把指标分析和暂停步骤写进发布过程；GitHub Environments 则能为生产环境增加审批、分支限制和部署保护规则。

最后才是回退。应用镜像回退通常不难，真正麻烦的是数据库和消息格式。因此表结构要尽量向前、向后兼容：先加字段并兼容双版本，完成数据迁移，再删除旧字段。功能开关也很重要，它能在不重新部署的情况下关闭高风险路径。

我心里比较完整的一条链路是：

提交
  -> 自动检查与测试
  -> 人工审查风险点
  -> 生成唯一制品
  -> 测试环境验证
  -> 小流量发布
  -> 指标达标后放量
  -> 异常时自动停止或回退

大公司使用的工具并不完全相同，但思路很接近：把可靠性分散到门禁、制品、环境、观测和回退中，不让某一次人工审查承担全部责任。

AI 让代码供给增加以后，团队真正需要扩容的是验证能力。写得快是一种效率，能够放心上线、出事后迅速退回，才是生产系统承认的效率。

参考：