编者按：本文由 Google Cloud AI 总监、前 Chrome Eng. 主管 Addy Osmani 在 X 上发表。

英文原文：https://x.com/addyosmani/status/2056078124346228860

现如今，让 AI 写代码而自己跳过学习过程，实在太容易了。Bug 确实被修复了，但你的心智模型（mental model）却毫无长进。假以时日，情况可能会变得更糟。我们在悄无声息地用未来的能力换取眼前的速度，而工具本身绝不会强迫我们改变这种现状。改变，只能源于你自己。

我们大多数人都已陷入一种默认的循环：粘贴需求说明或报错信息，模型给出一个修复方案，表面症状随之消失，然后你直接发布上线。在这个循环的某个环节中，原本存在于“问题”与“解决方案”之间那种乱麻般的挣扎与思考，彻底消失了。

我以前写过关于“认知让渡”（cognitive surrender）的文章——即 AI 审查员的判断悄然取代你自我判断的那一刻。而上述过程，仅仅是那个循环的“单机版”：只有你和模型。因为模型速度更快，所以你不再试图在理解力上与它较劲。在成千上万次这样的小型交互中，一旦没有 AI 在背后盯着，你实际手写代码的能力每周都在悄悄退化。而在这些情况发生的那一天，你丝毫不会觉得这是个问题。

我并不反 AI。我每天都在使用这些工具，并且在过去一年里借助它们交付的成果，比以往数年都要多。但是，我们使用它们的默认方式只为了一件事而优化：那就是“完结任务”。

然而，这与“保持敏锐度，从而在漫长的职业生涯中驾驭这些工具”的目标，截然不同。

各项研究正得出相同的结论

过去一年里的多项研究，都得出了大致相同的结论。

Anthropic 在 2026 年初进行了一项随机对照试验，让工程师们学习一个新的 Python 库，一半人使用 AI 辅助，另一半人则纯手工。两组完成任务的速度相同。但 AI 组在随后的理解测试中惨败：得分率仅为 50%，而纯手工组为 67%，并且在调试（debugging）环节的差距更大。有趣的是 AI 组内部的差异：使用 AI 询问概念性问题的工程师得分超过 65%；而直接复制粘贴生成代码的工程师得分则低于 40%。决定结果的不是工具，而是使用者的姿态。

麻省理工学院（MIT）的一项名为“ChatGPT 状态下的大脑”（Your Brain on ChatGPT）的研究，对比了使用大语言模型（LLM）、使用搜索引擎以及纯靠大脑写作的三组人群。脑电图（EEG）测量显示，随着外部支持层级的增加，大脑连通性呈下降趋势。LLM 组的大脑耦合度最弱。写完文章后，83% 的 LLM 用户甚至无法背诵出自己刚写出的一行字。研究人员将此称为“认知债务”：今天省下了脑力，明天就要用批判性思维的衰退来偿还。

CHI 2026 的一项研究补充了一个相关的发现。当人们在任务开始时就使用 LLM 时，LLM 会直接框定整个问题的解决思路。即使后续剩下的工作全由人类自己完成，这种最初的“锚定效应”也会导致决策质量显著下降。操作的先后顺序，比 AI 的总使用量影响更大。

不同的研究方法得出了相同的结论：如果没有主动学习的意图，过度使用 AI 会在不知不觉中削弱你安身立命的专业技能。

工具的默认选项是“交付”，而非“教学”

如果你启动一个代码智能体（coding agent）并坚持使用默认设置，你会发现一切只为一个指标服务：把活干完。

模型写代码，你点击接受，如此循环往复。工具绝对不会在任何时候停下来问你：“你认为问题出在哪里？”或者“要不你自己试着写前五行？”

这就是当前用户体验的“地心引力”所在。产品团队的考核指标是代码合并量和周期缩短率，而不是把你培养成一个更敏锐的工程师。大家都想少敲几次键盘，所以工具已经把所有的“摩擦力”都打磨平滑了。但问题在于，学习的过程往往就隐藏在这些“摩擦力”之中。

少数几家公司已经开始尝试打破这种不鼓励真正学习的死循环。

Anthropic 为 Claude 推出了“学习模式”（Learning Mode），它采用苏格拉底式的提问，并在继续往下走之前停下来让你自己写代码。OpenAI 和 Google 也推出了类似的功能。但坦白讲，几乎没有人会在真正的生产工作中使用它们。我们潜意识里把这些功能归类为“学生专属”，这是个大错特错的想法。能帮助大二学生学习 React 的功能，同样能帮助资深工程师学习 Rust。你只需要放下身段，愿意再次体验做初学者的感觉。

