夜雨聆风去年这个时候，我刚开始用AI编程助手。头两周简直像开了挂——以前要翻半天文档的正则表达式，现在描述一下需求就出来了；写了一百遍的CRUD接口，三秒钟生成，连异常处理都帮你补上了。
然后我翻车了。
一个很隐蔽的空指针问题，AI生成的代码里漏了一层判空。测试环境一切正常，上了生产之后，在某个特定数据组合下炸了。我花了一整天排查，最后发现就是那一行缺失的判空。
那天之后我开始认真想一个问题：大家都在卷提示词技巧，什么"角色设定法"、"思维链"、"Few-shot"，但用了一年AI编程工具，我觉得真正决定代码质量的，根本不是提示词写得多好。
三个阶段，三种心态
回头看，我用AI编程工具经历了三个阶段，每个阶段踩的坑完全不一样。
阶段一：兴奋期（第1-2个月）
什么都让AI写。函数、注释、测试用例、甚至README。效率确实起飞了，日均代码量翻了快两倍。但这个阶段有个隐藏问题——我在变懒。AI生成的代码，我扫一眼"看起来对"就提交了，根本没仔细读。
阶段二：翻车期（第3-5个月）
线上开始出问题。不是那种一跑就崩的明显bug，而是边界条件、并发场景、数据异常时才暴露的隐蔽问题。有一次AI帮我重构了一个支付模块，逻辑上"看起来更优雅"，但实际上把一个同步操作改成了异步，导致订单状态在特定时序下出现不一致。
这个阶段我开始怀疑：AI到底是在帮我，还是在给我埋雷？
阶段三：磨合期（第6个月至今）
慢慢摸索出了一套跟AI协作的节奏。核心转变是：从"让AI写代码"变成"让AI帮我写代码，但每个字我都得看懂"。听起来像废话，但真正做到的人不多。
比提示词更重要的三件事
第一件：代码审查能力
AI生成的代码有一个特点：它"看起来"总是对的。变量命名规范，逻辑结构清晰，注释也齐全。但这种"看起来对"的表象，恰恰是最危险的。
我现在养成了一个习惯：AI生成的代码，我会逐行读一遍，问自己三个问题——
这行代码在什么情况下会出问题？ 如果输入是null、空字符串、超长字符串，会怎样？ 这段逻辑有没有副作用？会不会影响其他模块？
说白了就是把AI当实习生，不当外包。实习生的代码你是要Review的，你不能因为他写得快就不看了。
我发现一个反直觉的现象：用AI编程之后，我的Code Review能力反而变强了。因为我每天要审查的代码量变大了，练出来的。
第二件：架构判断力
AI擅长写函数，不擅长设计系统。
这句话听起来像结论，但我是踩了坑才真正理解的。有一次我让AI帮我设计一个缓存层，它给了我一套看起来很完整的方案——读缓存、写缓存、过期策略都有。但完全没有考虑缓存一致性、缓存穿透、缓存雪崩这些问题。
不是AI不懂这些概念，你问它"什么是缓存雪崩"，它答得比谁都好。问题在于，它在写代码的时候不会主动帮你想到这些。它默认你要的是"能跑的代码"，而不是"能扛住生产流量的代码"。
所以架构层面的决策——模块怎么拆、数据怎么流、哪些地方需要容错——这些还是得你自己拿主意。AI可以帮你实现方案，但方案本身得是你的。
第三件：测试意识
AI生成的代码有个通病：正常路径写得很好，边界情况经常漏。
比如让AI写一个解析JSON的函数，正常数据没问题。但如果JSON里某个字段缺失、类型不对、或者嵌套层级超出预期，AI生成的代码大概率会直接崩。它不会主动帮你加防御性编程，除非你在提示词里明确要求。
所以我现在的工作流是：
让AI生成核心逻辑 - 自己补边界测试用例
（null、空、超长、类型错误、并发） 跑一遍测试，让AI修复失败的case 再人工Review一遍修复
第三步特别关键——让AI修bug可以，但你得确认它的修复没有引入新问题。AI修bug的时候有个倾向：它会"修好当前这个case"，但可能在别的地方挖个新坑。
AI擅长什么，不擅长什么
用了一年，我大概摸清了AI编程工具的能力边界：
放心交给AI的
- 样板代码
：CRUD、DTO、序列化、配置文件，这类重复性高的代码AI写得又快又准 - 正则表达式
：以前我最头疼的，现在描述需求就行 - SQL查询
：复杂的join和聚合，AI写得比我手写快 - 注释和文档
：给代码生成注释，质量不错（但你要检查技术准确性） - 语言转换
：Python转Go、JS转TS，这类翻译工作AI很擅长
必须自己把关的
- 架构设计
：系统拆分、数据流设计、技术选型 - 性能优化
：AI不太会主动考虑时间复杂度和空间复杂度 - 安全相关
：鉴权、加密、防注入，必须人工审查 - 并发处理
：锁、竞态条件、死锁，AI经常遗漏 - 边界处理
：null检查、异常输入、超长数据
三条实操原则
最后分享我总结的三条原则，不一定对，但对我有用：
1. 小粒度提交
不要让AI一次生成几百行代码。拆成小函数、小模块，每次生成几十行，review完再继续。大段代码你根本看不过来，小段代码才容易发现问题。
2. 关键路径自己写
支付、鉴权、核心业务逻辑，这些地方我不用AI。不是AI写不好，而是这些地方出问题的代价太高，我宁可慢一点也要完全掌控。AI用来写周边——数据转换、格式化、工具函数。
3. 永远跑测试
AI生成的代码，不管"看起来多对"，必须过测试。而且测试用例要你自己设计，不能让AI自己写测试自己跑——那样它只会测自己想到的场景，漏掉的就是它没想到的。
· · ·
用了一年AI编程工具，我最大的感受是：它没有让我变成更厉害的程序员，但它逼我变成了更认真的程序员。
以前手写代码的时候，逻辑都在脑子里，写出来基本就是对的。现在AI帮你写，逻辑不在你脑子里了，你反而得更仔细地去理解每一行——因为你没写过它，你不知道它藏着什么。
所以如果有人问我，AI编程时代程序员最该练什么？我的回答不是提示词工程，而是读代码的能力。
写代码的机会会越来越少，但读懂别人（包括AI）写的代码，判断它对不对、好不好、安不安全——这个能力，只会越来越值钱。
