复盘一件上周真正踩的事：我用 AI 生成并 review 通过的代码，deploy 后线上还是出了 30 分钟的故障。今天把这个过程拆给你看，问题出在哪一步。
背景：一个内部工具要加一个导出功能。我让 AI 写，AI 给了完整实现，我 review 时看逻辑、看边界、看异常，感觉没问题，就 merge deploy 了。结果线上导出大文件时内存直接被打爆，进程 OOM 重启，服务中断 30 分钟。
事后逐层查了 4 个小时，真正的根因不是 AI 的代码逻辑，而是三件 review 时根本没碰的东西：
第一：review 只看了「正常路径」。AI 写的代码对正常输入没问题，但大文件场景下它把整个文件一次性读进内存，没有任何流式或分块处理。review 时我所有测试用例都是小数据，根本没触发到大数据分支。
第二：没有 load test 就 deploy。我 review 的是逻辑对不对，但忽略了数据量上来会怎样。这个维度 review 看不到，必须靠真实压力或至少构造大数据样本验证。
第三：监控没接。进程 OOM 重启后，如果我第一时间能从监控看到内存曲线跳水，能早 20 分钟定位。但当时没有任何应用级监控，只能靠用户反馈才发现。
这次事故的结论我写成了三条铁律，现在每次改完都过一遍：
- review 不只对正常路径，必须主动想最大输入和并发会怎样——这是 AI 生成代码最容易漏的，因为它默认你给的是合理数据。
- 改动涉及数据量/并发相关的，哪怕很小，也要先跑一个大数据样本的冒烟测试再 deploy，不能只看逻辑对。
- 部署前确认这个链路有没有监控，没有就先补上最基础的，否则故障来了只能摸黑。
说白了，AI 帮我写代码确实快，但代码能跑和在生产环境经得住真实压力是两回事。review 的维度要从对不对扩展到扛不扛得住，这个责任始终在我，不在 AI。
如果你也在用 AI 写代码后直接上生产，强烈建议把上面三条过一遍，能省下很多次像我今天这样的 30 分钟故障。
