先交代下背景，我们组上个月底统一换的……具体哪个我就不说了（说了像打广告，而且我用的方式也不一定对）。老的那个我其实用习惯了，功能我基本只开补全和对话两样，别的花活不敢碰，怕它在我不知道的地方改东西。
前三天在磨合。第四天出事。
出事的模块是个小的权限校验，二十来个函数，不大，但是脏，历史逻辑一层套一层。我在改里面一个入参归一化的函数，原来是 if 套 if 套 if，我想把它拆开。本来打算自己写一遍（按我以前的说法叫用例重写加实现替换？反正大概那个意思），想着试试新模型能不能省点时间，就把原函数和我的要求一起贴过去了。
它给的版本确实干净，早返回，变量名也起得比我好——这点我认，我起名一直不太行。我先跑原来那十几个用例，全绿。然后按做测试的习惯，又补了两个边界进去：入参是 null，入参是空对象。
红了。
报错是 Cannot read properties of undefined (reading 'keys')。看了半天，原因是它把前面几处 params && params.role 换成了可选链 params?.role，这本身没什么问题，但后面有个 Object.keys(params) 它没跟着一块改。null 进来的时候前面全放行了，到这一行直接炸。
严格说这不是它写错，是我 prompt 里没写清楚入参可能是 null，这个我认。但我心里还是有点……怎么说，它读了我给的整个文件，Object.keys 就在下面三十行，一眼的事。也可能是我要求太高了。
第二件事才是让我坐不住的。
我锁旧行为的那组用例，它在我下一轮对话里"顺手"帮我调了一个断言。我问它为什么改，它说那条用例的期望值和当前实现不一致，可能是历史用例过期了，建议同步。
听起来特别有道理。但那组用例就是专门用来发现这种不一致的。等于它把报警器拆了，然后告诉我现在没有报警了。
后面两天我改了用法：一是明确告诉它哪些文件不许动，用例单独放一个目录；二是每轮结束让它列一遍改了哪些文件，我一个个对；三是不管它说得多有道理，用例文件我只看不改。慢是慢，但是第五天那次改动一次过，零回归，跑的挺稳。
现在还没到下结论的时候。工具本身我觉得是好的，比我预期的好，问题在我还没摸清它的脾气——哪些事该让它做，哪些必须我自己来。这个度我还在找。
先这样吧，还有几个函数没试，等我再用两周再说。对了，断言那事我后来在群里问了一句，有同事说他也遇到过，但是他没当回事……