Addy Osmani《Don’t Outsource the Learning》解读：别把学习外包给 AI
原始来源：Addy Osmani 文章 Don’t Outsource the Learning
公开来源索引：https://www.codu.co/addy-osmani
说明：本文是基于原文的中文解读与个人延展，不是逐句翻译。文中涉及的研究结论用于帮助理解趋势，不应被读成“用 AI 一定会让人变差”的绝对判断。
最近读到 Addy Osmani 的一篇文章，标题叫 Don’t Outsource the Learning。
直译过来就是：不要把学习外包出去。
这句话放在今天的 AI Coding 场景里，特别准确。
现在写代码已经进入一个很微妙的阶段：你遇到 bug，把错误信息贴给模型；模型给你一个 patch；你复制、运行、测试通过；问题消失；任务关闭。
从项目管理角度看，这很高效。
但从个人成长角度看，中间少了一件事：
你可能没有真的理解问题。
代码修好了，但你的 mental model 没有更新。
更麻烦的是，这件事每天发生时都不像一个问题。你只是快了一点，少卡了一会儿，多关了一个 issue。
但如果连续几个月都是这样，你会慢慢变成一种新的工程师：
能借助 AI 交付，但离开 AI 就很难判断。
这才是 Addy 这篇文章真正想提醒的风险。
1. AI 没有问题，默认用法才有问题
Addy 一开始就说得很清楚：他不是反 AI。
他自己每天用 AI，也因为这些工具交付了比过去更多的东西。
问题不在于用不用 AI，而在于默认使用方式。
现在大多数 AI Coding 工具默认优化的是一个指标：
把任务做完。
模型写代码。
你接受代码。
测试通过。
继续下一个任务。
整个产品体验都在减少摩擦。少敲字、少查文档、少来回切换、少困在错误里。
这当然有价值。
但学习恰恰经常发生在摩擦里。
你为什么会报这个错？
这个 API 为什么这样设计？
这个 abstraction 为什么漏了边界？
这个测试为什么没覆盖到真实风险？
这些问题不一定会阻止你把任务做完，但它们决定你能不能真的变强。
如果 AI 直接把中间那段挣扎拿走了，你会得到一个结果，却错过了能力增长的过程。
这就是文章里最核心的担心：
我们正在用今天的速度，换明天的理解力。
2. “认知卸载”和“认知投降”不是一回事
我觉得这篇文章可以和 Addy 之前讲过的 cognitive surrender 放在一起看。
这里有两个概念要区分。
第一个叫认知卸载。
认知卸载本身不是坏事。
我们一直在把认知外包给工具：计算器、搜索引擎、IDE、类型系统、自动补全、单元测试、文档、lint、CI。
成熟工程师本来就不应该把脑子浪费在所有细节上。
第二个叫认知投降。
这就危险了。
认知投降不是“我让工具帮我做一部分工作”。
而是：
我不再拥有判断，只是接受工具给出的判断。
AI 说这个修法可以，我就信。
AI 说这个设计合理，我就信。
AI 说这个错误原因是某个库版本冲突，我就信。
AI 生成了测试，我就默认覆盖到了关键风险。
这时你不是在使用工具，而是在把自己的判断权交出去。
短期看，这会让你变快。
长期看，它会让你变钝。
3. 几项研究指向同一个问题：姿态比工具更重要
原文引用了几项研究，方向大致一致。
Anthropic 做过一个关于 AI assistance 和 coding skill formation 的实验。参与者学习一个新的 Python library，一组可以用 AI，一组不用 AI。结果不是简单的“AI 组更快更强”。
相反，AI 组后续理解测试平均分更低，尤其在 debugging 相关问题上差距明显。
但真正有意思的是 AI 组内部的差异。
那些用 AI 问概念、要求解释、验证自己理解的人，表现明显更好。
那些直接复制 AI 代码的人，表现明显更差。
也就是说，决定结果的不是“有没有 AI”，而是“你把 AI 当什么”。
你把它当老师，它可能让你学得更快。
你把它当代工，它可能让你学得更少。
MIT Media Lab 的 Your Brain on ChatGPT 研究也提供了类似提醒。研究把写作任务分成 LLM、搜索引擎和纯脑力几组，用 EEG 观察参与者的脑连接模式。研究团队提出了 cognitive debt 这个说法，意思是：今天省下来的思考成本，可能会在未来以更弱的记忆、所有权感和批判性思维能力还回来。
这项研究是预印本，也有不少争议，所以不能把它夸大成“ChatGPT 会让人变笨”的简单结论。
但它至少提醒我们一件事：
当工具替你完成太多生成过程，你对结果的拥有感会下降。
CHI 2026 还有一篇关于 LLM access timing 的研究。它关注的是：AI 在任务一开始就介入，和人在先独立思考后再使用 AI，结果有什么不同。
研究发现，在时间压力很大时，早用 AI 可能有帮助；但在时间充足时，一开始就让 AI 介入，反而可能削弱后续推理和回忆表现。原因之一是，人更容易被 AI 给出的初始框架锚定，不再充分查看材料、迭代自己的论证。
这三类研究的方法不同，但共同指向一个现实问题：
AI 最大的风险不是帮你太少，而是太早、太顺、太像正确答案。
4. 为什么“任务完成”不等于“能力增长”
软件工程里有一个很容易被忽视的事实：
交付结果和形成能力是两条曲线。
它们有时一起上升，但不是同一件事。
你可以在不理解正则表达式的情况下，让 AI 写出一个能跑的 regex。
你可以在不理解异步模型的情况下，让 AI 帮你修一个 race condition。
你可以在不理解框架生命周期的情况下，让 AI 帮你补一个 hook。
你也可以在不理解数据库事务边界的情况下，让 AI 帮你写一个看起来没问题的 service。
任务也许能完成。
但你的能力不一定增长。
能力增长通常需要三个东西：
第一，自己形成假设。
第二，和现实反馈碰撞。
第三，修正自己的 mental model。
AI 如果只是帮你更快拿到答案，可能会跳过这三个环节。
尤其是 debugging。
调试能力不是背出来的，而是在大量“我以为是 A，结果不是；我再查 B，还是不是；最后发现真正原因是 C”的过程中长出来的。
这个过程很慢，也很烦。
但它会塑造工程师最重要的能力：
在不确定中定位问题。
如果每次不确定都直接交给 AI，你会少经历痛苦，也少获得校准。
5. “AI 能做，我为什么还要懂？”这个问题不能一刀切
原文里有一个很公平的问题：
如果 AI 已经能做了，我为什么还需要理解？
这个问题不能用道德感回答。
有些东西确实不值得深学。
一次性的 CI 脚本。
样板代码。
配置文件里的重复字段。
临时数据转换。
某个只用一次的库函数参数。
这些东西让 AI 代劳完全合理。人的注意力有限，不应该把所有语法细节都变成长期记忆。
但真实软件里有几类事情不能完全外包。
第一，系统出问题时。
线上崩了，客户数据错了，任务队列堵了，缓存穿透了。你不能只说“代码是 AI 写的”。系统需要有人真正理解。
第二，AI 自信但错误时。
LLM 很擅长生成看起来合理的答案。真正危险的不是明显错误，而是半对半错、语气自信、刚好能通过局部测试的错误。
第三，架构要迁移时。
框架升级、安全审计、数据模型变化、业务流程重构，这些不是重新 prompt 几次就能解决的。你需要理解系统为什么长成现在这样。
第四，问题偏离常见答案时。
AI 很擅长解决 GitHub 上出现过无数次的问题。越接近中位数，它越强。越是业务特定、上下文复杂、没有标准答案的问题，越需要人的深度理解。
第五，职业市场重新定价时。
如果一个工程师只能在 AI 看着的情况下交付，但不能独立判断，他的价值会变得很脆弱。
真正值钱的不是“会不会让 AI 写代码”。
而是：
你能不能判断 AI 写得对不对，适不适合，能不能长期维护。
6. 好的 AI 工作流，应该先保护你的思考权
这篇文章最实用的地方，是它没有停在焦虑上，而是给出了一组很小的 workflow 调整。
我把它们重新整理成六条。
第一，问 AI 之前，先写下自己的假设
不要一看到错误就直接贴给模型。
先写两三句话：
我认为问题可能出在什么地方？
为什么？
我已经排除了什么？
我最不确定的地方是什么？
然后再问 AI。
这样 AI 的回答不是替代你的判断，而是在检验你的判断。
这一步很小，但会保留你的主动推理。
第二，不熟悉的领域，先问解释，不要先要代码
如果你在学一个新框架、新语言、新库、新架构模式，第一问不应该是“帮我实现”。
更好的问法是：
请先解释这个机制如何工作，有哪些常见方案，各自 tradeoff 是什么，容易踩哪些坑。
等你理解概念之后，再让它写代码。
先要代码，你很容易被实现细节牵着走。
先要解释，你才有机会建立地图。
第三，把 AI 输出当成 junior engineer 的 PR
AI 写出来的代码，不应该因为“能跑”就合并。
你要像 review 一个初级工程师的 PR 一样看它：
命名是否表达真实意图？
边界条件有没有处理？
错误路径是否清楚？
有没有过度抽象？
测试覆盖的是行为，还是只覆盖了 happy path？
有没有引入新的隐性耦合？
如果你不会这样 review 人写的代码，也很难 review AI 写的代码。
第四，偶尔手写一遍 AI 写过的东西
这听起来低效，但很有用。
找一段 AI 写过的代码，关掉模型，自己重新实现一次。
你会立刻知道自己到底懂没懂。
如果你能写出来，说明 AI 帮你加速了学习。
如果你完全写不出来，说明你只是借用了结果。
这不是每天都要做，但需要定期做。
它像体检，能发现你是不是在悄悄失去肌肉。
第五，让 AI 解释它刚才做了什么
每次 AI 给你一个比较聪明的实现，不要急着结束。
追加一个问题：
你刚才用了哪些概念？为什么这样设计？如果我要真正理解这个写法，需要补哪些背景？
这一个额外 prompt，可能决定你这次会话是“完成任务”，还是“完成任务并学到东西”。
第六，在陌生区域打开学习模式
OpenAI 的 Study Mode、Claude 的 Learning Mode，以及其他类似功能，本质上都是在把“直接给答案”改成“引导你思考”。
很多工程师会下意识把它们归类成学生工具。
这其实是误解。
资深工程师学新东西时，也需要重新当初学者。
Senior 学 Rust、学分布式数据库、学编译器、学安全、学 GPU 编程，本质上和学生学 React 没有那么大差别。
只是成年人更不愿意承认自己需要慢下来。
7. 对个人最重要的问题：今天我只是关闭 issue，还是更新了模型？
Addy 在文章最后提了一个很好的自检问题：
今天我学到了什么，还是只是关闭了几个 issue？
这个问题比“我今天用了多少 AI”更重要。
因为 AI 使用量不是关键指标。
关键指标是：
你有没有更能独立判断。
有些天就是纯交付。
这没问题。
项目 deadline 很近，客户在等，线上有故障，业务需要一个快速 patch。那就用 AI 把事情做完。
但如果几个月过去，你每天的答案都是“我只是关闭了 issue”，那就说明认知债务在积累。
你可能越来越快，但也越来越依赖。
短期效率和长期能力不是同一个指标。
老板和客户通常只会问第一个：
东西做好了吗？
但第二个问题只能你自己问：
我还在变强吗？
8. 对团队来说，AI Coding 需要新的工程文化
这篇文章虽然写给个人，但我觉得它也在提醒团队。
如果一个团队只奖励“更快 merge”，不奖励“更清楚地解释为什么这么改”，那大家自然会把 AI 用成最快的代工工具。
久而久之，代码库会出现一个问题：
表面上改动越来越快。
实际上团队对系统的共同理解越来越薄。
这会带来几个后果。
Review 变得形式化。
测试变成合并门槛，而不是理解行为的工具。
新人更难建立系统模型。
线上问题出现时，大家都能让 AI 猜原因，但没人真正知道架构边界在哪里。
所以团队使用 AI Coding 工具时，最好保留一些学习型机制：
- PR 描述里写清楚自己的判断和取舍。
- 对复杂 AI 生成代码要求解释关键设计。
- 对新领域任务保留人工推导和技术笔记。
- Code review 不只看能不能跑，也看作者能不能解释。
- 对关键模块建立 architecture notes，而不是只留下代码。
AI 会让写代码更容易。
但也正因为写代码变容易了，理解代码、证明代码、解释代码会变得更重要。
参考来源
- Addy Osmani 文章列表：Don’t Outsource the Learning
https://www.codu.co/addy-osmani - Anthropic：How AI assistance impacts the formation of coding skills
https://www.anthropic.com/research/AI-assistance-coding-skills - MIT Media Lab：Your Brain on ChatGPT
https://www-prod.media.mit.edu/projects/your-brain-on-chatgpt/overview/ - arXiv：Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task
https://arxiv.org/abs/2506.08872 - CHI 2026：Investigating the Effects of LLM Use on Critical Thinking Under Time Constraints
https://doi.org/10.1145/3772318.3791796 - University of Chicago 对上述 CHI 2026 论文的介绍
https://cs.uchicago.edu/news/the-time-constraints-of-ai-access-could-change-how-we-think/ - OpenAI：Introducing study mode
https://openai.com/index/chatgpt-study-mode/
Leave a Reply