民间智慧对 AI 编程助手的看法分为两派。一方面，AI 让我们更高效——bug 修复了，功能上线了，产出翻倍了。另一方面，开发者的能力在悄悄地变弱——那些本该通过"挣扎"获得的深层理解，被 AI 的即时答案取代了。

---

一、一个安静的困境

我发现了一个让我不安的模式。

过去一年，我用 AI 工具写的代码比之前五年都多。

我在更短的时间内交付了更多的功能。bug 修复从一个小时压缩到十分钟。原型搭建从一天压缩到一个小时。我的 GitHub 贡献图比任何时候都绿。

与此同时，我发现自己越来越不愿意在没有 AI 的情况下写代码。

不是因为写不出来。而是因为没有 AI 陪着写，感觉格格不入。

这让我想起马奇在《经验的疆界》里提出的核心张力：经验既是最好的老师，又是傻瓜的老师。

AI 也是。它是我见过最高效的老师，也是让我最快停止思考的工具。

---

二、数据没有说话

过去一年，几项独立研究指向了同一个方向。

Anthropic 在 2026 年初做了一个随机对照实验。工程师们需要学习一个新的 Python 库，一半人带 AI，一半人不带。两组完成任务的速度几乎一样。但在理解力的测试中，AI 组的正确率只有 50%——比手动组的 67% 低了 17 个百分点。更值得关注的是 AI 组内部的分化：用 AI 来问概念的工程师得分超过 65%，而直接复制粘贴的工程师得分低于 40%。

工具没有决定结果。使用工具的姿态决定了结果。

MIT 的 “Your Brain on ChatGPT” 研究让三组人分别用 LLM、搜索引擎和纯大脑写文章。脑电图显示，外部支持越多，大脑连接度越低。LLM 组的大脑耦合度最弱。写完文章后，83% 的 LLM 用户无法复述自己刚刚写出的任何一句话。研究者称此为"认知债务"——今天省下的脑力，明天以思维能力的下降来偿还。

CHI 2026 的一篇论文发现了另一个值得注意的细节。当人们在一项任务开始时接触了 LLM，LLM 会"框定"整个问题的视角。即使之后的所有工作由人类独立完成，那个初始的锚定效应也产生了可测量的更差决策。

操作顺序比 AI 的使用总量更重要。

不同的方法论，同一个结论。没有主动学习意图地使用 AI，在悄悄削弱你赖以为生的技能。

---

三、工具的默认值是"交付"，不是"教育"

当你打开一个 AI 编程助手，使用默认设置，一切都被调校为一个指标：完成任务。

模型写代码。你点接受。循环重复。

在这个过程中，没有任何一个时刻，工具会停下来问"你觉得问题是什么？“或"先自己写五行试试？”

这不是阴谋。这是 UX 的天然倾向。产品团队因合并的代码和缩短的周期获得认可，而不是因为你成为了一个更锋利的工程师。我们都想减少击键次数，所以工具把摩擦全部打磨掉了。

问题是，摩擦恰恰是学习发生的地方。

爱比克泰德在《手册》里说：假如你想做事，就得养成做事的习惯。

学习的习惯，也只有在"做事"的过程中才能形成。当 AI 替你做了事，习惯就没有被养成的机会。

一些公司开始意识到这个问题了。Anthropic 在 Claude 中推出了学习模式，使用苏格拉底式的提问方法，在给出答案之前让你自己先写代码。OpenAI 和 Google 也推出了类似的功能。

几乎没有人真正在生产环境中使用它们。

我们悄悄地给它们贴上了"给学生用的"标签。这很可惜。一个帮助大一学生学习 React 的功能，同样可以帮助一个十年经验的老工程师学习 Rust。你只需要愿意再次像一个初学者那样感到笨拙。

---

四、“如果 AI 能做，我为什么还需要理解？”

这是一个合理的问题。

对于某些工作，你的确不需要。如果是样板代码、胶水代码、或者永远不会再看第二遍的 CI 脚本，交给 AI 去做。记住 YAML 语法的机会成本太高了。

但对于真正的软件开发，纯粹的委托在几个点上会失效。

当代码出问题的时候。 AI 生成的代码和人类写的代码一样会崩溃。"Agent 写的"这种解释对你调试没有任何帮助。团队里总有一个人需要理解架构。

当模型自信地给出错误答案时。 LLM 会产生幻觉。对抗一个看起来合理但不正确的答案的唯一防线，是足够的领域知识去发现它。

当基础发生变化时。 代码是暂时的，系统是永恒的。当框架升级，或者安全审查标记了一个结构性问题时，你不能靠重新提示来解决。你需要那些真正理解系统、能够帮助它度过迁移期的工程师。

当你离开中位数的时候。 AI 在那些已经被在 GitHub 上解决了一百万次的问题上表现得极其出色。你离中位数越远，它的表现越差。那些困难的、没有文档记录的问题——那些证明了高级工程师收入合理性的问题——仍然需要深层的理解。

当市场开始重新定价的时候。 2022 年以来初级开发者就业率 20% 的下降，不是巧合。那些只能靠 AI 才能写代码、没有 AI 就无法独立工作的工程师，正在进入一个已经开始重新评估"专业能力"价值的劳动力市场。

如果你用 AI 来跳过学习，你是在用未来的竞争力换取一个稍稍轻松的周二下午。

---

五、亦此亦彼：如何使用 AI 而不变笨

好消息是：同样的工具可以产生认知债务，也可以塑造更锋利的工程师。

区别在于你的姿态。

在提问之前，形成自己的假设。 在请求修复之前，写下两三句话描述你认为问题是什么。用模型的回答来检验你的理论，而不是替代它。

在请求代码之前，先请求解释。 在不熟悉的领域，你的第一个提示应该是"解释这是如何工作的，有什么替代方案，各有什么权衡"。在你理解了概念之后，再请求代码。

在你不熟悉的领域，开启学习模式。 Claude 有，ChatGPT 有，Gemini 也有。是的，这会让你的速度慢下来。但那就是重点。

把 AI 的输出当成初级工程师的 PR。 阅读它。质疑它。反驳它。如果测试通过了你就合并，那在人类同事的 PR 上你也会这样做吗？

偶尔亲手还原一遍。 挑一段 AI 为你写的代码，尝试从零把它重新写出来。这是告诉你"你悄悄失去了多少"的校准检查。

让模型教会你它刚做的事。 在它写了一个巧妙的函数之后，问问它用了什么概念，你需要读什么才能理解这个设计选择。多一句话，你从这次会话中带走的东西就会完全不同。

这些都不是什么剧烈的改变。它们是你已经在使用的工具内部，一些小姿态的调整。

---

六、两个指标

我最近养成了一个习惯。每次编码会话结束时，我问自己一个问题：我今天学到了什么，还是只是关闭了工单？

有时候诚实的答案是"我只是关闭了任务"。这没问题。

但如果这个答案持续几个月，认知债务就在悄悄地累积。

交付和学习是两个不同的指标。你的经理和你的客户永远只在乎第一个。第二个，只能靠你自己。

我宁愿交付我可能交付的 80%，然后学到我需要学的 100%、——而不是反过来的那个比例。几年下来，这两种策略会塑造出截然不同的工程师。

---