认知防线：开发者如何避免被 AI“养废”？

一、真正的退化，从“点采纳”开始

我第一次意识到问题的严重性，不是在写不出代码的时候，而是在一次代码评审会上。

那段缓存逻辑是智能编程工具帮我生成的，本地跑起来没问题，单元测试也过了。评审的同事问了一句：“这个过期时间为什么定 30 分钟，而不是 5 分钟或者 2 小时？”

我张口结舌，答不上来。

那个数字不是我定的，是工具顺手写的。我当时觉得“能跑就行”，连问都没问一句。那一刻我才明白，所谓被 AI 养废，根本不是手生了，而是脑子先交出去了：判断的过程被省掉了，只剩下一个会点“采纳”按钮的人。

这不是个例。当生成一段可运行代码的成本趋近于零时，开发者面临的最大风险不再是“写不出来”，而是“不再思考为什么这样写”。本文想讨论的，正是如何在使用智能编程工具的同时，守住自己的技术判断力。

二、为什么“模糊的想法 + 像样的代码”最危险

智能编程工具最擅长的事，是把一个模糊的想法快速变成一段看着像样的代码。而模糊的想法配上像样的代码，是最危险的组合。

原因在于：代码的“像样”会给人已经完成思考的错觉。变量命名规范、缩进整齐、注释齐全，这些表面特征会让我们下意识地认为逻辑也是完备的。但事实上：

• 边界条件可能从未被考虑；
• 数据来源可能只是工具根据上下文猜测的；
• 异常路径可能只是被 catch 住然后打印日志；
• 那个“顺手写”的常量，可能来自训练数据里的某个常见值，而非你的业务场景。

你省掉的思考不会消失，只会换个时间、以 bug 的形式还回来。 而且往往是在线上环境、在凌晨告警、在评审会上答不出问题的那一刻还回来。

三、四条可落地的自我防线

以下是我给自己定的几条规矩。不算高明，但确实管用。

防线一：动手之前，先自己说清楚

接到一个需求，我会先在纸上——或者在脑子里——把思路过一遍：

1. 这个功能要解决什么问题？
2. 数据从哪来，到哪去？
3. 边界情况有哪些？
4. 失败了怎么办，谁来兜底？

说不清楚，就不急着让工具写。

这一步的价值不在于“比 AI 想得好”，而在于把问题定义权握在自己手里。当你能够用自己的话描述清楚需求和约束时，工具生成的代码才有明确的评判标准；否则你连“它写得对不对”都无从判断，只能凭“跑起来没报错”这种最低标准来验收。

一个实用技巧：把上面四个问题的答案写成三五行注释或文档草稿，再让工具基于这份草稿生成代码。你会发现生成质量明显提升，因为你已经把模糊性消除了大半。

防线二：AI 写的东西，必须能讲出为什么

每一处关键决策，我都要求自己能用自己的话讲一遍：

• 为什么用这个数据结构，而不是另一个？
• 为什么在这里加锁，锁的粒度是否合理？
• 为什么异常要这样处理，是吞掉、重试还是向上抛？
• 为什么这个参数取这个值，它的上下界在哪里？

讲不出来，就两种处理：

• 要么追问，直到工具把理由讲明白、我也真听懂了；
• 要么删掉重写，用自己的实现替代。

这条规矩很费时间，刚开始我也嫌麻烦。但它恰好就是那道防线：你一旦能讲出为什么，代码就重新是你的了。 反之，讲不出理由的代码，本质上是一笔你无法维护的技术债——今天能跑，明天换个场景就不知道该怎么改。

防线三：把 AI 的位置从“代笔”换成“评审”

我现在的做法经常是反过来的：

1. 骨架和核心逻辑自己先写，哪怕写得糙一点；
2. 再让工具来挑毛病、补边界、给另一种实现让我对比；
3. 我拿着它的意见做取舍，而不是拿着它的代码做填空。

这样做的好处很实在：写的时候你在思考，评审的时候你也在思考。 工具的产出变成了你思考的材料，而不是思考的替代品。顺序一换，主动权就回来了。

从工程实践角度看，这其实符合“生成-评审”分离的原则：生成者与评审者角色分开，能有效提高缺陷发现率。当你自己充当生成者、工具充当评审者时，你既保留了架构决策的主导权，又获得了额外的检查视角。

防线四：每周留半天给“断电练习”

关掉代码助手，挑一个小功能或者一次重构，从头手写一遍。

不是为了复古，也不是为了证明自己还能写，而是为了保持一种手感：知道一段代码从空白到跑通中间要趟过哪些坑。

手感这东西，三个月不用就会钝，而钝掉的时候你自己是察觉不到的。察觉到的那天，往往已经是评审会上答不出问题的那天。

断电练习可以这样安排：

• 选一个你熟悉的领域，比如一个简单的数据转换或接口封装；
• 不使用任何自动补全或生成功能，从空文件开始；
• 写完后对比：如果用了工具，它会怎么写？差异在哪里？哪个更好？

这个过程本身就是一次高质量的自我复盘。

四、一个自测小办法：三个问题

下次工具给你一段代码，别急着点采纳，先遮住它，问自己三个问题：

1. 这段代码在解决什么问题？ 如果你说不出来，说明你还没理解需求。
2. 它的关键决策是什么，为什么这么做？ 如果你答不上来，说明判断权已经交出去了。
3. 如果需求变了一点，我该改哪里？ 如果你找不到切入点，说明这段代码对你是黑盒。

三个问题都能顺畅回答，再点采纳。有一个卡壳，就回到防线二：追问或重写。

五、结语：效率的红利，不能以判断力为代价

智能编程工具带来的效率提升是真实的，拒绝使用它并不明智。但效率的红利不能以交出判断力为代价。

真正的专业能力，不在于你能敲出多少行代码，而在于你能否对每一处决策负责。工具可以帮你写，但“为什么这样写”必须由你来回答。把思考留在流程里，把判断握在手中，才不会在某个评审会上，面对一个本该答得出来的问题，张口结舌。