我当时第一反应不是焦虑，是好奇：这小子要是线上出了事故，他排得动吗？

这个问题我想了一周。答案是：AI 就像一个手速极快但不懂业务的实习生——活儿干得快，但判断力这东西，它没有。

而判断力，恰恰是 AI 时代程序员真正的护城河。先看这张图，今天聊的 4 种能力都在里面：

一、为什么 AI 写的代码，总在异常分支上翻车？

先说个真事。

之前让 AI 写一个提现接口，代码写得漂漂亮亮，评审时我问了一个问题："银行接口超时了，这笔钱到底出没出去？"

全场沉默。AI 的代码里，超时直接抛异常，没有任何对账补偿。真上了线，掉一笔单就是客诉，掉十笔就是事故。

AI 写代码有个致命习惯：默认一切 Happy Path。产品说"用户提现要实时到账"，它就给你写个同步调用。它不会追问：量级多大？超时了怎么办？要不要做异步+对账？

▍怎么练这个能力？

很简单，从下一次需求开始：代码不动笔，先花半小时写一份"异常清单"——把所有"如果出问题会怎样"列出来。超时、重试、幂等、降级，一个一个过。

坚持三个月，你会发现自己看需求的角度完全变了。以前看的是"要做什么"，现在看的是"会出什么事"。这个视角切换，AI 学不会。

二、凌晨 3 点的报警电话，AI 能替你接吗？

上个月凌晨两点，订单服务大量超时。我让 AI 帮我看日志，它给了我十几条"可能的原因"，从慢 SQL 到 GC 到网络抖动。

但它看不出"这个慢 SQL 是上周上线的新索引导致的"，因为它不知道上周发生了什么。

线上排查拼的是三样东西：对系统的熟悉度、对业务的理解，还有直觉。直觉这玩意儿，是被几百个深夜电话喂出来的，AI 喂不出来。

说白了，AI 是"知识的搬运工"，而排查是"经验的变现"。知识可以学，经验只能熬。

▍怎么练这个能力？

三步：第一，主动跟一次完整的线上事故，从报警到恢复全程参与，别只当看客；第二，把你排查过的每个问题记下来，形成自己的"排查手册"——下次类似问题，5 分钟定位；第三，学 arthas，它是线上排查的瑞士军刀，不用重启就能看方法入参、耗时、调用链。

而且换个角度想：愿意半夜爬起来救火的人，本身就是稀缺资源。公司可以裁掉写 CRUD 的，但不敢裁半夜能解决问题的人。

三、AI 给的"最优方案"，为什么不能直接用？

"用 Redis 还是本地缓存？"我问过 AI，它给了我一张漂亮的对比表：性能、一致性、运维成本，面面俱到。

但它不知道：我们团队只有三个人，Redis 挂了没人会修。

技术选型从来不是选"最好的"，而是选"最适合当前团队的"。这个判断需要的信息——团队水平、业务阶段、历史包袱——全在 AI 的视野之外。

▍怎么练这个能力？

每次做技术选型，强迫自己写下"为什么没选 B"。不是写给别人看，是写给自己看。三个月后回看，你会发现自己的决策质量在肉眼可见地提升。

另外，多看架构师的决策记录。很多大厂的技术博客会讲"我们为什么从 A 迁移到 B"，重点看"为什么"，不看"怎么做"。做决策的思路，比具体的技术选型值钱 10 倍。

我面试时最爱问："你为什么选这个方案？当时还考虑过什么？"答不上来的，代码写得再漂亮我也不要。因为做过权衡的人，和只会执行的人，是两种程序员。

四、当代码都是 AI 写的，程序员还剩什么价值？

以后大概率是这个分工：AI 先写一版，人来 Review。这意味着看代码的能力，比写代码的能力更重要。

能看出 AI 生成的并发代码里少了 volatile，能看出那个"看起来没问题"的 SQL 在数据量大时会全表扫描，能闻出过度设计的味道——这些靠的是基本功。

讽刺的是，AI 时代反而让基本功更重要了。以前你写错了，测试能测出来；现在 AI 写错了，藏得更深，更需要你一眼看穿。

▍怎么练这个能力？

每天花 20 分钟，专门 Review AI 生成的代码——不是看它写得对不对，而是找"它哪里可能错"。并发、边界条件、异常处理，这三个地方是 AI 的重灾区。

另外，重读《Effective Java》。以前读是"学怎么写"，现在读是"学怎么审"。同一本书，AI 时代读出了第二层意思。

AI 吃掉的是"把需求翻译成代码"的体力活，吃不掉的是"判断什么代码是对的"的脑力活。

它越能干，判断力就越值钱。因为当所有人都能 10 倍速产出代码时——

稀缺的不再是代码，而是知道什么代码是对的人。

以上是我的个人观点，难免有偏颇，欢迎在评论区交流。