📝 新增《不要把学习外包给 AI》文章

Author: bd-dxg

.vitepress/configs/sidebar.mts

@@ -62,6 +62,10 @@ export default {
     }
   ],
   '/Lives/': [
+    {
+      'text': '不要把学习外包给 AI',
+      'link': '/Lives/DontOutsourceLearning'
+    },
     {
       'text': '程序员从幼稚走向成熟的标志',
       'link': '/Lives/SuccessfulMarketing'

Article/Lives/DontOutsourceLearning.md

@@ -0,0 +1,95 @@
+# 不要把学习外包给 AI
+
+> 作者: Addy Osmani 原文链接：[Don't Outsource the Learning](https://addyosmani.com/blog/dont-outsource-learning/)
+
+---
+
+> [!WARNING] 警示
+> 现在，让 AI 写代码、自己跳过学习，实在太容易了。Bug 是修好了，但你对问题的理解一步没进。 我们正在悄悄地用未来的能力换取眼前的效率，而工具本身不会逼你改变。这件事，只能靠你自己。
+
+![](/imgs/1780028324720.avif)
+我们大多数人已经陷入了一个默认的循环：把需求说明或报错信息粘贴进去，模型给出解决方案，问题消失，代码上线。在这个循环里，那段在问题和答案之间苦苦摸索的过程，已经彻底消失了。
+
+我曾经写过"[认知投降](./CognitiveSurrender)"这个现象——就是 AI 审阅者的结论悄悄取代了你自己的判断。现在说的，是同一个陷阱的单机版：只有你和模型。模型更快，所以你干脆放弃了在理解层面与它较劲。经历了成千上万次这样微小的交互之后，你在没有 AI 搭把手的情况下能真正完成的事，每周都在悄悄缩水。而这每一次，在当下都感觉不到有什么问题。
+
+我并不反对 AI。我每天都在用这些工具，过去这一年靠它们完成的工作，比之前好几年加起来还多。但我们使用它们的默认方式，只针对一件事做了优化：完成任务。而这个目标，和"保持足够敏锐、能够在漫长的职业生涯中持续掌舵"，完全是两码事。
+
+## 研究结论，指向同一个方向
+
+![](/imgs/1780028324712.avif)
+过去一年，几项研究几乎得出了相同的结论。
+
+Anthropic 在 2026 年初做了一项随机对照实验，让工程师学习一个新的 Python 库，一半人使用 AI 辅助，另一半不用。两组人完成任务的速度相差无几。但在随后的理解测验中，AI 组惨败：得分仅 50%，而手动组达到 67%，在调试题上差距更大。更有意思的是 AI 组内部的分化：那些用 AI 追问概念问题的工程师，得分超过 65%；而直接复制粘贴生成代码的，得分不到 40%。**结果的差异不在于工具，而在于使用姿态。**
+
+MIT 的《你的大脑与 ChatGPT》研究对比了三组人的写作表现：使用大语言模型、使用搜索引擎、以及全靠自己。脑电图显示，外部辅助越多，大脑的连接活跃度越低。LLM 组的耦合度最弱——写完文章之后，83% 的 LLM 用户连自己刚写了什么都记不住一句话。研究者把这称为"认知负债"：今天省了脑力，明天就要用批判性思维来偿还。
+
+2026 年 CHI 会议上的一项研究还发现了一个相关现象：如果任务一开始就有 LLM 介入，它会塑造整个问题的框架。即便后续工作全由人类自己完成，这个"先入为主"的锚定效应，仍然会让最终决策质量显著下降。不是 AI 用了多少，而是在什么时候用，才是关键。
+
+不同的研究方法，指向了相同的结论：**在没有主动学习意图的情况下使用 AI，会悄然腐蚀你赖以为生的核心技能。**
+
+## 工具默认的目标是交付，而不是成长
+
+![](/imgs/1780028324715.avif)
+如果你打开一个 AI 编程助手，一切都被调校成只盯着一个指标：把任务搞定。
+
+模型写代码，你接受，循环继续。整个过程中，没有任何地方会有人停下来问你："你自己觉得问题出在哪？"或者"先试着自己写开头五行？"
+
+这就是当前产品的引力方向。研发团队靠合并代码、缩短周期来获得认可，而不是靠让你成为更好的工程师。我们都想少打几个字，于是工具把摩擦力磨平了。但问题是，那些摩擦，恰恰是学习生长的地方。
+
+也有公司在尝试反其道而行之。Anthropic 为 Claude 推出了"学习模式"——用苏格拉底式问答引导用户，在给出代码之前先让你自己动手写写看。OpenAI 和 Google 也推出了类似的功能。但说实话，几乎没人把这些功能用在真实的生产工作中。我们默默地把它们归入"学生专用"一栏，这是个错误。帮大二学生学 React 的功能，同样适合资深工程师学 Rust。只是你得愿意再次以初学者的姿态去面对它。
+
+## "AI 都能做了，我为什么还要懂？"
+
+这个问题问得很合理。对于某些工作，答案是：也许……你真的不需要懂？如果只是样板代码、粘合代码，或者一个用完即弃的流水线脚本，大胆交给 AI 就好。为了记一些语法而付出的机会成本，实在太高了。
+
+但对于真正的软件工程，单纯的外包在几个关键时刻会彻底失效：
+
+**出了问题的时候。** AI 生成的代码照样会崩。"是 AI 写的"这句话，帮不了你 debug。团队里必须有人真正理解系统架构。
+
+**AI 自信地说错了的时候。** 大语言模型至今仍会出现幻觉。对抗一个听起来有道理却完全错误的答案，唯一的武器是你自己足够深的专业积累。
+
+**技术基础发生变化的时候。** 代码是暂时的，系统是长期的。当框架升级、或安全审查揭示出结构性问题，你没法靠"再提示一遍"逃出生天。你需要真正理解这个系统的工程师来推动迁移。
+
+**走出"大多数"的时候。** AI 最擅长解决在 GitHub 上被做过一百万遍的问题。你越偏离主流，它就越力不从心。那些艰深的、没有文档记录的问题——正是高级工程师薪水背后的价值所在——仍然需要深厚的理解。
+
+**当市场重新定价的时候。** 那些只能借助 AI 完成工作、一旦离开 AI 就不行的工程师，正在进入一个已经开始重新评估"专业能力值多少钱"的就业市场。用 AI 来逃避学习，是在用未来的竞争力换今天轻松的周二下午。
+
+## 改变，从提问方式开始
+
+![](/imgs/1780028324661.avif)
+好消息是，同样的工具，既可以制造认知负债，也可以把你磨得更锐利。关键在于你向它要什么。
+
+**先形成自己的判断，再去提问。** 在请求解决方案之前，先用两三句话写下你认为问题在哪。用模型的答案来验证你的判断，而不是替代它。
+
+**先要解释，后要代码。** 在陌生的领域，第一个问题应该是："解释一下这是如何工作的，有哪些替代方案，各自的权衡是什么。"等你真正理解了概念，再去要代码。
+
+**在你力不从心的时候，打开学习模式。** 是的，它会更慢。这正是重点。
+
+**把 AI 的输出当成初级工程师的 PR 来对待。** 认真读，提出质疑，推回去。如果只是因为测试通过你就会合并，那就不应该这样做。
+
+**偶尔自己从头推导一遍。** 拿一段模型为你写的代码，试着自己从零复现。这是一个校准测试，让你看清自己悄悄失去了多少。
+
+**让模型解释它刚才做了什么。** 在它写完一个精巧的函数之后，追问它用了哪些概念、要真正理解这个设计决策需要读什么。多一个提问，让你从这次对话中带走的东西完全不同。
+
+这些都不是什么大动作，只是在你已经在用的工具里，调整一下使用的姿态。
+
+## 两个指标，缺一不可
+
+![](/imgs/1780028324718.avif)
+我开始在每次编程结束时问自己一个简单的问题：_今天我学到了什么，还是只不过关掉了几个 issue？_
+
+有时候诚实的答案是"只是关掉了 issue"，这没什么。但如果连续几个月的答案都是这个，认知负债就已经在后台悄悄积累了。
+
+"交付"和"成长"是两个独立的指标。你的经理和用户只会问第一个。第二个，由你自己负责。
+
+我宁可交付 80% 本可以完成的，换来 100% 需要学到的；也不愿意倒过来。放眼多年，这两种策略培养出来的，是截然不同的工程师。
+
+你不必在"使用 AI"和"持续学习"之间二选一。但你必须主动选择一种两者兼顾的工作方式——因为那些默认设置，不会替你做这个选择。
+
+工具随时准备好了。
+
+那个你本来打算交出去的下一个"无聊任务"，就是最好的起点。
+
+---
+
+_延伸阅读：Anthropic 的[技能习得研究](https://www.anthropic.com/research/AI-assistance-coding-skills)、MIT 的[《你的大脑与 ChatGPT》](https://www.media.mit.edu/publications/your-brain-on-chatgpt/)、CHI 2026 关于[时间压力下 LLM 使用](https://arxiv.org/html/2603.08849v1)的论文，以及作者此前的文章[《理解负债》](https://addyosmani.com/blog/comprehension-debt/)与[《认知投降》](https://addyosmani.com/blog/cognitive-surrender/)。_