“既然 AI 能搞定，我为什么还要去理解它？”

问得好。对于某些工作，答案是：也许……你真的不需要。如果是样板代码（boilerplate）、胶水代码（glue code），或者是你再也不会看第二眼的、用完即弃的 CI 脚本，那就把它外包给 AI 吧。死记硬背某些语法的机会成本太高了。

但对于真正的软件工程而言，在以下几个特定场景中，纯粹的“外包”是行不通的：

• 当系统崩溃时。 AI 生成的代码和人类写的代码一样会崩溃。“代码是 Agent 写的”这种理由对调试问题毫无帮助。团队中必须得有人真正理解系统架构。
• 当 AI 一本正经地胡说八道时。 LLM 依然会产生幻觉。面对看似合理实则错误的答案，唯一的防线就是具备足以识破它的专业知识。单纯依靠技能包、CLI 等“创可贴”式的修补，终究走不远。
• 当底层基础发生改变时。 代码是暂时的，而系统是长期的。当框架更新，或安全审查暴露出结构性问题时，你无法靠重新写一句提示词（Prompt）就能蒙混过关。你需要对系统了如指掌的工程师来主导迁移。
• 当你偏离“中位数”时。 AI 非常擅长解决 GitHub 上被解决过上百万次的问题。但你越是偏离常规，它的表现就越糟。那些棘手的、没有现成文档的问题，也就是那些能证明资深工程师薪资物有所值的问题，依然需要深度的理解力。
• 当市场开始调整时。 那些离开 AI 就无法交付代码的工程师，正在进入一个重新评估“专业知识价值”的劳动力市场。如果你用 AI 来逃避学习，你实际上是在用稍微轻松一点的周二，去透支未来职场的核心竞争力。

破局之道：改变你的提示词方式

好消息是，产生“认知债务”的工具同样能塑造出更敏锐的工程师。区别仅仅在于，你是如何向它们发问的。

• 提问前先建立假设。 在请求修复代码之前，先写下两三句话，说明你认为问题出在哪儿。用模型的回答来验证你的推测，而不是直接取代它。
• 先求解释，再要代码。 在陌生的领域，你的第一句提示词应该是类似于“解释一下它是如何运作的，有什么替代方案，以及各有什么权衡（tradeoffs）。”只有在你理解了核心概念之后，再要求生成代码。
• 在超出能力范围时开启“学习模式”。 没错，这会让你感觉效率变慢了。但重点恰恰就在于此。
• 把 AI 的输出当成初级工程师提交的 PR。 阅读它，批判它，反驳它。你会仅仅因为测试通过了就去合并初级工程师的代码吗？如果不会，在这里也别盲目合并。
• 偶尔手动推导一次。 拿一段模型为你写的代码，试着从头开始自己重写一遍。这是一种“标定检查”（calibration check），能让你清楚地知道自己在不知不觉中退化了多少。
• 让模型教你它刚刚做了什么。 在它写出一个巧妙的函数后，问问它使用了哪些概念，以及你需要阅读哪些资料才能理解这个设计选择。多加一句提示词，你从这次互动中获得的收获将截然不同。

这些改变并不算惊天动地。它们只是在你每天都在使用的工具中，做出的微小姿态调整。

两个指标，而非一个

我现在结束一天的编程工作时，都会问自己一个简单的问题：今天我是学到了新东西，还是仅仅关闭了几个 issue？

有时候诚实的回答是“我只是关闭了几个 issue”，这没关系。但如果连续几个月答案都是如此，那么“认知债务”就已经在后台默默堆积了。

“交付”和“学习”是两个完全独立的指标。你的经理和客户永远只会关心第一个。而第二个，只能靠你自己。

我宁愿只交付我本能完成的 80%，去百分百学习我需要掌握的知识，也不愿反其道而行之。日积月累，这两种策略塑造出的工程师将有天壤之别。

你大可不必在“使用 AI”和“学习”之间二选一。但你必须主动选择一个兼顾两者的工作流，因为默认设置绝不会替你做这个选择。只要你准备好了，工具随时待命。

你准备“外包”出去的下一个无聊任务，或许就是一个不错的起点。