AI 时代，程序员最需要培养的能力，可能已经不是写代码了，而是审查代码、判断风险，并对最终交付结果负责。
Codex、Claude Code 这类工具越来越强，以前几天甚至几周才能开发出来的功能，现在几个小时就能跑起来。但 AI 能把代码写出来，不代表它真的能用于生产环境。
最危险的不是程序直接报错，而是它看起来一切正常：前端能打开，API 能调用，数据库能读写，Demo 演示得非常流畅，AI 还会告诉你功能已全部完成、测试已通过。
可 Demo 阶段暴露不出来的问题，上线后就是实实在在的事故：同时 100 个用户请求会怎样？第三方 API 突然超时怎么办？用户连续点两次提交会不会重复下单？任务执行到一半失败，重试会不会重复扣费、重复写数据？接口权限有问题，普通用户能不能读到其他客户的数据？半年之后再改这套代码，还能不能搞清楚它的逻辑？
所以上线前要做的，不是只让 AI 帮你写代码，更要让它站在一个挑剔的高级工程师视角，专门找自己代码的问题：从安全漏洞、并发性能、异常处理、用户真实操作、长期维护成本几个角度重新审查整个系统。
而且不能只给一句“代码整体质量良好，建议优化异常处理”，这种话没有任何价值。要让它指出具体文件、具体代码位置、问题触发条件、实际影响、修复方案，以及修复之后应该如何验证。找不到证据的问题就明确说不确定，而不是为了完成审查任务编造漏洞。
当然，AI 给出的审查结论也不能直接当成事实。真正上线之前，权限测试、并发测试、异常注入、自动化测试和人工复核，一个都不能省。AI 可以帮你寻找风险，但不能替你承担风险。
这也是能力结构变化的地方：以前衡量一个程序员，很大程度上看他能不能独立完成某个功能；现在代码生成越来越便宜，真正有价值的能力往上移了——你能不能设计合理的架构？能不能识别 AI 生成代码中的隐患？能不能判断什么时候重构、什么时候保持简单？能不能在功能、性能、安全和开发成本之间做出取舍？
尤其是做企业 AI 落地，客户根本不关心你用了多少个 Agent、多少个 Skill，也不关心代码是不是 AI 写的。他只关心系统能不能稳定运行，出问题之后能不能恢复，数据会不会泄露，业务会不会受到影响。
以前写出一个功能，可能是工作的终点。现在 AI 写出一个功能，反而只是工程工作的起点。能跑起来只是第一步，能稳定运行、经得起真实用户折腾、出了问题还能恢复，才是真正的工程能力。不要因为 AI 告诉你“任务已完成”，就真的以为项目已经完成了。