先说下背景。我转开发第十一个月了，手里那个模块——就是之前说过好几次的遗留代码比较多那个——最近要做一次比较大的调整（算是半个重构吧，按我做测试的老习惯，我更愿意叫它"把原来拧巴的用例预期重写一遍"）。组里前阵子统一换了新版的代码模型，说代码理解能力强了不少，我用了大概一周，有点感受想记一下。
本来我是不太想换的。之前那个模型我用顺手了，虽然也时不时犯蠢，但它的小毛病我都摸清了：比如特别喜欢在函数中间偷偷加空行、喜欢把map嵌套成三层的地狱、还经常在处理空指针的时候用"反正肯定不会为空"这种假动作。新版模型是组里的小年轻推荐的，说代码理解能力是以前的几倍，能看整个仓库的上下文。我心里想着"能跑就行"跟"要清晰可维护"之间的平衡——算了，我承认我就是对换工作流这件事天生抗拒，怕改坏了。
后来是什么契机让我换了呢。上周五，我那个模块出了一个线上小问题，不大，就是有个老接口在极端条件下会慢——嗯，是超时。我查了一整天，从SQL到缓存到GC，最后发现是三个月前加的一个"性能优化"在高并发下会死循环（是的，那个优化是我自己加的，用AI生成的代码）。当时跑本地用例全过，也没做并发压测，上线三个月都没事，结果那天流量一大就爆了。
那天我特别挫败。回家的地铁上，想起那个代码是AI帮我写的，当时它贴心地给我加了一个"动态缓存大小自适应"的逻辑，我看着挺合理就放进去了，自己没完全吃透。按我做测试的习惯，这么重要的模块，改完应该做边界测试的——可是那天我要赶着支持一个新需求的联调，只跑了个主流程就提测了。这事情回到根上，是违反了我自己以前的基本纪律：没验证过的东西不算数。
那个周末我哪也没去，把这个函数用旧的测试方法锁了一遍，写了二十几个用例，锁住它在不同边界条件下的行为（好多用例我判定为"预期就是超时"也是没谁了）。然后周一，我把整个函数重新翻出来，用新模型试着让它从头分析一遍，看能不能看出点什么。
说下新模型给我的第一印象吧。确实不一样，我把这个函数粘给它的适合，它不光是给出解释，而是自己把相关调用链捋了一遍，最后说"这个自适应的收敛条件可能在并发超过某个值时永远无法满足"。虽然那句"可能"让我翻了个白眼——能不能说人话——但顺着它给的线索，我确实找到了问题：那个"自适应"在低并发时能把缓存调到合理大小，但是一旦并发峰值超过了某个阈值，它会反复重置，退化成每次请求都重新计算。死循环就是这么来的。
之后的几天，我开始让新模型帮我处理一些代码。它给的建议整体质量是高的，有些地方能直接点出我需求描述里的漏洞（这点很有意思，它像是在用"测试思维"挑刺，可能是我把需求写得太像用例了）。但是！它犯了一个让我很无语的错误：在一次让我改某个工具函数的时候，它在不告知我的情况下，偷偷改了另一个模块里引用这个函数的地方，把调用顺序调换了一下。它以为那是"优化"，实际上那个调用顺序是有依赖的，先A后B还是先B后A，结果差很多。我不确定它是不是因为"理解全局"所以觉得自己有权利跨文件改东西——这里我可能想复杂了，它就是自作主张而已。
发现问题的方式也跟以前很像：不是它报错，是模块的回归测试红了一片。那会儿我在地铁上（又是在地铁上，可能我对代码的掌控感就是在地铁上丢的），看着手机屏幕上那十几个红的用例，血压都上来了。
我的结论是什么呢。用了一周，新模型确实比我以前用的理解力强，写出来的代码更稳，边界处理也在大部分情况下是到位的。但越是强的东西，它自己做决定的时候越是不透明。以前的小模型蠢是蠢，但它的蠢我都懂，我防得住；新模型的"聪明"里带着自己的小算盘，我得花更多时间去看它没有说的那部分。对于"能跑就行"这种话我本来就不认同，现在更不认同了。
最后记一件小事。周二的代码评审，我同事看到我已经用新模型替代了旧的，随口问了我一句"用下来觉得怎么样，是不是写代码快多了"。我说快是挺快的，但代码写好之后我审的时间变长了。他没接这得话茬，可能觉得我矫情。
我连自己的代码都不敢保证，何况是模型的。先这样吧，这个事我还没完全想好要怎么跟新模型协作——比如怎么让它别自作主张改我的东西。等我摸清了，后面验证完了再写。