不要让 AI 替你学习：认知债务正在悄悄累积

现在有个默认循环，大多数人已经习惯了。

你粘贴一个需求或报错。AI 模型给你一段修复代码。症状消失了。你 deploy 了。但在那个循环里，问题和解法之间的"纠结"，已经不再发生了。

Bug 被修复了，但你的心智模型没有更新。它甚至可能变得更糟。我们在用今天的效率，悄悄透支未来的能力。

Addy Osmani 把它叫作"认知债务"。不是钱的事，是脑力的事。

一、三项研究，同一结论

过去一年，几项独立研究从不同角度验证了同一个现象。

不同方法论，同一结论。不带主动学习意图地使用 AI，在悄悄贬值你被雇来干活的那个技能。

二、产品默认的陷阱

打开一个编程 Agent，保持默认设置——一切都在为同一指标优化：完成这个任务。

模型写代码。你接受。循环重复。没有任何工具会停下来问"你觉得问题是什么？"或"前五行你自己先写写看。"

产品团队因为合并变更和缩短周期受到奖励，而不是因为你变得更厉害而被奖励。大家都想要更少的击键次数，所以工具把摩擦磨掉了。但麻烦的是——摩擦才是学习住的地方。

Anthropic 为 Claude 推出了学习模式，用苏格拉底式提问让你先写代码再继续。OpenAI 和 Google 也有类似功能。但说真的，几乎没人用在正经生产工作上。我们都默默把它归类为"给学生的"，这是个错误。

三、什么时候可以偷懒？

公平的问题来了——有些工作能不能就交给 AI 算了？

答案是：能。如果是模板代码、胶水代码、一个扔掉的 CI 脚本你永远不会再碰，全权委托就完了。记住某些语法的机会成本太高了。

但对于真正的工程，纯委托会在几个地方出问题：

• 出 bug 的时候。AI 写的代码和人写的代码一样会崩。"Agent 写的"不会帮你调试。团队里总得有人理解架构。
• 它自信地犯错的时候。LLM 仍然会幻觉。对抗看起来合理的错误答案，唯一的防线是你自己足够资深。Bandaids 只能帮你到这一步。
• 地基换的时候。代码是暂时的，系统是永久的。框架更新、安全审查出事，你不能靠 re-prompt 解决问题。需要懂系统的人来做迁移。
• 离开中位线的时候。GitHub 上被解决过一百万次的问题，AI 很在行。离中位线越远，它越差。而正是那些难到没有文档的问题，值得高级工程师的工资。
• 市场重新定价的时候。只用 AI 才能交付的工程师，正在进入一个已经重新评估专业价值的人才市场。用 AI 跳过学习，你是在用未来的竞争力换一个稍微轻松点的今天。

四、六个姿势，改变一切

好消息是：同一套工具，既产生认知债务，也能培养更优秀的工程师。区别在于你向工具要什么。

1. 问之前先形成假设。要求修复之前，先写两三句话，说你觉得问题是什么。用模型的结果来验证你的理论，而不是替代它。
2. 先要解释，再要代码。在不熟悉的领域，你的第一个 prompt 应该是"解释一下这是怎么工作的，有什么替代方案，有什么权衡。"理解概念之后再要代码。
3. 进入学习模式。身处不熟悉的深度时，打开学习模式。是的，它更慢。这就是目的。
4. 把 AI 的输出当成初级工程师的 PR。读它。批评它。质疑它。测试通过你就 merge 吗？不是的话，这里也别 merge。
5. 偶尔自己手推一遍。拿一段 AI 写的代码，自己从头写一次。这是校准检查，告诉你你悄悄丢了什么。
6. 让模型教你它做了什么。写出一段巧妙的函数之后，问它用了什么概念，需要读什么才能理解这个设计决策。多一个 prompt，改变你从这次对话里带走的东西。

有时候诚实的答案是"我只是 close 了 issues"。这没问题。但如果连续几个月都是这个答案，认知债务在悄悄积累。

Ship 和 Learn 是两个不同的指标。你的经理和客户只会问前面那个。后面那个，靠你自己。

Addy 最后说：我宁愿交付我能交付的 80%，学到我需要学的 100%，而不是反过来。几年下来，两种策略造出完全不同的工程师。

你不用在"用 AI"和"学习"之间做选择。但必须选择一套二者兼顾的工作流，因为默认设置不会替你选择。工具已经准备好了。下一个你想要委托的乏味任务，就是个不错的开始。

← 返回首页