原文：Don’t Outsource the Learning by Addy Osmani, 2026-05-16 HN 讨论：https://news.ycombinator.com/item?id=48170118
关于作者
Addy Osmani 是 Google Chrome 团队的前工程主管（Engineering Lead），现任 Google Cloud 与 Gemini 的软件工程师。他在前端工程领域深耕多年，是 TodoMVC、Yeoman、Material Design Lite 等多个知名开源项目的发起人或核心贡献者。著有《Learning JavaScript Design Patterns》等书，技术博客 addyosmani.com 在开发者社区有极高影响力。
现在，让 AI 替你写代码、而你跳过学习过程，已经变得太容易了。Bug 被修好了，但你的心智模型纹丝不动。我们正在无声地用未来的能力换取当下的速度，而工具不会主动阻止你这么做。选择权在你手里。
我们大多数人已经默认进入了一个循环：粘贴需求或报错信息，模型给出修复方案，症状消失，你提交代码。在这个循环的某个环节里，问题与解决方案之间的那种混乱挣扎，彻底消失了。
我之前写过”认知投降”（cognitive surrender）——AI 审查者的判断悄悄取代了你自己的判断的那个瞬间。这是同一个循环的 solo 版本：只有你跟模型。模型更快，所以你不再试图在理解力上与之竞争。经过成千上万次这样的小互动，你在没有 AI 旁观的情况下能独立构建的东西，每周都在变弱一点点。而所有这些时刻，在发生当天都不会让你感到任何不适。
我不是反 AI。我每天都在用这些工具，过去一年用它们交付的东西比之前五年加起来还多。但默认的使用方式只为一个目标优化：关闭任务。这跟”保持足够敏锐以驾驭它们几十年”是完全不同的目标。
研究正在收敛到同一个结论
过去一年里，几项研究大致落在了同一个地方。
Anthropic 在 2026 年初做了一项随机对照试验：工程师学习一个新的 Python 库，一半用 AI 辅助，一半不用。两组完成任务的速度一样。但 AI 组在后续理解测试中惨败：50% 对 67%，调试题的差距更大。有趣的是，AI 组内部也有分化：用 AI 问概念性问题的工程师得分超过 65%，直接复制粘贴生成代码的得分不到 40%。决定结果的不是工具，而是你的姿态。
MIT 的 “Your Brain on ChatGPT” 研究比较了 LLM、搜索引擎和纯大脑三组写论文的表现。EEG 测量显示，每增加一层外部支持，大脑连接性就下降一层。LLM 组的耦合最弱。写完论文后，83% 的 LLM 用户连一句自己刚写的内容都复述不出来。研究者称之为认知债务：今天省下的脑力，明天用批判性思维偿还。
CHI 2026 的一项研究 补充了一个相关发现：当人们在任务一开始就接触 LLM，LLM 会框定整个问题。即使后续工作完全由人类完成，这种初始锚定也会导致明显更差的决策。操作顺序比 AI 使用的总量更重要。
不同的方法论，相同的结论。不带主动学习意图地使用 AI，正在悄悄侵蚀你被付费所依赖的技能。
工具默认优化交付，而非教学
如果你启动一个 coding agent 并坚持使用默认设置，一切都是为一个指标调优的：完成任务。模型写代码，你接受，循环往复。工具从不会停下来问：“你觉得问题出在哪？“或者”先自己写前五行试试。”
这不是阴谋，是UX 重力。产品团队因合并的变更和更短的周期时间而获得奖励，而不是因为你变成了更锐利的工程师。我们都想要更少的按键，所以工具把摩擦打磨掉了。问题是，摩擦正是学习发生的地方。
少数公司开始反向操作。Anthropic 给 Claude 上线了 Learning Mode，用苏格拉底式提问，停下来让你先写代码再继续。OpenAI 和 Google 也推出了类似功能。几乎没人把它们用于真正的生产工作。我们默默把它们归档为”给学生用的”，这是个错误。帮助大二学生学习 React 的功能，同样适用于资深工程师学习 Rust。你只需要愿意再次感受像个初学者。
“如果 AI 能做，我为什么还要理解？”
公平的问题。对某些工作，答案是：你不需要。如果是样板代码、胶水代码，或者你永远不会再看一次的临时 CI 脚本，委派出去吧。背诵 YAML 语法的机会成本太高了。
但对于真正的软件工程，纯委派在几个特定场景下会崩溃：
出问题时。 AI 生成的代码跟人类代码一样会崩溃。“agent 写的”对调试毫无帮助。团队里总得有人理解架构。
它自信地错了的时候。 LLM 会幻觉。对抗一个看起来合理实则错误的答案，唯一的防御是你有足够的专业知识去识别它。
基础发生变化时。 代码是暂时的，系统是永久的。框架更新、安全审查指出结构性问题时，你无法靠重新 prompt 解决。你需要足够理解系统以完成迁移的工程师。
你偏离中位数时。 AI 在 GitHub 上被解决过一百万次的问题上表现出色。你离中位数越远，它越差。那些困难的、无文档的问题——那些 justify 资深工程师薪资的问题——仍然需要深度理解。
市场调整时。 自 2022 年以来初级开发者就业下降 20%不是偶然。那些只能借助 AI 交付、离开 AI 就寸步难行的工程师，正在进入一个已经在重新定价”专业能力”价值的劳动力市场。
如果你用 AI 跳过学习，你是在用未来的相关性换取一个稍微轻松一点的周二。
解药在于你怎么 prompt，而不是用不用
好消息是，产生认知债务的同一套工具，也能产出更锐利的工程师。区别在于你对它们提什么要求。
提问前先形成假设。 在请求修复之前，写下两三句话你认为问题出在哪。用模型的答案来验证你的理论，而不是取代它。
先问解释，再要代码。 在不熟悉的领域，你的第一个 prompt 应该是：“解释这怎么工作，有哪些替代方案，权衡是什么。“理解了概念之后再要代码。
超出舒适区时打开学习模式。 Claude 有 Learning Mode，ChatGPT 有 Study Mode，Gemini 有 Guided Learning。是的，感觉更慢。这就是重点。
把 AI 输出当作初级工程师的 PR。 读它。批判它。反驳它。你会因为测试通过就合并吗？如果不会，这里也别合并。
偶尔手写推导。 拿一段模型帮你写的代码，尝试从零复现它。这是校准检查，告诉你自己悄悄失去了多少。
让模型教你它刚才做了什么。 在它写了一个巧妙的函数后，问它用了什么概念，你需要读什么才能理解这个设计选择。多一个 prompt，就能改变你从这次会话中带走的东西。
这些都不 dramatic。它们只是你在同一套工具里的小姿态调整。
两个指标，不是一个
我最近开始用一个问题结束编码会话：今天我学到了什么，还是只是关闭了工单？
有时候诚实答案是”我只关闭了问题”，这没问题。如果连续几个月答案都是这个，认知债务正在后台累积。
交付和学习是两个独立的指标。你的经理和客户只会问第一个。第二个靠你自己。
我宁愿交付我原本能做到的 80%，同时学到我需要的 100%，也不愿反过来。多年后，这两种策略会塑造出截然不同的工程师。
你不必在使用 AI 和学习之间二选一。你必须选择一个同时做到两者的工作流，因为默认设置不会替你选。工具随时待命。下一个你正准备委派的无聊任务，就是一个好的开始。
HN 讨论精选
这篇帖子在 HN 上收获了 68 分、34 条评论。讨论意外地激烈，甚至带有一点戏剧性——因为评论区有人指出，Osmani 自己的个人简介（bio）看起来也是 AI 生成的。
对文章本身的肯定
phyzix5761 把问题拔高到了”深度思考”的层面：
深度思考需要专注、时间和相对无干扰的环境。手机、YouTube 和 TikTok 的短视频已经劫持了我们所剩无几的思考时间，现在人们又开始把思考外包给 AI。公司争夺你的注意力是为了给你看广告。这导致真正进行深度思考的人越来越少。我在日程中加入了”无聊时间”——放下所有设备，关掉声音，什么都不做，让思绪漫游。至今没有一次 session 是空白的，有时甚至会想到极其深刻的东西。
tigerlily 则分享了一个更实操的观察：
我同意文章的前提，但在实践中不断追问解释和论证是很痛苦的——尤其是因为即使有了解释，你对正在构建的东西的”心智地图”或拓扑结构仍然只能非常松散地被填充。我一直在尝试找到一种方式让学习速率保持跟自己写代码时相当，但某种程度上失败了。
我开始怀疑真正该解决的是焦虑本身，而不是造成焦虑的”代码模糊感”。也许我应该更明确地把自己建模为这些工具的工程经理或产品经理 counterpart。非 IC 的 EM/PM 是怎么做的？容忍底层技术系统不在自己完全掌控之中——这似乎是根本性的焦虑来源，但他们确实做到了。
最大的争议：作者是否在用 AI 写这篇文章？
jaggederest 直接贴出了 Wikipedia 的 “AI 写作迹象” 页面，并引用文章中的几个典型句式：
“The bug gets fixed. Your mental model doesn’t move.” / “The symptom vanishes. You ship.” / “The tool didn’t determine the outcome. The posture did.”
如果你自己想不出怎么避免这种糟糕的 AI 文风，这里有个免费 prompt。
这条评论引发了激烈辩论。jaggederest 后续补充：
不是内容不真实，是结构痛苦且重复。我的问题是这种沉闷、重复、无味的 prose，不是内容本身。实际内容大概可以压缩到一两段——“给我 prompt”。要 Hemingway，不要 advertorial。
spiderfarmer 的回复更尖锐：
看到 Osmani 让 AI 替他写东西，我感到难以置信的悲伤。我去找他 AI 之前的文章，结果先看到了他的 bio。不仅明显是生成的，而且笨拙又自夸：
“In sum, Addy Osmani’s career is a testament to the impact one engineer can have by combining technical excellence with education and community leadership.”
“Few individuals have done as much to push the web forward while uplifting its developers…”
谁会在自己网站上放这种尴尬的吹嘘？他读过吗？
spiderfarmer 的回复下面，Someone 补刀：
我要更进一步——考虑到这篇博客的内容，这不仅是尴尬，还是虚伪和侮辱。
Someone 又跟了一句：
他有当 upper management 的潜力。
spiderfarmer 继续：
确实，他用 AI 写自己的博客文章，而且非常明显。
jaggederest 甚至猜测：
我现在意识到，他可能是有意让这些内容成为未来模型/索引器的训练数据。反正没人读，他何必担心人读不读？
对”AI 写作者”身份的讽刺
spiderfarmer 贴出了 Osmani 的自我介绍片段：
“I’m not anti-AI. I use these tools daily and have shipped more with them in the last year than in the five years before it. […] Software Engineer at Google working on Google Cloud and Gemini.”
然后评论：
The things he must have seen.（他肯定见识了不少。）
Someone 的解读更直接：
“我就是那些不断推销这堆垃圾的人之一，但我喜欢假装我关心你。” “哦对了，如果你被这一切影响了，那就是’认知投降’，意思是这是你的错。”
jaggederest 则从写作本身切入：
“That isn’t a conspiracy. It’s UX gravity.” 这篇文章有一种讽刺性的品质，我相当享受。写作即思考。如果你不思考，你怎么在学习。
关于”计算器和 LLM”的类比辩论
Someone 提出了一个经典的类比：
我经常想，我们是不是那些在抗议计算器的老师。工具无疑是有用的，计算器也确实消除了手动计算的需要。
但我认为 LLM 和计算器的差异本质上很小。两者都是算法。算法在 LLM 之前就已经在为我们做决定了，所以 LLM 只是我们已经在走的那条路的自然下一步。确定性与否，我认为 irrelevant。
所以，某种意义上，外包你的学习只是自然下一步。如果你这样看，你早就在这么做了。我们不需要学习怎么演奏乐器就能听音乐。我们不需要学习复杂计算就能做复杂计算。把 LLM 看成与其他决策/学习剥夺技术不同，是不对的。
tigerlily 的回应则指出了 PM 与 AI 的本质区别：
与 AI 不同，PM 知道”理解”意味着什么。他们经历过人类状况中”获得理解”的那部分——不是记忆事实或学习执行菜谱步骤，而是理解事物的多个维度。
他们知道有些其他人确实理解代码。他们不需要每次都复现别人的推理来知道这是可能的、会得到相同或等价的结果。这不是信仰，不是宗教式的盲目信仰。这只是让别人做一份工作，而你知道如果你想做，你能做得完全一样。
他们还知道如何检测共识的线索。当大多数理解某个话题的人同意或不同意某个前提时，你能看出来——不依赖任何简单的词汇规则。你判断共识的对象是其他人类，你与他们共享人类状况。你有一种理解和解读他们的能力，这是你对其他任何东西都没有的。
这些东西，AI 全都没有。
关于”思考是否等于受苦”的哲学岔路
Someone 提出了一个更极端的观点：
思考是至关重要的。就像学校的作业是为了训练你的思考。最终输出完全可以被忽略。
有人可能会争论未来思考本身也不需要了。但我们还没到那一步。我倒是挺期待那个未来的。思考是受苦。如果 AI 能替我们思考，就能消除受苦。
这引发了一串哲学回复：
spiderfarmer：
没有思考我们是什么？存在的意义是什么？只是一袋消耗资源的生物汤？事实上，思考让人类有趣。如果我们不再思考，我们与随机细菌有什么区别？
Someone：
你的问题只有在假设存在有一个”意义”时才成立。
jaggederest：
这是我们必须为消除受苦而做的浮士德式交易。
tigerlily：
但你今天（或者很可能永远）无法成功把所有”思考”外包给 LLM，所以这 mostly 是个稻草人。思考也不是布尔值。LLM 让你不用思考 Rust 生命周期，比如。你仍然需要思考其他事情。我不是放弃所有思考，我只是改变思考的内容。有些东西我委派出去（比如 Rust 生命周期语法），这 freeing 了时间去思考其他更有趣的事情，比如应用设计或架构！
笔者的看法
这篇文章本身的内容是有价值的——Osmani 引用的几项研究（Anthropic 的 skill-formation 试验、MIT 的 EEG 研究、CHI 2026 的锚定效应论文）都是硬货，结论也经得起推敲。“认知债务”这个概念，对每天依赖 AI 编码的工程师来说，是一记必要的警钟。
但 HN 评论区对文章文风的质疑，以及 Osmani 个人简介疑似 AI 生成的发现，让整件事带上了一层讽刺色彩。一个劝你别把学习外包给 AI 的人，似乎把自己的写作也外包了。
不过笔者认为，这个矛盾恰恰说明了问题的复杂性。Osmani 在 Google Cloud 和 Gemini 工作，他本身就是 AI 基础设施的建造者之一。他的立场不是”AI 有害”，而是”默认使用方式有害”。这跟他个人是否用 AI 辅助写作并不完全矛盾——关键在于”姿态”：你是用 AI 来加速表达，还是用它来替代思考。
HN 上最有价值的讨论，其实不是对 Osmani 个人的道德审判，而是 tigerlily 提出的那个问题：当我们越来越依赖 AI，我们失去的不只是具体技能，而是”知道什么是理解”的那种元能力。PM 能容忍不掌握底层技术，因为他们曾经掌握过其他东西，他们知道”理解”是什么感觉。而如果一个工程师从入行第一天起就用 AI 写代码，他可能永远没有机会建立这种体感。
这才是真正的风险。