本文译自 Addy Osmani 的《Don’t Outsource the Learning》，并在不改变原意的前提下做了适当的语言润色与本地化。原作者：Addy Osmani。文中第一人称「我」均指原作者。

Don’t Outsource the Learning

现在有件事变得太容易了：让 AI 把代码写完，自己却把学习这一步省掉。Bug 是修好了，可你的心智模型纹丝没动——时间一长，甚至还会退步。我们其实是在悄悄地用未来的能力，换今天的速度，而工具并不会拦着我们。要不要停下来，只能由你自己决定。

我们大多数人都滑进了同一个套路：把一段需求或一条报错粘进去，模型递回来一个修复方案，症状消失，你直接发版（ship）。在这个循环的某个环节，问题与解法之间那场乱糟糟的较量，已经彻底不再发生了。

我以前写过「认知投降」（cognitive surrender）——就是 AI 的判断不知不觉顶替掉你自己判断的那一刻。今天要说的，是它的单人版本：场上只有你和模型。模型比你快，于是你索性不再跟它比拼「谁更理解」。可就在这成千上万次的小互动里，那些没有 AI 在旁边时你本来能独立做出来的东西，正一周一周地被减弱。而这些时刻，发生在当下的那一天，没有哪一次看起来像是个问题。

我并不反对 AI。这些工具我天天都在用，过去一年靠它们交付的成果，比之前好几年加起来还多。但我们使用它们的默认方式，只为一件事做了优化：把任务关掉。

而这件事，跟「让自己一直敏锐到足以在整段职业生涯里持续驾驭它们」，根本是两个目标。

这些研究正在指向同一个结论

过去一年里的几项研究，落点出奇地一致。

Anthropic 在 2026 年初做了一个随机对照试验：让工程师去学一个全新的 Python 库，一半有 AI 协助，一半没有。两组完成任务的速度不相上下。但在随后的理解测验里，AI 组败下阵来——50% 对手动组的 67%，而且越是调试题，差距拉得越大。更耐人寻味的是 AI 组内部的分化：用 AI 去追问「概念」的工程师得分超过 65%，直接复制粘贴生成代码的则不到 40%。可见决定结果的不是工具本身，而是你用它的姿势。

MIT 的《Your Brain on ChatGPT》研究，把写文章的人分成三组：用 LLM 的、用搜索引擎的、纯靠脑子的。EEG 数据显示，外部辅助每多叠一层，大脑的连接强度就弱一分，其中 LLM 组的耦合最弱。文章写完后，83% 的 LLM 组用户连自己刚写的东西里的一句话都复述不出来。研究者给这个现象起了个名字——「认知负债」（cognitive debt）：今天省下的脑力，明天要用批判性思维来还。

CHI 2026 的一项研究又补上了相关的一笔：当人们在任务一开始就用上 LLM，LLM 会替整个问题定好框架。即便后面的活儿全是人自己干的，这种最初的「锚定」也会让最终决策明显变差。换句话说，操作的先后顺序，比 AI 用了多少更要紧。

方法各不相同，结论却殊途同归：在缺乏主动学习意图的情况下使用 AI，会悄悄蚀掉那项你正靠它吃饭的技能。

工具的默认设置是为了「交付」，不是为了「教会你」

打开一个编码 agent，一切照默认走，那么所有设计都只朝一个指标看齐：把任务做完。模型写代码，你点接受，循环往复。在任何一个节点上，工具都不会停下来问你一句「你觉得问题出在哪？」或者「要不先自己写头五行试试？」

这就是当下的产品与交互的设计方向。产品团队被奖励的，是合并的变更数和更短的周期，而不是「把你磨成一个更敏锐的工程师」。我们都想少敲几下键盘，于是工具把摩擦一点点润滑了。麻烦在于，学习恰恰就藏在那些摩擦里。

