先交代一下，我是被我们组长那句"这模型读代码比你勤快"勾过去的，六天了，感受说不上好坏。它确实勤快，勤快到有点烦。
那天下午我是真被一个 bug 卡住了，往后端传数组，后端是 Java 的老接口，字段要 snake_case，我前端写的是 camelCase，十几处，改得头晕。以前那个 AI 遇到这种问题会先问你用什么框架再给方案，这个新模型上来就给我一篇长文，说你要不要再考虑换一个 data structure？然后……然后它就给了我一个在我看来天书的解法，让我 wrap 一下 fetch。
wrap 我懂，包装嘛。它给的代码里有一个词我不认识：transducers。（拼了三次，最后是靠粘贴进词典才查到的。）直译过来是转换器？不对，那是 transformer。du 了一下，好像是函数式编程里的一种 tool，让数据在一个"带状态的过成"里换手。这词我是第一次见，估计以后还得查。重点是它帮我写的那个 wrapper 我今天早上读了一遍：它在我的请求里加了一层代理，把递归的属性变成 snake_case。用是能用，但我看了看那代码，越看越 not comfortable（这里应该用 uncomfortable 吧，不管了）。它把我原来的代码"重构"了。我明明只要传参的时候改个 key 名，它把我整个请求层都 re-architecture 了。
当时我对着屏幕说了句"谢谢你喔"，然后把它那方案里面 strip 掉，只留下它那个把 camelCase 转成 snake_case 的函数，自己写了五行为循环去套。代码丑是丑，丑得像我自己写的。
后来我又问它一个更蠢的问题：为什么我后端返回时间它总是显示成什么 9/4/2026, 3:30:00 PM 这种格式，明明后端 json 里是 2026-08-31 这种字符串。它说可能是浏览器解析了 date 字段。我贴了代码给它看，它说因为你用了 new Date(string)——这是原话——不对，不是说这个不对，意思是浏览器自动把它当成 UTC 然后转本地时区了。是时区的问题，gmt 的问题。我就切了英文又问一遍，想对照着看它有没有忽悠我，发现英文版答案里给了个词比中文版多一句话：If you only need to display the raw value, skip the Date constructor entirely. 中文版根本没提这个，只说"可以考虑用 dayjs"。
所以又回到老结论了，AI 是恩人，但不能全信。六天用下来我最大感受是它比上一个更适合写长代码，但我控制不住它。以前那一个是我不喂它就不动，这个是我不说"不要大改"它就把我整个项目格式都给你换一遍，还不知道是 feature 还是 bug。
今日单词：transducers——查了三遍还是拼不利索，但好歹知道它大概是个什么东西了。明天我准备狠狠地在 prompt 里写 DO NOT REFACTOR。