如果人不保持认知参与，AI 赋能就变成了 AI 替代，而一旦 AI 出错，没有人有能力兜底！Anthropic 最新的论文做了一个有趣的研究「AI 如何影响技能的习得」👀 arxiv.org/pdf/2601.20245

研究者设计了一个随机对照实验，让 52 名有经验的Python 开发者学习一个他们从未用过的异步编程库（Trio）。实验分两组：AI 辅助组可以使用基于 GPT-4o 的聊天助手，对照组只能靠文档和网页搜索。完成编程任务后，所有人参加同一份知识测验（概念理解、代码阅读、调试能力），且测验期间双方都不能用 AI。

核心发现很尖锐：用 AI 既没有明显提速，又显著损害了学习效果。六种AI交互模式的分化极其鲜明：

低分模式（测验 24%-39%）：

- AI 全委托：直接让 AI 写完所有代码，最快完成但学到最少；
- 渐进依赖：第一题还自己想，第二题就完全交给 AI；
- 反复让 AI 调试：遇到错误就丢给 AI，自己不思考；

高分模式（测验 65%-86%）：

- 先生成后理解：让 AI 写代码，但之后追问原理；
- 混合代码-解释：每次请求都同时要求代码和解释；
- 只问概念：仅向 AI 提概念性问题，自己独立写代码和解决错误；

最高分的模式（86%）是"先生成后理解"——看起来行为和全委托几乎一样，但多了一步主动追问理解，结果天差地别。

基于论文的发现，我认为有几个层面的应对策略：

- 对个人（尤其是新技能习得阶段）： 关键原则是保持认知参与。论文证明了"先生成后理解"模式的有效性——你可以用AI 加速，但必须在生成后追问"为什么这样写"，把 AI 当教练而不是代工。遇到错误时，先自己想 30 秒再求助 AI，这个独立解决错误的过程正是调试能力的来源；

- 对组织和管理者： 需要重新审视"AI 提升生产力"的叙事。论文揭示了一个隐性成本——初级员工如果在入职初期就过度依赖 AI 完成不熟悉的任务，可能永远无法建立起监督AI所需的基础能力。可以考虑在 onboarding 和技能培养阶段设置"AI-light"时段，或者强制要求新人在使用AI时同时生成解释；

- 对 AI 产品设计： 论文末尾提到了 ChatGPT Study Mode 和 Claude Code 的 Learning/Explanatory 模式，这是正确的方向。理想的 AI 编程助手应该能感知用户处于"学习新技能"还是"执行已知任务"的状态，在前者时主动引导而非直接给答案。

因为 AI 增强的生产力不是能力习得的捷径✨