不要把学习外包给 AI

AI 编程工具越强，越需要问一个反直觉的问题：你是在借助 AI 学得更快，还是只是让 AI 替你跳过了学习？

Addy Osmani 在《Don’t Outsource Your Learning》里讲的不是“不要用 AI”。恰恰相反，他长期关注 AI 辅助开发，也承认 AI 能显著提高工程师的速度。真正的提醒是：AI 可以帮你完成任务，但不能替你形成理解。它能给出答案，但如果你没有经历发现问题、做出假设、尝试修复、犯错、调试、验证的过程，能力并不会自动长出来。

这篇文章值得引入到 AI 原生团队的讨论里，因为它说中了一个容易被忽略的成本：AI 不只会改变产出速度，也会改变学习路径。工具默认优化的是关闭任务，不是训练判断。你把 bug 修掉了，但你的 mental model 可能没有动。

过去，写代码慢，有一部分慢来自摩擦：查文档、理解报错、读源码、试错、重构、回滚。这些摩擦很烦，但它们也是训练判断力的材料。AI 把摩擦抹平之后，人的体验变好了，反馈却可能被拿走。

你看起来做得更多，但也可能理解得更少。

工具默认帮你 ship，不默认帮你 learn

大多数 AI coding 工具的默认 loop 很顺滑：贴需求或报错，模型给修复，症状消失，任务关闭。产品体验越好，这个 loop 越不打断你。

问题是，学习恰恰发生在被打断的地方。

你以为某段代码会这样运行，结果不是；你以为 bug 在这一层，调试后发现根因在另一层；你以为某个抽象会让系统更清楚，改完以后才发现调用方更难用了。这些落差让人不舒服，但正是这些落差在训练你。

AI 的问题不是它给答案，而是它太容易直接跨过这段落差。当你让模型直接改完一个 bug，却不追问为什么这样改；当你让它生成一整个组件，却不读它为什么拆成这些状态；当你让它解释一段陌生代码，却不自己画出数据怎么流动，你得到的是短期完成，不一定是长期能力。

一开始这很难察觉。因为任务确实完成了，代码确实跑了，PR 也可能合并了。但几周后，如果同类问题再次出现，你仍然无法判断模型答案是否可靠，无法指出风险在哪里，也无法在它给错方向时把它拉回来。

这就是 cognitive debt。它不像技术债那样留在代码库里，而是留在人的判断力里。

研究指向同一个问题：姿态比工具更重要

Addy 原文有一个很重要的部分：这不是纯粹的个人体感，过去一年多的几组研究正在指向同一个方向。

Anthropic 在 2026 年 1 月发布了一项随机对照研究，让 52 位主要是 junior 的软件工程师学习一个不熟悉的 Python 库。一组可以用 AI，一组手写。AI 组平均只快了大约两分钟，速度差异没有达到统计显著；但随后的理解测验里，AI 组平均 50%，手写组 67%，差距接近两个 letter grade。更值得注意的是，差距在 debugging 问题上最大，因为调试正是未来检查 AI 代码最需要的能力。

但结论不是“用了 AI 就会变弱”。Anthropic 的定性分析更有意思：在 AI 组内部，用 AI 问概念、追问解释、边独立编码边求证的人保留得更好；把 AI 当代码生成器、直接复制结果的人，理解最差。工具没有决定结果，使用姿态决定了结果。

MIT Media Lab 的《Your Brain on ChatGPT》研究看的是写作任务，不是编程，但机制相似。研究把参与者分成 LLM、搜索引擎和纯脑力组，持续比较神经、语言和行为层面的变化。LLM 组在多个层面表现出更弱的参与和更低的文本归属感，研究者把这种现象称为 cognitive debt：今天省下的脑力，可能变成明天更弱的批判性思考。

还有一篇 CHI 2026 论文研究 LLM 介入时机。它发现，在时间压力下，早用 LLM 可能提升表现；但时间充足时，一开始就让 LLM 介入反而会损害结果。换句话说，顺序很重要。先让模型框住问题，人之后再努力，也可能已经被早期答案锚定。

这些研究的共同点不是反 AI，而是提醒我们：AI 是放大器。它可以放大执行，也可以放大依赖；可以加速理解，也可以替代理解。

可以委派执行，但不能委派理解

“如果 AI 能做，我为什么还要懂？”这是一个合理问题。

