夜雨聆风发完之后收到几条留言，我觉得比文章本身还有意思。
一条说：当你有这种错觉的时候，说明AI已经开始转向了。
一条说：上次那谁不是已经不写代码了嘛，怎么越活越回去了。
还有一条说：有经验的值钱了，刚毕业的还是不好找工作。
你看，三个完全不同的角度。但归根结底都是一个问题：AI时代写代码这事，到底该怎么干？
今天就来拆这个事。
省流版：
AI写的代码有三个致命特点：会编造不存在的API、不理解业务上下文、自信满满地给出错误结果 审AI代码不能用审人代码的方式，要反过来：先审意图，再审逻辑，最后审细节 程序员的核心能力正在从写代码变成审代码，这是AI时代最大的技能转移
先讲一个真实的翻车案例。
有次我让AI帮我写一个订单导出的功能。需求很清楚：按时间范围导出订单，生成CSV文件。
AI两分钟写完了，代码结构漂亮，注释齐全，类型安全。
我差点就直接提交了。
但因为要用到一个内部SDK的导出方法，我去翻了一下那个SDK的文档。结果发现，AI调的那个方法根本不存在。它自己编了一个API，而且编得特别像真的。方法名符合命名规范，参数类型都对，连返回值都设计得合理。
如果我不去查那个文档，这段代码会在生产环境上直接报错。
从那天起，每次合并AI生成的代码之前，我都会逐行过一遍。
这不是不信任AI，而是理解了AI的工作方式之后，知道它的盲区在哪里。
AI写的代码有三个最常见的坑。
第一个坑：编造不存在的API。
这事发生的频率比你想象的高得多。AI在训练数据里见过类似的API设计模式，所以它很擅长推测一个方法应该叫什么名字、接受什么参数、返回什么类型。
问题是，推测和事实是两回事。
你让AI写一段调用第三方服务的代码，它可能会用一个看起来非常合理的函数。但这个函数可能根本不存在，或者签名和你以为的不一样。编译器和类型检查查不出来，因为AI连调用的模块路径都给你编好了。
唯一能发现的办法是：你去翻文档，或者运行测试。
第二个坑：不懂业务上下文。
AI不知道你的业务里有什么潜规则。
它不会知道这个字段虽然叫price，但实际上存的是折扣价。它不会知道这个用户的订单不能取消是因为已经发了货。它不会知道这个接口虽然接受DELETE请求，但实际业务上只支持软删除。
这些知识不在代码里，在业务里。AI看不见业务，所以它会写出技术上正确、业务上错误的代码。
第三个坑：自信满满地犯错。
这是最危险的一个。
如果是一个同事不确定，他会问，会在代码里留TODO，会在PR描述里写我不确定这个地方对不对。
AI不会。它会给你一段看起来完全合理的代码，哪怕整个逻辑方向是错的。没有犹豫，没有标记，没有免责声明。
就像一个永远自信的实习生。
认识到这三个坑之后，我总结了一套审查AI代码的方法，分三层。
第一层：审意图。
先别看代码。
先看AI有没有理解需求。打开你写的提示词，问自己一个问题：如果我是AI，看了这个提示词，我会理解成什么？
很多时候你发现，AI确实写错了，但错不在AI，在你的提示词有歧义。你说了按时间范围导出，但没说清楚是下单时间还是付款时间。
这一层能过滤掉至少一半的问题。
第二层：审逻辑。
确认意图对齐之后，再看代码的逻辑路径。
重点关注边界条件。时间范围为空怎么办、数据量超过一万条怎么办、并发导出怎么办。
重点关注异常路径。网络超时怎么办、SDK调用失败怎么办、中间步骤出错了有没有回滚。
AI擅长写快乐路径。但生产环境从来不快乐。
第三层：审细节。
意图对了，逻辑也对了，最后看实现。
API签名对不对、有没有敏感信息被日志输出、性能有没有明显问题。
这一层AI通常做得很好了，但还是要看。因为细节问题虽然不会让功能挂掉，但会让代码变脏。
三层走完，代码就可以放心合并了。
有人可能会问：每一层都自己看，那不比自己写还累？
说实话，刚开始确实慢。但熟练之后你会发现，审代码比写代码轻松。因为你的角色从生产者变成了质量把关者。你不需要从头构思，只需要判断对错。
而且，AI改代码比你快得多。你发现一个问题，告诉AI，它几秒钟就改好了。你只需要做决策，AI做执行。
这就是AI时代程序员的正确姿势。
AI负责快，你负责对。
开头那三条留言，现在可以回答了。
说错觉的那位，三层审完你就知道AI没那么神。
说越活越回去的，审代码不是倒退，是进化。
说刚毕业不好找工作的，这才是新人最好的突破口。
下次AI给你一段漂亮的代码时，别忘了翻一下那个SDK的文档。
