夜雨聆风事情是这样的。
上周三凌晨三点，我被电话叫醒。线上有个服务，用户下单后库存扣减正常，但订单状态一直卡在「处理中」，后台日志疯狂报错。
我当时就一个反应，卧槽。
爬起来打开电脑，看了一眼监控面板，错误率已经从0.3%飙到了12%。凌晨三点的脑子跟浆糊一样，我盯着那段代码看了五分钟，愣是没看出问题在哪。这代码是我自己写的，两个月前上线的，跑得好好的，今天突然炸了。
然后我做了一件事。
我把报错日志、相关的三个Java文件、加上数据库的慢查询日志，一股脑全扔给了Claude。
三分钟。
它给我的回复是，你这个库存扣减用的是乐观锁，但在高并发场景下，CAS重试次数用完了就会抛异常，而你的异常处理只catch了通用Exception，没有单独处理乐观锁失败的情况。所以订单状态卡住了，库存扣了但订单没推进。
我当时就愣住了。
不是因为它说得对，而是因为它说得太快了。我对着屏幕发了大概十秒钟的呆，然后回去翻那段代码，果然是这样。CAS重试那里我写了retryTimes = 3，catch块里只有一个e.printStackTrace()，压根没处理重试失败的回滚逻辑。
这个问题我自己排查可能要半小时到一小时，凌晨三点的脑子搞不好要更久。AI用了三分钟。
然后它给了一个修复方案。
方案本身没什么问题，加一个乐观锁失败的自定义异常，catch住之后做回滚操作，同时加一个降级策略，如果重试三次还是失败，就走同步扣减。
但让我陷入沉思的不是方案本身。
而是它说了一句，建议同时检查其他使用乐观锁的地方，这个项目的异常处理模式可能存在系统性的遗漏。
我顺着这个思路扫了一遍整个项目，发现有十七处类似的写法。十七处。其中九处是关键链路。
你知道那一刻是什么感觉吗？
像是你以为自己家打扫得很干净，结果有人拿着紫外线灯照了一遍，到处都是你看不见的污渍。
那天晚上修完bug已经快五点了。我躺在床上，翻来覆去睡不着。脑子里一直在转一个问题，我写了两年的代码，那些我以为没问题的地方，到底还有多少是我看不到的问题？
后来我跟一个做了十年Java的老哥聊起这件事。他听完说了一句话，让我印象特别深。
「你知道老司机和新手的区别在哪吗？新手写完代码觉得没问题，老司机写完代码知道哪里可能有问题。但现在AI比老司机还多知道一层，它知道你不知道你不知道的地方。」
这话有点绕，但仔细想想，就是这么回事。
过去这半年，我开始养成一个习惯。写完代码之后，不是先跑单元测试，而是先让AI review一遍。不是替代我自己的review，而是在我review之前先让它扫一遍。
说实话，刚开始我心里是有点抗拒的。写了这么多年代码，自己的代码还要让一个机器来检查，总觉得哪里不对劲。就像一个做了十年菜的厨师，突然有人说「来，让这个机器人先尝尝你做的菜」。你多少会觉得不太舒服。
但用了一段时间之后，我发现一件事。
AI review跟人review最大的区别不在于谁更准，而在于AI不会不好意思。
你让同事review代码，有些小问题他可能就放过了。你写的那个工具类有点笨重，他不好意思说。你的命名不太规范，他觉得「算了不影响功能」。你的异常处理过于粗糙，他想着「提醒一下就行了」。
AI不一样。它没有社交压力。它会把每个它觉得有问题的地方都指出来，不管你觉得舒不舒服。
当然，它指出来的不一定都对。有时候它会建议你用一个过于复杂的方案去解决一个很小的问题，有时候它会忽略业务上下文给出不切实际的建议。所以我说的不是让AI替代人review，而是在人review之前加一道AI的预审。
就像你考试交卷之前，先让一个不知疲倦的朋友帮你检查一遍。他可能不懂你的解题思路，但他能帮你看到那些低级错误。
回到凌晨三点那个晚上。
后来我把那十七处全部修了。花了两天时间。修的过程中我发现，那些代码确实是我自己写的，而且写的时候我觉得没问题。但问题是，我在写的时候，我的注意力全在业务逻辑上，「怎么让这个流程跑通」占了我99%的脑子，剩下1%分给了异常处理。
这1%，就是凌晨三点把你叫起来的那个东西。
有个东西叫海因里希法则，工业安全领域的。大概意思是，每一起严重事故背后，有29起轻微事故和300起未遂事故。代码世界也一样。你看到的那一个线上bug，背后是二十九个你自己没注意到的隐患，和三百个碰巧没出事的隐患。
以前这三百个隐患，要么靠经验老道的同事帮你发现，要么就只能等它某天自己炸出来。
现在多了一个选项。
有人可能会说，你这不是过度依赖AI吗？万一哪天AI给你指了一个错误的方向，你不就踩坑了吗？
坦率的讲，这种担忧完全合理。我自己也被AI坑过。有一次它建议我把一个同步调用改成异步，说得头头是道，我改了之后确实性能提升了，但第二天发现上游有个地方依赖了这个同步返回值，整条链路直接断了。
所以我的做法是，让AI当你的第一个审阅者，但不要让它当你的最后一个决策者。它提出来的每一条建议，你都要自己判断。你不懂它为什么这么建议的时候，就问它。问完还是不懂的时候，就不改。
你想想看，这跟我们当年刚入行的时候其实是一样的。老师傅跟你说「这个地方要这样写」，你不懂就问，问完还是不懂就先按自己的写。只不过现在老师傅换成了AI，而且这个老师傅不会嫌你烦，凌晨三点也能秒回你。
前几天我把这个经历发到技术群里，有个朋友回了一句话我觉得说得特别好。
「AI不会取代程序员，但会用AI的程序员，会取代不会用AI的程序员。」
这话你可能听了一百遍了。但凌晨三点被电话叫醒，看着AI三分钟找到你自己半小时都找不到的bug的时候，你对这句话的理解会跟之前完全不一样。
不是因为它多厉害，而是因为你终于切身体会到了，你的注意力应该放在哪里。
你的时间和精力是有限的。以前你分给review和排查的时间，现在可以让AI先筛一遍，你把精力集中在它筛出来的那些真正需要你判断的地方。这不是偷懒，这是资源的重新分配。
就像彼得·德鲁克说的，效率是把事情做对，效能是做对的事情。AI帮你提高效率，但做对的事情，还是得你自己来。
凌晨五点，bug修完了，天也快亮了。我关上电脑的时候看了一眼窗外，小区里只有几盏路灯还亮着。
说实话，那天晚上我心里是有感激的。不是对AI感激，是对这个时代感激。你想想十年前的程序员，凌晨三点被叫起来排查bug，靠的就是自己的一双眼睛和一堆日志。现在至少有人能帮你分担一部分了。
当然了，也有人说，十年前的代码没这么复杂，bug也没这么多。
这倒也是。
