
AI 编程最危险的副作用,不是它写错代码。
写错了还能改,还能测,还能回滚。真正麻烦的是另一种情况:项目确实在往前跑,代码也能合并,功能看起来做出来了,但你对系统的理解越来越薄。
你知道按钮点哪里,知道让 Agent 改哪个文件,知道怎么描述需求。
可一旦关掉 AI,脑子里空了一块。
这不是危言耸听。现在越来越多开发者已经开始遇到这种感觉:AI 让产出变快了,但主动生成、调试直觉、架构记忆和代码路径感被慢慢掏空。
最近有一个面向 Claude Code 和 Codex 的开源技能,思路挺有意思。它没有试图让 AI 再快一点,而是反过来,在 AI 写完重要代码之后,提醒你做 10 到 15 分钟的学习练习。
说白了,它想把“人该练的那部分”从 AI 手里抢回来。
Vibe Coding最大的坑:你以为自己会了,其实只是AI替你会了
AI 写代码时,最容易制造一种假象:顺滑。
需求说清楚,Agent 开始改文件,测试跑过,diff 看起来也合理。你扫一眼,觉得“懂了”,然后合并。
问题就在这个“懂了”。
很多时候你只是识别出了熟悉的形状,并没有真正把逻辑装进自己的脑子。等下次要你独立解释为什么这么拆模块、为什么这个 schema 这么设计、为什么边界条件放这里,你会突然发现自己只记得结果,不记得推理。
学习科学里有个很扎心的概念:流畅性错觉。
东西越容易读、越容易获得,人越容易高估自己掌握了它。AI 生成的代码整洁、完整、像答案,这种错觉会被放大。
AI 编程对学习的冲击,大概可以拆成这几类:
这些问题不是“用 AI 就一定会废掉”。真正的问题是:如果工作流只奖励速度,不给学习留位置,能力退化就会悄悄发生。
这个技能不教AI写代码,而是逼你重新参与理解
这个技能的名字可以直译成“学习机会”。
它的设计很克制:不是每次改代码都打断你,而是在完成比较重要的工程动作之后,提供一个可选的小练习。
触发场景一般包括:
它会问一句类似这样的话:
关键是后面。
它不是马上解释答案,而是让你先预测、先生成、先回忆、先教回去。也就是说,它故意让 AI 暂停输出,把思考任务还给你。
这点很反直觉。
我们用 AI 工具时,已经习惯了“别停,继续给答案”。但学习恰恰需要停顿。没有停顿,你的大脑只是消费结果,不是在形成可迁移的能力。
第一招:先预测,再看答案,错了反而赚
最实用的练习,是预测。
比如 Agent 刚刚重构了一个鉴权中间件,它可以先问你:
你先回答。然后再一起看代码实际行为。
这里重点不是猜对。
猜错也很有价值。因为错误预测会暴露你的心智模型哪里和真实代码不一致。这个差异,比直接看解释更容易被记住。
在 AI 编程里,这招特别适合用在:
很多人看代码只看 happy path。预测练习会逼你去看分支和边界。
这就是从“我看过”走向“我能推演”的差别。
第二招:先自己画方案,再对照AI实现
AI 最容易偷走的能力,是方案生成。
你遇到新需求,本来应该先在脑子里拆模块、想数据结构、判断边界。现在变成了“先让 Agent 来一版”。
短期很爽,长期会出问题。
所以另一个练习是:在看 AI 实现之前,先让你自己 sketch 一版。
不用写完整代码,只要说清楚:
然后再对照 Agent 的实现。
对照时不要只问“谁写得好”。更应该问:
这一步很关键。
AI 的实现可以当 worked example,也就是“带答案的例题”。对新手或陌生技术来说,它能降低认知负担。但如果你永远只看例题,不自己动手生成,就会卡在“看懂答案”的舒适区里。
第三招:Trace路径,别让代码仓在你脑子里变成一团雾
AI 编程还有一个常见后遗症:代码路径感变弱。
以前你自己写功能,从入口到数据库到返回值,路径是慢慢走出来的。现在 Agent 一次性改了 8 个文件,你看 diff 时很容易只看局部。
Trace 练习就是专门治这个问题的。
给一个具体输入,然后一步步问:
这种练习很朴素,但非常有效。
它会把“代码静态长什么样”变成“执行时怎么走”。只要做几次,你就会发现自己对项目的掌控感明显不一样。
尤其是 Agent 做过大重构之后,我建议一定做一次 Trace。别只看测试绿了。测试绿,只说明某些路径被验证过;你能 trace,才说明你知道系统在怎么运转。
第四招:Teach it back,把“看懂了”变成“讲得出”
还有一种更狠的练习:教回去。
让你把刚完成的组件,讲给一个新加入项目的开发者听。
不是复述代码,而是讲清楚:
如果你讲不出来,基本就别骗自己“我懂了”。
这类练习适合放在 PR 合并前,也适合团队里做小范围分享。它不需要很正式,5 分钟就够。重点是让知识从“眼熟”变成“能组织语言输出”。
能讲清楚,才更接近真的会。
团队真要用,别把它做成形式主义打卡
这个技能还提供了一个团队实验思路:用很轻量的前后测,观察大家的学习文化、AI 技能威胁感、编码自信和主动练习意愿有没有变化。
但这里有个坑。
不要把它搞成“每个人必须每天完成两次学习练习”的考勤。
那会很快变味。
更合理的做法是,把它当成团队 AI 编程工作流里的一个小闸门:
不要追求次数,追求关键节点。
真正有用的不是“我做了一个学习练习”,而是你在某个重要改动上,补上了原本被 AI 速度冲掉的思考。
我建议把这5条写进你的AI编程习惯里
如果不想安装任何插件,也可以先把这套方法手动塞进自己的工作流。
我建议从这 5 条开始:
这里最难的是第一条。
因为 AI 太快了,你会本能地想跳过自己的笨拙阶段。但学习恰恰发生在那个笨拙阶段。你先生成一个不完美的答案,再被现实修正,记忆会更牢。
别把所有困难都外包给 AI。
困难不是浪费时间,很多困难本来就是能力增长的材料。
AI编程不是不能用,而是别把练习也交出去
我不赞成那种“关掉 AI,回到手写时代”的建议。
这不现实,也没必要。
AI 编程确实能让开发者处理更大的代码仓、更快验证想法、更低成本试错。问题不在用不用 AI,而在你是否把所有生成、判断、检索、推演、复盘都交给它。
如果你只让 AI 代替重复劳动,它是工具。
如果你让 AI 代替所有思考,它就会慢慢改写你的能力结构。
这个技能真正提醒我们的,不是“安装一个插件就能防退化”,而是工作流需要重新设计:在 Agent 高速产出之后,必须给人留出短暂但真实的主动练习。
10 分钟不多。
但这 10 分钟,可能就是你从“会指挥 AI 写代码”走向“真的理解系统”的那条线。
夜雨聆风