AI 写代码八个月后，我开始怀疑"熟练"这个词

八月的最后一个周五，凌晨一点半，我还坐在屏幕前。Cursor 刚给我生成了一段处理订单状态的函数，逻辑完整，注释得体，甚至给边缘情况加了判断。搁半年前，我大概会毫不犹豫地点下”Accept All”。但那天夜里，我把那段代码从头到尾看了三遍，才按下合并。

不是我不信任它了。恰恰相反，是我太知道它有多”像”会写代码的人。

第一次认真用 AI 写代码，是去年冬天。老项目里有一个两百行的回调地狱，我想重构。打开 Cursor，敲下”把这段改成 async/await”，三秒钟后，代码焕然一新。那一刻我感觉自己像个指挥家，AI 是乐团，挥挥手就能出旋律。

我一度以为，这就是未来的工作方式。熟练的程序员，等于会用提示词的程序员。

这种想法大概持续了一个月。直到有天早上，线上告警。用户反馈说，部分订单状态卡在”处理中”。我回滚到重构前的版本，问题消失。再仔细看 AI 生成的代码，它确实把回调改成了 async/await，但它悄悄把两个原本串行的校验步骤合并了。在大部分情况下，这没问题。但有一种老客户端会在同一时刻触发两次请求，那个合并就出了问题。

代码看起来是对的。甚至看起来比我的版本更好。但它在没有理解业务语义的情况下，做了一个”合理”的优化。

那次我修了三小时。不是因为代码复杂，是因为我花了很长时间才相信：问题出在那段”完美”的代码上。

后来我慢慢养成了一些别扭的习惯。让 AI 生成之前，先自己把需求写成一段简短的 spec，把边界条件和失败场景列清楚。有人觉得这太慢了，直接对话不是更高效吗？我试过很多次，结果通常是：前三次生成都挺惊艳，第四次开始跑偏，第五次我发现它在用上一版的错误假设继续编。

这个循环我写过一篇更具体的记录：写好需求规格，比写好提示词更重要。核心观点现在也没变：AI 不会替你思考，它只会替你打字。你打的主意越清楚，它打出来的字越有用。

但让我改变的，不是某一次踩坑，而是我开始观察自己”依赖”和”不信任”之间的摇摆。

有段时间我追求极致的 AI 辅助。能让它写的绝对不自己写。结果遇到一个问题：我明明知道某个函数应该怎么设计，但我的手先于大脑，把光标移到了 AI 的输入框里。等它给出答案，我又陷入选择困难——这个方案好，还是那个好？其实两个都行，但我已经懒得自己判断了。

熟练，原来不是写得快。

我想起以前带过一个实习生。他敲代码很慢，但每行都清楚自己在做什么。我问他怎么不快一点，他说：”我现在慢，是为了以后不返工。”当时我觉得这是套话。现在发现，这句话在 AI 时代反而更值钱。因为 AI 让”快”变得廉价，”清楚”反而稀缺。

上个月我做了一个实验。同一个功能，用两种方式实现：一天交给 AI 全程生成，另一天自己先画流程图、写 spec，再让 AI 填骨架。结果前者两小时完成，调试花了六小时；后者四小时完成，几乎没调试。

这个对比当然不够严谨，样本量只有一个，不能当成结论。但它让我确认了一件事：用 AI 写代码的熟练度，不是指你能多快地拿到结果，而是指你多快地判断这个结果可不可靠。

我开始重新理解”熟练”这个词。以前觉得熟练是肌肉记忆，是看到问题就知道怎么写。现在觉得，熟练更像是一种节奏感：知道什么地方该让 AI 飞，什么地方该自己踩刹车。

就比如 review AI 生成的代码。新手容易犯两种错误：一种是全盘接受，因为看不懂也不敢改；另一种是全盘否定，觉得 AI 写的一定有坑。花足够时间 review 过几百次之后，你会形成一种直觉：哪些地方是机械替换，安全；哪些是业务逻辑，要重点看；哪些注释是 AI 自己编的，不能信。

这种直觉没法通过看教程获得。它来自你亲自踩过的坑，来自你凌晨一点还在纠结要不要合并的那段代码。

昨晚我又遇到一段 AI 生成的代码。它用了一个我没见过的库函数，语法正确，但语义微妙。我盯着它看了五分钟，然后去翻了官方文档。原来那个函数在最新版本里已经标记为 deprecated，只是 AI 的训练数据还没更新到那一版。

我把它改了，没有让 AI 重新生成。改完提交，合上电脑。

窗外天还没亮。我突然觉得，这可能就是我现在理解的”熟练”：不是我知道所有答案，而是我愿意为那些看起来对的答案，多花一点时间确认。