有些东西确实可以交出去。一次性的脚本、重复样板、熟悉框架里的胶水代码、不会长期维护的小工具，让 AI 直接做没有问题。不是每个语法细节都值得记住，也不是每个低风险任务都值得人从零推演。

但真实软件里，纯委派会在几个地方失效。

第一，系统坏掉时。AI 写的代码和人写的代码一样会崩。线上报错不会因为“这是模型写的”就更容易定位。团队里总要有人理解状态、依赖、调用链和失败模式。

第二，答案看起来对但其实错时。LLM 最危险的输出不是明显胡说，而是结构完整、语气自信、局部正确。防住这种错误，需要足够的领域判断，而不是更多复制粘贴。

第三，基础设施变化时。框架升级、依赖弃用、安全审查、计费模型变化、数据权限收紧，这些问题不能靠重新 prompt 一次解决。你需要理解系统为什么这样设计，才知道迁移时什么不能破坏。

第四，问题离 GitHub median 越来越远时。AI 很擅长解决被大量重复过的问题；越是未文档化、强业务约束、跨团队边界的问题，越需要人理解上下文和取舍。这些问题恰恰是 senior engineer 的价值所在。

第五，市场重新定价时。只会在 AI 扶着的时候交付，和能判断 AI 什么时候错、哪里该改、何时该停，是两种不同能力。前者会越来越便宜，后者会越来越稀缺。

所以更准确的原则不是“不要委派”，而是：

委派执行，但不要委派你未来需要负责的理解。

那些烦人的摩擦，正是在训练你

很多工程经验都不是从教程里获得的，而是在具体挫败里长出来的。

你第一次遇到异步状态乱序，才会真正理解竞态。你被一个隐式共享状态坑过，才会对可变对象保持警觉。你追过一次线上性能问题，才会知道“看起来优雅”的抽象可能藏了多少成本。

这些经验很难被直接灌输。别人可以告诉你原则，但原则只有在真实上下文里疼过一次，才会变成直觉。

这也是 Addy 文章里最重要的判断之一：如果 AI 替你拿走所有困难，它也可能拿走让你成为高手的那部分训练。

对新手尤其如此。新手最需要建立的是心智模型：语言怎么执行，框架怎么组织状态，网络请求为什么失败，数据库查询为什么慢，测试为什么能保护重构。AI 如果只作为“答案机器”，会让新手跳过心智模型的形成。

对老手也一样。老手不是不会被削弱，只是削弱的方式更隐蔽。你可能开始不再深读陌生代码，不再自己追根因，不再更新底层知识。短期看是效率提高，长期看是判断力钝化。

AI 应该变成教练，不是代写员

更好的用法，不是少用 AI，而是改变 AI 在学习循环里的位置。

不要一上来就让它给完整答案。先让自己做一次预测，再让 AI 参与。

更具体一点，可以把默认 prompt 改成这些动作：

先写下你认为 bug 可能在哪里，再让 AI 检查推理
先让 AI 解释机制、替代方案和 tradeoff，再让它写代码
先自己拆任务，再让 AI 找遗漏、风险和边界条件
把 AI 输出当成 junior engineer 的 PR：读、问、改、要求补测试
偶尔把模型写过的关键函数从零手写一遍，检查自己到底理解了多少
让 AI 教你它刚才用了哪些概念，以及你应该读什么才能理解这个设计

这里的关键是顺序。你先暴露自己的模型，AI 才能帮你校准。否则你只是消费答案，很难知道自己到底哪里不会。

把 AI 当教练时，一个很好用的提示方式是让它提问：

先不要直接给答案。请问我 3 个问题，确认我是否理解这段代码的执行路径。然后指出我推理里最可能错的一步。

或者：

我会先给出自己的修复方案。请你只审查风险、边界条件和我遗漏的测试，不要重写整段代码。

这种互动比“帮我改好”慢一点，但它保留了学习所需的主动预测。你仍然在做判断，AI 只是把反馈变得更快、更密。

如果工具提供 Learning Mode、解释模式、Socratic questioning 或类似设置，真正该打开它们的并不只是学生。一个 senior engineer 学 Rust、一个前端工程师学 distributed systems、一个产品工程师第一次碰 billing，也都应该允许自己短暂地像初学者一样工作。

慢一点不是失败。慢一点可能是在保留未来的速度。

团队不能只看交付，也要看学习

很多公司衡量 AI 编程工具时，最容易看见的是产能：代码生成量、任务完成速度、PR 数、工单吞吐。这些指标有用，但如果只看它们，团队会自然鼓励“更快地把工作交给 AI”。

