AI写代码越顺手，工程师的判断力越容易退化

一个 pull request 里堆着上千行改动，评审人从上往下扫了一遍，点了通过。事后有人问起其中某个分支为什么这么写，提交者答不上来。他知道那是 AI 生成的，也知道测试是绿的，但再往下追问，就没有了。

这样的场景正在变多。问题不在 AI 生成的代码本身，而在工作流里少掉的那一步。输入提示词，接受结果，继续下一个任务——审查被跳过了。每一次改动都小到不像值得担心的事，所以没人担心。但这个过程会被重复成百上千次，小改动会叠加。等到某一天打开编辑器，面对空白文件写不出第一行，才意识到变化早就发生了。

AI 写出来的代码有一种特别的迷惑性。它格式整齐、命名规范、结构看上去合理，界面跑起来也对，连测试都能通过——而测试往往也是它一并生成的。一切都显得顺理成章，于是“看起来没问题”就成了放行的理由。问题在于，代码正确与否从来不靠外观判断。整齐的代码可以藏着完全错误的假设，通过的测试可以只是在验证一个错误的前提。

技能退化不是软件行业独有的现象。任何一种长期不用的能力都会衰减，这不需要额外的理论解释。区别在于，向别人口述该怎么做，和亲手把事情做一遍，是两种不同的活动。亲手做的时候，你会被迫撞上边界条件，会开始在意交互上的细节，会判断哪些测试真正有意义，会权衡哪段代码更值得保护。这些东西没办法靠口述获得，它们只在动手的过程中出现。

人手写的代码当然不完美。多数人不是天赋型选手，代码里带着各种人为错误。但恰恰是这一点让代码有价值：它背后有人。有人做出了决定，有人能承担后果，有人脑子里装着上下文。出问题的时候，这个人是从自己搭的地基上往下查，而不是从零开始猜。挣扎、做出错误假设、最后找到正确解法，这一整套过程才是理解形成的地方。下次再碰到同类问题，他大概率能自己解决，效率反而更高。

信任的传递链条更麻烦。一个未经验证的改动被推上去，初级工程师相信 AI，资深工程师相信初级工程师，代码就这么一路进到生产环境。这不是单纯的认知退化，还制造出一种虚假的可靠感。速度从来不是衡量代码质量的好指标。代码库一直是脆弱的，一处错误实现能牵出一连串问题。而当一次改动大到需要读上千行时，评审人的注意力会失效：他会跳读、略读，甚至再叠一层 AI 评审工具，把不确定性又加上一层。

更合理的用法是把 AI 放在补充的位置，而不是替代的位置。先自己形成判断，再让它来暴露你的盲区：提问、质疑、验证，三件事同时做。有工程师提到过，AI 会给出已经废弃的写法，如果事先没查过官方文档，这类错误很难被发现。而当你指出它的错误时，它最常见的回应是“你说得完全正确”。这种顺从说明不了它可靠，只能说明它在顺着你说。对一个自己不了解的领域，你几乎没有能力判断它给的东西对不对——这一点在输入提示词之前就已经注定了。

对抗退化需要主动给大脑出题。一种做法是每天解决一个小的编程问题，同时录制屏幕并逐步讲出自己的思路，像在教别人一样。回看录像时，卡住的地方、解释含糊的地方会非常明显。这类记录的价值在于它是可比较的证据，而不是模糊的自我感觉。方法因人而异，核心是让难度停在一个刚好让大脑吃力的位置，并持续一段时间。

纪律这件事很难外包。可以试着从具体动作开始：提交之前自己完整读一遍改动，确认能解释每一处为什么存在，确认被问到时能立刻答上“为什么”。不必做到完美，但改动必须是自己的，出了问题也得自己接得住。这一步做到位，讨论才有发生的基础，上下文才会在团队里自然流动。

AI 会放大使用者的习惯。习惯好，它放大效率；习惯差，它放大混乱。它值得用，前提是别让它替你做决定。自己动手写一段不看提示、不复制粘贴的代码，看看现在还能做到什么程度，这个答案往往比想象中更有信息量。