AI写完代码你却越来越不会写了:这个Claude和Codex技能想把脑子救回来

AI 编程最危险的副作用，不是它写错代码。

写错了还能改，还能测，还能回滚。真正麻烦的是另一种情况：项目确实在往前跑，代码也能合并，功能看起来做出来了，但你对系统的理解越来越薄。

你知道按钮点哪里，知道让 Agent 改哪个文件，知道怎么描述需求。

可一旦关掉 AI，脑子里空了一块。

这不是危言耸听。现在越来越多开发者已经开始遇到这种感觉：AI 让产出变快了，但主动生成、调试直觉、架构记忆和代码路径感被慢慢掏空。

最近有一个面向 Claude Code 和 Codex 的开源技能，思路挺有意思。它没有试图让 AI 再快一点，而是反过来，在 AI 写完重要代码之后，提醒你做 10 到 15 分钟的学习练习。

说白了，它想把“人该练的那部分”从 AI 手里抢回来。

AI 写代码时，最容易制造一种假象：顺滑。

需求说清楚，Agent 开始改文件，测试跑过，diff 看起来也合理。你扫一眼，觉得“懂了”，然后合并。

问题就在这个“懂了”。

很多时候你只是识别出了熟悉的形状，并没有真正把逻辑装进自己的脑子。等下次要你独立解释为什么这么拆模块、为什么这个 schema 这么设计、为什么边界条件放这里，你会突然发现自己只记得结果，不记得推理。

学习科学里有个很扎心的概念：流畅性错觉。

东西越容易读、越容易获得，人越容易高估自己掌握了它。AI 生成的代码整洁、完整、像答案，这种错觉会被放大。

AI 编程对学习的冲击，大概可以拆成这几类：

这些问题不是“用 AI 就一定会废掉”。真正的问题是：如果工作流只奖励速度，不给学习留位置，能力退化就会悄悄发生。

这个技能的名字可以直译成“学习机会”。

它的设计很克制：不是每次改代码都打断你，而是在完成比较重要的工程动作之后，提供一个可选的小练习。

触发场景一般包括：

它会问一句类似这样的话：

关键是后面。

它不是马上解释答案，而是让你先预测、先生成、先回忆、先教回去。也就是说，它故意让 AI 暂停输出，把思考任务还给你。

这点很反直觉。

我们用 AI 工具时，已经习惯了“别停，继续给答案”。但学习恰恰需要停顿。没有停顿，你的大脑只是消费结果，不是在形成可迁移的能力。

最实用的练习，是预测。

比如 Agent 刚刚重构了一个鉴权中间件，它可以先问你：

你先回答。然后再一起看代码实际行为。

这里重点不是猜对。

猜错也很有价值。因为错误预测会暴露你的心智模型哪里和真实代码不一致。这个差异，比直接看解释更容易被记住。

在 AI 编程里，这招特别适合用在：

很多人看代码只看 happy path。预测练习会逼你去看分支和边界。

这就是从“我看过”走向“我能推演”的差别。

AI 最容易偷走的能力，是方案生成。

你遇到新需求，本来应该先在脑子里拆模块、想数据结构、判断边界。现在变成了“先让 Agent 来一版”。

短期很爽，长期会出问题。

所以另一个练习是：在看 AI 实现之前，先让你自己 sketch 一版。

不用写完整代码，只要说清楚：

然后再对照 Agent 的实现。

对照时不要只问“谁写得好”。更应该问：

这一步很关键。

AI 的实现可以当 worked example，也就是“带答案的例题”。对新手或陌生技术来说，它能降低认知负担。但如果你永远只看例题，不自己动手生成，就会卡在“看懂答案”的舒适区里。

AI 编程还有一个常见后遗症：代码路径感变弱。

以前你自己写功能，从入口到数据库到返回值，路径是慢慢走出来的。现在 Agent 一次性改了 8 个文件，你看 diff 时很容易只看局部。

Trace 练习就是专门治这个问题的。

给一个具体输入，然后一步步问：

这种练习很朴素，但非常有效。

它会把“代码静态长什么样”变成“执行时怎么走”。只要做几次，你就会发现自己对项目的掌控感明显不一样。

尤其是 Agent 做过大重构之后，我建议一定做一次 Trace。别只看测试绿了。测试绿，只说明某些路径被验证过；你能 trace，才说明你知道系统在怎么运转。

还有一种更狠的练习：教回去。

让你把刚完成的组件，讲给一个新加入项目的开发者听。

不是复述代码，而是讲清楚：

如果你讲不出来，基本就别骗自己“我懂了”。

这类练习适合放在 PR 合并前，也适合团队里做小范围分享。它不需要很正式，5 分钟就够。重点是让知识从“眼熟”变成“能组织语言输出”。

能讲清楚，才更接近真的会。

这个技能还提供了一个团队实验思路：用很轻量的前后测，观察大家的学习文化、AI 技能威胁感、编码自信和主动练习意愿有没有变化。

但这里有个坑。

不要把它搞成“每个人必须每天完成两次学习练习”的考勤。

那会很快变味。

更合理的做法是，把它当成团队 AI 编程工作流里的一个小闸门：

不要追求次数，追求关键节点。

真正有用的不是“我做了一个学习练习”，而是你在某个重要改动上，补上了原本被 AI 速度冲掉的思考。

如果不想安装任何插件，也可以先把这套方法手动塞进自己的工作流。

我建议从这 5 条开始：

这里最难的是第一条。

因为 AI 太快了，你会本能地想跳过自己的笨拙阶段。但学习恰恰发生在那个笨拙阶段。你先生成一个不完美的答案，再被现实修正，记忆会更牢。

别把所有困难都外包给 AI。

困难不是浪费时间，很多困难本来就是能力增长的材料。

我不赞成那种“关掉 AI，回到手写时代”的建议。

这不现实，也没必要。

AI 编程确实能让开发者处理更大的代码仓、更快验证想法、更低成本试错。问题不在用不用 AI，而在你是否把所有生成、判断、检索、推演、复盘都交给它。

如果你只让 AI 代替重复劳动，它是工具。

如果你让 AI 代替所有思考，它就会慢慢改写你的能力结构。

这个技能真正提醒我们的，不是“安装一个插件就能防退化”，而是工作流需要重新设计：在 Agent 高速产出之后，必须给人留出短暂但真实的主动练习。

10 分钟不多。

但这 10 分钟，可能就是你从“会指挥 AI 写代码”走向“真的理解系统”的那条线。