不要把学习外包出去

# 别把学习外包出去 来源：https://addyosmani.com/blog/dont-outsource-learning/ *如今，我们太容易让 AI 写代码，自己却跳过学习。Bug 被修复了，但你的心智模型毫无进展。我们正悄无声息地用未来的能力换取当下的速度，而工具不会迫使我们改变。这一点，必须由你自己来做到。* --- 多数人已经陷入了一个默认循环：你把需求或报错信息粘进去，模型给出修复方案，症状消失，你发布上线。在这个循环中的某个环节，问题与解决方案之间那种混乱的挣扎彻底消失了。 我之前写过关于[认知投降](https://addyosmani.com/blog/cognitive-surrender/)的文章，指的是 AI 审查者的结论悄然取代了你自己的判断。而这个是同一循环的单人版本——只有你和模型。模型更快，所以你不再试图在理解上与之竞争。成千上万次这样的小交互过后，你在没有 AI 监督的情况下真正能构建的能力，每周都在变弱。每一刻发生时，都不觉得是个问题。 我不反对 AI。我每天都在用这些工具，过去一年里用它交付的东西比过去五年还多。但我们默认的使用方式只优化了一件事：关闭任务。这与保证你在数十年的职业生涯中仍能敏锐地驾驭工具，是完全不同的目标。 --- ## 多项研究正指向同一结论 过去一年，几项研究大致得出了相同的结果。 Anthropic 在 2026 年初开展了一项[随机对照试验](https://www.anthropic.com/research/AI-assistance-coding-skills)，让工程师学习一个新的 Python 库，一半人使用 AI 辅助，另一半不用。两组完成任务的速度相同。但 AI 组在后续的理解测验中成绩很差：正确率 50% 对比人工组的 67%，而在调试题目上差距更大。有趣的是 AI 组内部的差异：那些用 AI 提问概念性问题的工程师得分超过 65%；而那些直接复制粘贴生成代码的工程师得分低于 40%。**决定结果的不是工具，而是你的姿态。** MIT 的 [Your Brain on ChatGPT](https://www.media.mit.edu/publications/your-brain-on-chatgpt/) 研究比较了使用大语言模型（LLM）、搜索引擎以及仅凭大脑写作论文的情况。EEG 测量显示，随着外部支持的增加，大脑连接性逐级下降。LLM 组的连接性最弱。写完论文后，83% 的 LLM 用户无法引用自己刚刚写出的任何一句话。研究人员将此称为“认知债务”：今天节省脑力，明天就要为批判性思维付出代价。 一项 [CHI 2026 研究](https://arxiv.org/html/2603.08849v1)补充了相关发现：当人们在任务开始时就能使用 LLM 时，LLM 会框定整个问题。即使人类后续完成了其余工作，这种初始锚定效应仍会导致明显更差的决策。操作顺序比 AI 使用的总量更为重要。 不同的方法，相同的结论。**在不主动有意学习的情况下使用 AI，会悄然削弱你赖以谋生的技能。** --- 如果你启动一个编码智能体并使用默认设置，一切只为一项指标优化：完成任务。模型写代码，你接受，循环重复。工具在任何时候都不会停下来问：“你怎么看这个问题？”或者“先自己试着写前五行。” 这不是什么阴谋，而是 UX 的惯性。产品团队因合并的变更和更短的周期而获得奖励，而不是因让你成为更优秀的工程师。我们都希望减少击键次数，所以工具磨平了摩擦。但问题在于，摩擦正是学习所在。 一些公司已经开始反击。Anthropic 为 Claude 推出了[学习模式](https://www.engadget.com/ai/anthropic-brings-claudes-learning-mode-to-regular-users-and-devs-170018471/)，采用苏格拉底式提问，在继续之前会要求你写代码。OpenAI 和 Google 也推出了类似功能。但几乎没人把它们用于真正的生产工作。我们悄悄地将它们归类为“给学生用的”，这是个错误。一个能帮大二学生学 React 的功能，同样适用于高级工程师学习 Rust。你只需要愿意再次像初学者一样。 --- ## “如果 AI 能做，我为什么需要理解？” 问得好。对于某些工作，答案是你确实不需要。如果是样板代码、胶水代码或你永远不会再看的临时 CI 脚本，交给 AI 就好。记忆 YAML 语法的机会成本太高了。 对于真正的软件，纯委派会在几个特定环节出问题。 **当出故障时。** AI 生成的代码和人类代码一样会崩溃。“智能体写的”这句话并不能帮你调试问题。团队中必须有人理解架构。 **当它自信地给出错误答案时。** LLM 会产生幻觉。面对一个看起来合理的错误答案，唯一的防御就是你足够的知识储备去发现它。 **当基础发生变化时。** 代码是暂时的，系统是永久的。当框架更新或安全审查发现结构性问题时，你不能靠重新输入提示词解决。你需要理解系统到足以迁移它的工程师。 **当你离开中位数时。** AI 在 GitHub 上被解决过百万次的问题上表现出色。你越偏离中位数，它的表现就越差。那些困难的、未文档化的问题——正是高级工程师高薪的理由——仍然需要深刻的理解。 **当市场调整时。** 自 2022 年以来[初级开发者就业率下降 20%](https://stackoverflow.blog/2025/12/26/ai-vs-gen-z/)并非偶然。那些只能靠 AI 交付、离开 AI 就无能为力的工程师，正在进入一个已经在重新定义专业价值的人才市场。 如果你用 AI 来跳过学习，你是在用一个稍微轻松的星期二，换取未来的竞争力。 --- ## 解决之道在于你如何提问，而非是否提问 好消息是，同一个产生认知债务的工具也能培养出更敏锐的工程师。区别在于你要求它们做什么。 **在提问前先形成假设。** 在要求修复之前，先写两三句话，说明你认为问题是什么。用模型的答案来检验你的理论，而不是取代它。 **先要解释，再要代码。** 在不熟悉的领域，你的第一个提示词应该是类似“请解释这是如何工作的，有哪些替代方案，以及它们的权衡。”只有在理解概念之后，才去要代码。 **当你不懂时，开启学习模式。** Claude 有学习模式，ChatGPT 有学习模式，Gemini 有引导式学习。没错，它慢一些。这正是目的所在。 **把 AI 输出当作初级工程师的 PR 来对待。** 阅读它，批评它，反驳它。你会仅仅因为测试通过就合并它吗？如果不是，这里也别这么干。 **时常手动推导。** 把模型给你写的一段代码，自己从头重新实现一遍。这是校准检查，能告诉你已经悄悄丢失了多少。 **让模型教你它刚刚做了什么。** 当它写了一个巧妙的函数后，问它用到了哪些概念，你需要读什么才能理解这个设计决策。多问一个问题，就能改变你从这次会话中获得的收获。 这些都不夸张。它们只是在你已经在用的同一个工具中，做出一些小的姿态调整。 --- ## 两个指标，而非一个 我开始在每次编码会话结束时问一个简单的问题：我今天学到了什么，还是只是关闭了工单？ 有时诚实的答案是“我只是关闭了工单”，这没关系。但如果连续几个月都是这个答案，那么认知债务就在暗中累积。 交付和学是两项不同的指标。你的经理和客户只会问第一个。第二个要靠你自己。 我宁愿只交付我能做的 80%，但学会了我需要学的 100%，也不愿相反。几年下来，这两种策略会造就截然不同的工程师。 你不必在使用 AI 和学习之间做选择。但你必须选择一种同时做到两者的工作流程，因为默认设置不会为你选。工具随时待命。你即将委派出去的下一个无聊任务，就是一个很好的起点。 --- *延伸阅读：Anthropic 的[技能形成研究](https://www.anthropic.com/research/AI-assistance-coding-skills)、MIT 的 [Your Brain on ChatGPT](https://www.media.mit.edu/publications/your-brain-on-chatgpt/)（arXiv [2506.08872](https://arxiv.org/abs/2506.08872)）、CHI 2026 论文 [LLM use under time constraints](https://arxiv.org/html/2603.08849v1)、Stack Overflow 的 [AI vs Gen Z 报告](https://stackoverflow.blog/2025/12/26/ai-vs-gen-z/)，以及我之前关于[理解债务](https://addyosmani.com/blog/comprehension-debt/)和[认知投降](https://addyosmani.com/blog/cognitive-surrender/)的文章。*