AI 让代码越来越便宜，软件交付的瓶颈正在转移
AI 编程工具带来的一个直接变化是，代码产出的速度已经开始超过团队验证代码的速度。
以前一个需求可能要写两天。代码出来以后，审查者还有时间顺着业务逻辑一点点看，测试也有时间补场景、找边界条件。
现在不太一样了。半小时就能生成一批接口、测试、配置，甚至连数据库变更一起给出来。代码量上去了，但真正麻烦的通常不是编译错误，而是那些看起来没什么问题、实际却在某个边界条件下做错事情的实现。
这类代码往往语法正确、结构完整，测试可能也能通过。问题可能只是需求理解偏了一点，权限范围多放开了一层，或者消息重试时多写了一次数据。
代码写得越快，这类问题就越容易堆到审查和发布阶段。
过去团队更容易卡在“代码还没写完”，以后更可能卡在“这些代码到底能不能放心上线”。
这也意味着，单纯提高开发速度已经不够了，后面的审查、验证和发布能力也得跟着调整。
代码审查的重点要变
代码量持续增加以后，人工逐行兜底很难长期维持。
格式检查、Lint、静态分析、单元测试、依赖漏洞、密钥泄漏这类规则比较明确的事情，本来就更适合交给 CI。
AI 也可以先做一轮辅助检查，比如找重复实现、遗漏的错误处理、常见并发问题、明显的资源泄漏，或者指出哪些改动没有对应测试。
人的时间应该更多放在代码之外的上下文上。
比如接口新增一个字段，除了看代码写得对不对，还得考虑旧客户端是否兼容。
一个同步写入改成异步任务，需要关心的不只是 goroutine 怎么写，还要看任务失败以后留下什么状态，重试会不会造成重复写入。
权限逻辑改了一行，也不能只确认条件表达式没写反，还得确认这个变化有没有扩大数据访问范围。
所以代码审查越来越像是在确认一件事情：这次改动到底改变了系统什么行为。
审查者至少应该能说清楚改动范围、主要风险和验证方式。涉及核心业务、权限、数据一致性这类高风险模块时，还需要熟悉模块的人参与。
代码可以很快生成，但这些判断不会因此自动完成。
发布不应该是一个瞬间，而应该是一个过程
测试环境永远只能覆盖生产环境的一部分。
真实流量、数据分布、依赖延迟、缓存状态、机器负载，这些因素都有可能让一个测试环境表现正常的版本在生产上暴露问题。
所以测试通过，和适合直接全量上线，是两回事。
更稳妥的做法是逐步放量，例如：
1%
↓
5%
↓
20%
↓
50%
↓
100%
每一步先跑一段时间，看指标是否正常，再决定要不要继续扩大流量。
金丝雀发布解决的就是这个问题。蓝绿发布虽然实现方式不同，本质上也是尽量避免一个未经生产流量验证的新版本一次接管全部请求。
这里还有一个经常被忽略的问题：发布时不能只看技术指标。
CPU、内存、错误率、P99 延迟都正常，不代表业务一定正常。
一个订单接口完全可能全部返回 200，但金额算错了。
数据任务也可能没有任何报错，只是同一批数据被写了两遍。
所以发布阶段最好同时关注两类信号：
技术指标
错误率
延迟
CPU
内存
线程数
连接数
队列堆积
业务指标
订单成功率
支付金额
设备在线率
消息重复率
数据完整率
任务处理量
技术指标告诉你服务是不是“活着”，业务指标才能进一步说明它是不是“做对了”。
回滚的关键是要在设计之初做好前后版本兼容
回滚并不总是一次简单的版本切换。
新版本可能已经改了数据库结构，写入了新格式数据，发出了消息，或者调用了外部系统。这个时候旧版本重新启动，并不代表系统就恢复到了发布前的状态。
所以比“出了问题自动退回去”更重要的，是平时就把回退条件准备好。
数据库变更可以尽量采用 Expand / Contract 的方式：
Expand
↓
新旧版本同时兼容
↓
完成迁移
↓
Contract
先增加新结构，让新旧版本都能工作；等迁移完成、旧逻辑彻底退出以后，再删除旧结构。
消息格式也要考虑前后版本兼容。
风险较高的新能力可以放在 Feature Flag 后面，出现问题时先关闭功能，而不是立刻重新部署整个系统。
旧版本镜像要保留，回滚步骤提前写清楚，负责人明确，关键操作最好也实际演练过。
这些事情平时看起来比较琐碎，但真的出问题时，它们往往比“支持自动回滚”更有用。
AI 时代真正需要扩容的是验证能力
如果一个团队一天能产出过去一周的代码，但测试、审查和发布能力没有变化，整体交付速度并不会同比提升。
瓶颈只是从编码阶段移到了后面。
过去：
需求
↓
【编码瓶颈】
↓
测试
↓
发布
AI 之后：
需求
↓
代码快速生成
↓
【审查瓶颈】
↓
【验证瓶颈】
↓
【发布瓶颈】
所以后续真正需要补的是整条交付链路。
比较理想的流程大致会变成：
代码提交
↓
自动检查
↓
自动测试
↓
AI 辅助审查
↓
人工检查关键风险
↓
合并
↓
构建制品
↓
测试 / 预发布验证
↓
小流量发布
↓
观察技术指标和业务指标
↓
逐步放量
↓
发现异常后停止继续放量
↓
人工决定切流、关闭功能、修复或回退
GitHub Actions、GitLab CI、Jenkins、Argo CD、Argo Rollouts 都可以实现其中的一部分，具体用什么工具并不是最关键的。
更重要的是把确定性的检查尽量交给自动化，把人的时间留给需要业务背景和现场判断的事情。
AI 把写代码这件事变快以后，工程能力的差距会越来越多地体现在后半段：
能不能迅速判断一个改动影响了什么；
能不能拿出足够的证据证明它没有明显问题；
如果判断错了，能不能把影响控制住。
代码生成得快，只解决了“做出来”的问题。
能不能稳定地把它送到生产，仍然是另一件事。