近期，Anthropic 发布了一项研究，标题虽然较长，但核心问题十分简洁：AI 辅助编写代码，究竟是提升效率，还是让你更慢地掌握知识？

这里有一个略显反直觉的结论：借助 AI，某些任务的速度确实能提升 80%，但“做得快”与“学得会”之间，可能横亘着一条微妙的鸿沟。更直白地说，你是否发现自己很久没有完整、从头到尾读完一篇文章或一篇论文了？是不是习惯了打开 AI 总结，觉得“知道了”就匆匆划走？这种从“获取知识”到“掌握技能”的转变，正是这项研究想要深入探讨的核心所在。

简言之，这是一次精心设计的随机对照实验，参与对象是 52 名真实的软件工程师（多数为初级水平）。他们需要使用一个从未接触过的 Python 异步库（Trio）完成开发任务，随后立即接受测验，以评估实际掌握程度。

测验内容覆盖了调试（错误定位与解释）、代码阅读（代码理解）、代码编写（代码编写）以及概念理解（概念掌握）这几项关键能力。注意，这不是让他们自行填写问卷说“我觉得我学会了”，而是通过实际答题来验证你的真实水平。

结果如何？颇为有趣。

速度提升不明显，但掌握程度出现显著下降。 使用 AI 的组平均仅快约 2 分钟，这一差异在统计上并不显著。然而测验成绩的差距却很大：AI 组平均得分为 50%，而完全自主编写的组拿到了 67%——相差将近两个等级，从 B 直降至 D。尤其在需要“知道问题出在哪、为什么不对”的调试类题目中，差距最为显著。讽刺的是，这恰恰是 AI 时代对工程师更为关键的能力。

因此，第一层结论是：AI 并不一定能让你稳定地更快，但它更容易让你“做完任务，却没学到东西”。

不过，这项研究最有价值的地方，并非单纯告诉你“用 AI 就完了”，而是探讨了“如何用”才能避免技能退化。研究者从录屏中归纳出 6 种交互模式，并能直接对应到截然不同的学习效果。

低分模式：把大脑外包给 AI

这些模式的测验平均分普遍低于 40%，典型的“完成了任务但没学到内容”。

• 完全委托写代码：速度最快，几乎不出错（因为 AI 帮你避开了所有坑），但测验结果最差。问题在于，你没有经历“犯错→定位→修复→理解”这一完整的学习闭环。
• 越写越依赖：一开始还能自己思考一两次，后来逐渐将写法和逻辑全部交给 AI，尤其对后续更复杂的概念掌握尤为薄弱。
• 让 AI 负责排错：提问方式往往是“帮我修一下”或“帮我确认对不对”，结果既不快，也没学会——因为关键的诊断推理直接被外包了。

高分模式：把 AI 当“教练”，而非“代写员”

平均分 ≥65% 的模式，才是真正学会的正确打开方式。

• 先生成，再逼自己理解：看起来与“全委托”相似，也是先让 AI 提供代码。但区别在于，你会在拿到代码后追问“为什么”，验证自己的理解，再亲自动手整合。
• 要代码也要解释：提示词中同时要求“生成代码 + 逐段解释”，你会花时间阅读解释，虽然慢，但理解更深入。
• 只问概念，不让它替你写：只问“Trio 的这个机制是什么”“为什么要这么写”，代码主要自己编写，错误也自己修正。这个模式在高分组中速度反而第二快，仅次于完全委托。

这里有一个关键点：使用 AI 的过程，本质上就是“认知外包”的过程。自动化越强，人类就越像监督者，但监督者最需要的技能——读懂、诊断、概念把握——却可能被自动化削弱。于是形成了一种结构性悖论：越依赖 AI，越缺乏监督 AI 的能力。

那么，落实到日常开发中，如何才能在“提速”与“保技能”之间找到平衡？其实可以直接参照上述高分模式，建立几个非常具体的操作习惯：

• 默认不让 AI 直接给最终代码。先让它解释概念、提供方案、指出潜在难点；你自己编写第一版。
• 如果要生成代码，强制加入解释和复述。比如在提示词中明确要求：“先给代码，再逐段解释每一段为什么需要”，以及“最后用三条要点总结该库/该模式的限制”。
• 调试时别让 AI 直接修复，先让它“定位与假设”。让它列出 3 个可能的原因，以及你应该如何验证（打印什么、查看哪段源码、查询哪个 API 文档）。这样就把诊断推理留在了你这边。
• 把“卡住”当作训练。认知努力，甚至那种“痛苦地卡住”的体验，很可能正是形成真正掌握度的重要条件。

当然，研究本身也承认其局限性：样本量不大（52人），测量的是“刚学完立刻测验”的短期理解，任务是“学习新库”，并不等于日常所有开发场景。因此更合理的结论不是“AI 会让人变笨”，而是：AI 本身不是问题，关键在于你使用它的方式。

而对于企业和管理者来说，更长远的考量是：短期生产效率的提升，是否正以长期专业能力的流失为代价？如果工程师逐渐失去了审查和调试 AI 代码的能力，未来的系统风险只会越来越大。