如果不解决“脑子变懒”的问题

现在的编程环境变了，大家都在讨论 AI 辅助编程能提高多少效率，但我最近在复盘自己用 Claude Code 写项目的过程时，反而产生了一种很深的危机感：如果所有的逻辑、架构甚至 Bug 修复都交给 AI，那人类所谓的“编程专业能力”是不是正在加速崩塌？

这种现象在实操中特别明显。以前遇到一个复杂的并发问题，我会习惯性地去翻源码、查底层原理，通过逻辑推演找出那个隐藏的 Race Condition。现在呢？直接把报错丢给 Claude，它会瞬间吐出一堆看起来逻辑自洽的代码，我点一下 Apply，跑通了，任务结束。

这种“反馈回路”极短的开发模式，本质上是在剥夺我们进行深度思考的机会。

这种依赖带来的隐患

• 逻辑黑盒化： 你能写出运行的代码，但你并不真正理解每一行代码为什么在那儿。当 AI 生成的代码逻辑过于复杂时，人类的审查能力（Code Review）其实已经跟不上 AI 的生成速度了。
• 架构能力的退化： 现在的 AI 擅长解决局部问题（Snippet-level），但在处理大规模系统的架构设计、解耦、以及长期的技术债管理时，它给出的方案往往是“当下最优”而非“长期最优”。
• Debug 能力的萎缩： 真正的专家是在解决问题的过程中积累经验的。如果遇到问题第一反应是“问 AI”，那么当 AI 陷入幻觉（Hallucination）或者无法处理边界 case 时，你会发现自己完全失去了从底层逻辑去排查问题的直觉。

我现在尝试的应对策略

为了不让自己沦为 AI 的“代码搬运工”，我最近在调整自己的工作流，强迫自己进行一些“反直觉”的操作：

1. 先写伪代码逻辑，再用 AI 实现：
在让 AI 写具体函数之前，我会先在注释里写清楚我的算法思路。如果 AI 给出的实现和我预想的逻辑路径不一样，我会停下来思考：是我的思路错了，还是 AI 的实现更优雅？而不是直接全盘接受。

2. 强制进行“反向审查”：
拿到 AI 生成的代码后，我会故意问它一个问题：

   # 示例：不仅看它怎么做，还要问它为什么不这么做
   "Why did you choose this specific data structure instead of a hash map here? What are the time complexity implications for our specific scale?"

通过这种追问，把 AI 当作一个陪练，而不是一个单纯的执行工具。

3. 定期脱离 AI 进行“纯手工”重构：
每周我会挑一个核心模块，尝试完全不打开 Copilot 或 Cursor 的自动补全功能，只靠文档和大脑逻辑去重写一遍。这种“肌肉记忆”的训练对维持编程直觉至关重要。

工具的进化不可阻挡，但如果我们的思维停止了演化，那我们最终会被自己亲手创造的工具所取代。