也有几家公司想给这种循环踩一脚刹车。Anthropic 为 Claude 上线了「学习模式」（Learning Mode）：用苏格拉底式的反问，并在往下走之前先让你写一段代码。OpenAI 和 Google 也推出了类似的功能。但说实话，几乎没人在真正的生产工作里用它们。我们悄悄把它们归进了「学生才用」的那一类——这是个误判。同一个能帮大二学生学会 React 的功能，照样能帮一位资深工程师学会 Rust，前提只是你愿意重新当一回新手。

「既然 AI 能做，我为什么还要懂？」

这问题问得在理。对某些活儿来说，答案确实是——也许你真不用懂。如果是样板代码、胶水代码，或者一个你这辈子都不会再看第二眼的一次性 CI 脚本，那就放心交出去，把这点语法背进脑子的机会成本太高了。

但换成真正要长期维护的软件，纯委托会在几个特定的地方崩掉：

东西出故障的时候。 AI 写的代码，崩起来和人写的没两样。「这是 agent 写的」帮不了你调试，团队里总得有人真正吃透这套架构。
它一本正经地犯错的时候。 LLM 仍然会胡说八道。面对一个看着合理、实则错误的答案，唯一的防线就是你懂得够多、一眼能识破。skills 之类的「创可贴」只能顶一阵子。
地基变动的时候。 代码是临时的，系统是长久的。框架升级、或者安全评审揪出一个结构性问题时，你没法靠「再 prompt 一遍」蒙混过去，得有真正理解这套系统、能把它迁移过去的人。
你偏离中位数的时候。 对那些在 GitHub 上被解决过上百万遍的问题，AI 游刃有余；可你离中位数越远，它就越力不从心。那些困难的、没文档的问题——也正是撑得起一份资深薪水的问题——依旧要靠深刻的理解。
市场重新定价的时候。 那些只会借 AI 交付、离了 AI 就不行的工程师，正踏进一个早已开始重估「专业能力值多少钱」的市场。拿 AI 来跳过学习，等于拿未来的竞争力，去换一个稍微轻松点的周二下午。

解药藏在你怎么提问里

好消息是：制造认知负债的那些工具，同样能把人磨得更锋利。区别只在于，你向它们提出什么样的要求。

先立假设，再开口问。 在请求修复方案之前，先用两三句话写下你认为问题出在哪，然后拿模型的回答去检验你的判断，而不是替换掉它。
先要解释，再要代码。 在陌生领域，第一句不妨这么问：「讲讲这是怎么工作的、还有哪些替代方案、各自的取舍是什么。」等概念吃透了，再去要代码。
吃不准的时候，把学习模式打开。 是会慢一些，但慢正是它的意义。
把 AI 的输出当成初级同事提的 PR。 去读它、挑它的毛病、跟它较真。你会因为「测试过了」就直接合并吗？不会的话，这里也别合。
隔三差五，亲手把东西重推一遍。 挑一段模型替你写的代码，试着从零再造一次。这是一次校准，能让你看清自己究竟悄悄丢了多少。
让模型把它刚做的事讲给你听。 它写出一个漂亮的函数后，问问它用到了哪些概念、想看懂这个设计该去读些什么。多这么一问，你从这次会话里带走的东西就完全不一样了。

这些都谈不上什么大动作，不过是在你已经在用的工具里，调整几个小小的姿势而已。

两个指标，而不是一个

我现在习惯在每次编码收工时问自己一句：今天我学到东西了，还是只是关掉了几个 issue？

有时候诚实的答案就是「我只是关了几个 issue」——这也没什么。但要是接连好几个月答案都如此，那认知负债就在你看不见的后台默默累积。

「交付」和「学到手」是两条不同的线。你的老板和客户永远只会问第一条，第二条只能靠你自己盯着。

我宁可只交付出本可以交付的 80%，却把该学会的东西学满 100%，也不要反过来。把时间拉到很多年，这两种取法会养出截然不同的工程师。

你不必在「用 AI」和「学习」之间二选一，但你确实得主动挑一套两者兼顾的工作流——因为默认设置不会替你挑。工具一直都准备好了，就等你。

你正打算随手扔出去的下一件无聊小事，就是个不错的起点。