又有人在吹什么 Claude 的 Sonnet 4.5 还是 4.6 的，我没记清，反正就那个意思，一出来我朋友圈全是"震惊体"。要我说，整天震惊来震惊去的人，大概率自己没写过什么正经代码。
但我实话实说，上一个模型用太久了，最近确实感觉有点食之无味。怎么说呢，活还是能干，但就是那种十年老夫老妻的感觉，它张嘴我就知道它要放什么屁，我需求没打完它就已经把答案猜岔了，然后还要花两倍时间给它纠偏。烦。
这不是前几天正好手头一个老改不好的活——我们那个祖传进销存系统，跑批任务隔三差五凌晨三四点死掉，日志翻出来指向一个存储过程，两万行，三层嵌套游标里面还套着动态SQL，是当年从另一个系统迁移过来的，原作者早跑路了，中间经手了多少人谁也说不清。要我说这种代码还能跑在生产上本身就是奇迹，奇迹还三天两头闹脾气。
之前我让老搭档帮我分析日志，每次都是车轱辘话，什么"可能存在死锁风险"——废话，我要你告诉我可能存在死锁？我是来让你告诉我具体在哪个环节锁上的。
这周一凌晨它又挂了，我到了公司对着那坨存储过程发愁。新来的小年轻说你换那个新模型试试呗，我说不换，我那个用顺手了。他说你那个都过时了哥。我当时就想怼他，但转念一想，也是，我天天骂手里的工具不行，但就是不肯换，这不有病嘛。
于是我把那段动态SQL拆出来丢给了新模型，就发了一句：这玩意儿凌晨跑批卡死，日志只有这个错，帮我看看是哪段逻辑的问题。
这要是换以前那个，能回我八百字关于"动态SQL可能存在的安全风险"的废话。这新东西倒好，没跟我废话，直接一行行读，读到第两层的时候标注了一句：这里在循环体里改了Globals表结构，但下一轮循环又按老结构去绑定变量，MySQL 8.0.12以后不能这么玩了，查到这行必崩。
我当时就愣了。这个坑，说实话，当年踩过，有这个印象，但你让我把那行在两千行里翻出来，我没那本事。它给我指出来了，还问了一句：需要我帮你把这个存储过程改成游标循环外先临时表的方式吗？
我那时候已经不知道说什么了。突然就让我想起来一六年那会儿，有一次线上事故查了一天一夜，最后是某运维老大拿来一瓶啤酒，说喝完再试一次，结果酒精一上头思路通了，凌晨四点找到了那个逗号写错的小bug。那时候什么AI，连个智能提示都做不利索。现在好了，别说逗号了，连存储过程里面犄角旮旯的历史遗留问题都能给你揪出来。
说真的，我用AI写代码也有半年了，一直觉得一句话能概括：不过是个聪明点的补全工具。但那天这玩意儿给我把存储过程的逻辑理顺了之后，我盯着它输出那个临时表的方案，从建表到插入到重新关联，每一步都给我标注了为什么不会死锁，我一时……确实说不上来是什么滋味。
倒不是怕失业，我干这么多年，还不至于被个模型吓住。就是觉得，这玩意儿进步也太快了。
不过话说回来，我没全盘换掉。它分析完了我还是自己又过了两遍代码才敢往生产上推。工具嘛，打打下手就行了，真要靠它写存储过程——那我这十二年的活不就白干了。我这个人守旧是守旧，但把活干踏实这条规矩从来没变过。
新工具挺好，我有数。但谁要是让我把核心那块也交给它，那我还是那句——我需要AI？呵呵，我只是让它打打下手。
顺便说一句，那天后来我看了它的计费，一个月的量顶我一顿午饭钱都不到。这我倒真没意见。