真正该问的是：团队有没有因为 AI 变得更会判断？

可以观察几个信号：

工程师能不能解释 AI 生成代码的设计取舍
Code review 里有没有指出模型常犯的错误模式
测试是不是覆盖了 AI 容易漏掉的边界
线上事故复盘有没有更新提示词、模板、检查清单或 eval
新人是不是通过 AI 更快理解系统，而不是更快复制答案
团队有没有沉淀“什么时候可以委派，什么时候必须自己想”的判断标准

Addy 在原文里用了一个很好的区分：ship 和 learn 是两个指标。客户和管理者天然会问第一个：这周关了多少 issue，合了多少 PR，交付了多少功能。第二个指标没有人自动替你问：这周你理解了什么，团队变得更会判断了吗？

这不是鸡汤。对 AI 原生团队来说，learn 是生产指标。

这和 AI 原生团队的建设是一件事。AI 不该只是放大执行，也应该放大反馈。一次 AI 生成代码后的 review，不只是为了合并这次 PR，也应该反过来改进团队的上下文：哪些约束应该写进文档，哪些工具描述需要更清楚，哪些测试应该自动化，哪些模式应该进入 Agent Skill。

如果每次错误都只由人临时兜底，团队会越来越依赖少数高手的隐性判断。如果每次错误都能留下规则、检查和案例，团队才会真的变强。

学习回路也需要 Harness

我读这篇文章时，最自然联想到的是 Harness。

我们通常说 Agent 需要 Harness，是因为真实工作不只需要模型，还需要上下文、工具、约束、验证和纠正。同样，人使用 AI 学习，也需要一层 Harness。

这层 Harness 不一定是复杂系统。个人层面，它可以很简单：

上下文：让 AI 知道你当前水平、目标和已有理解
约束：要求 AI 不直接给最终答案，先引导你推理
验证：让你写测试、复述机制、解释边界条件
纠正：让 AI 指出你的误解，而不是只给新代码
记忆：把反复犯错的点记录成自己的 checklist

没有这层 Harness，AI 很容易变成答案自动售货机。有了这层 Harness，AI 才更像一个可以随叫随到的导师。

团队层面，它也可以变成更具体的工作系统：

PR 模板要求说明 AI 参与了哪些部分
Code review checklist 里加入模型常见错误模式
关键路径代码必须附测试或可复现验证
新人 onboarding 里要求先解释系统，再让 AI 生成改动
事故复盘要更新 docs、eval、prompt、Skill 或工具描述
对高风险任务设置人工判断点，而不是只在最后看结果

这就是人类学习回路的 Harness：上下文让人知道自己在学什么，约束防止直接跳到答案，验证让理解暴露出来，纠正把误解转成规则，记忆让下一次不从零开始。

真正成熟的 AI 编程文化，不是每个人都离不开 AI，而是每个人都知道怎样和 AI 一起保持学习。AI 原生团队不是只会更快交付，它应该让团队的判断标准、测试体系、文档、工具和 Agent Skill 都随着每次运行变得更好。

用 AI 加速反馈，不要绕过反馈

AI 会继续变强。它会越来越会写代码，越来越会读仓库，越来越会调用工具，越来越能完成长任务。这是好事。

但模型越强，人越需要守住一件事：判断力不能被动委派。

因为你仍然要决定问题是否值得做，方案是否真的对，代码是否能维护，风险是否能接受，输出是否可以进入生产。AI 可以给你更多候选答案，却不能替你承担这些判断。

所以这篇文章最值得留下来的，不是“少用 AI”，而是一个更具体的原则：

用 AI 加速反馈，不要用 AI 绕过反馈。

让 AI 解释、质疑、出题、对比、审查、生成测试、指出盲点。让它帮你走得更快，但不要让它替你走完所有认知路径。

真正的学习不是把答案拿到手，而是下一次没有答案时，你能更早看出问题在哪里。

本文整理自 Addy Osmani 的文章 Don’t Outsource Your Learning，核心观点来自原文。

参考来源

Don’t Outsource Your Learning —— Addy Osmani, May 16, 2026
How AI assistance impacts the formation of coding skills —— Anthropic, Jan 29, 2026
Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task —— Nataliya Kosmyna 等, Jun 10, 2025
Investigating the Effects of LLM Use on Critical Thinking Under Time Constraints —— Jiayin Zhi、Harsh Kumar、Mina Lee, Mar 9, 2026