先说清楚，这篇不推荐任何工具，就是这周挑战的题目戳到我了，记录一下。
这事得从一段 SQL 说起。去年冬天接了个外包转私活的单子，客户是搞社区团购的小老板，后台自动结算老卡，一到晚上八点高峰就卡死。我打开服务器一看，好家伙，一段报表查询用 FOR XML PATH 拼字符串当聚合用，里面套了五层子查询，全表扫完还要对每行跑一遍递归。跑一次一分多钟，期间整个库锁死，后面所有订单请求全堵着。客户说之前有个外包帮他写的，后来那个人跑路了。我瞅了一眼那段代码的缩进，觉得大概能联想到那个人为什么要跑路。
这段 SQL 一共快两百行，超出对话窗口，我拆成三段往里贴，贴的时候还顺手把里面几个中文注释改成了英文——现在想想也不知道提防谁呢。贴完附上执行计划截图，又加了一句「目标是让它在一秒内出来」。AI 回了很长一段，先是很客气地说这个查询逻辑有些复杂，建议先开参数嗅探——说句实话，那会儿我连参数嗅探这四个字都懒得拆分，我就想让它把查询重写了。结果它重写出来的版本，扫描次数是少了，但用的全是我没见过名字的索引提示，那台老服务器上的 MySQL 版本压根不认。
第一轮就这么翻车了。我盯着它的输出想砸键盘，冷静下来之后还是自己动手。把那段查询摊开，在纸上画，从凌晨一点画到三点。画到第二遍才看明白，业务其实特别简单——就是统计每天缺货的品类数、退款单数，外加一个累计缺货天数。所谓最复杂的第五层子查询，根本是在给一个十年前遗留的脏数据字段擦屁股，数据格式得先拼个特殊前缀才能对得上。烂代码的烂，有一半是烂在它去迁就一个早该被修掉的烂数据。
我把这个业务逻辑链整个拆掉，手动写了一个四十几行的新查询。写完之后在本地跑，从八十一秒掉到两秒。说实话，那一瞬间我指尖都是麻的，截图发给客户群里之后我又后悔了——这动作我太熟了，这不就是我在卖课那年最爱干的，先甩一个「看！效果立竿见影」的截图，然后下面跟个报名入口。打住。
回头说那位写原始 SQL 的兄弟，我翻了系统日志，看到他最后一次提交是在春节前。他大概率也没想坑谁，就是赶工，写的时候自己也觉得这是对的。AI 重写代码这种东西，你让它重写一段错的，它往往能在错误的骨架上给出一个更精美的错。真正把问题解决的，是我在凌晨三点看懂那段业务逻辑的那一刻。
最后这条查询上线一周了，没崩过。客户说，你们玩技术的真神奇，这都能救回来。我没接话。因为只有我知道，昨天我翻 git 历史的时候，在那个跑路的人提交的 message 里看到一句话：「这逻辑至少能撑到明年。」他不知道明年这个时候，有人坐在他的代码前面花了两个晚上才看懂他在想什么。
写代码这事儿，逃不掉的。就说到这。
