原文链接#

笔记#

这是一篇来自 Anthropic 的 preprint 论文。我读完后的第一感觉不是“结论已定”，而是它给了我一个值得警惕的观察角度。

这篇文章里最让我在意的一点是：在作者设计的任务里，更依赖 AI 的那组，在新知识掌握和调试测试上的表现更弱，而完成时间优势也不明显。

1. 实验：模拟“边干边学”#

研究者设计了一个比较贴近现实的场景：让 52 位有 Python 经验、但从未接触过 Trio 的 professional / freelance programmers，去学习这个主打结构化并发的异步编程库。

参与者被分为两组：

  • 手动组 (Manual Group)：不能使用 AI，只能依靠任务说明、文档和搜索。
  • AI 组 (AI Group)：可以使用基于 GPT-4o 的 AI 助手协助编写、调试和解释代码。

2. 核心发现：效率差异有限，能力形成可能受影响#

测试成绩差异#

在任务结束后的技能测试中，AI 组的得分比手动组约低 17%，论文作者称大约相当于 two grade points。差异主要出现在三个领域：

  1. 调试能力（分差最大）：AI 组更难发现代码中的逻辑错误。
  2. 概念理解：对 Trio 核心设计理念的掌握不如手动组。
  3. 代码阅读：预测代码运行结果的表现更弱。

效率并未显著提升#

研究结果显示，AI 组平均完成任务的时间仅比手动组快了不到 2 分钟（23 min vs 24.7 min）。

3. 为什么 AI 没有显著提效？#

我把这里的隐性成本理解为一种 interaction tax。

很多时候，我们以为 AI 帮我们写了代码就提效了，但实际上，程序员为了让 AI 生成正确的代码，需要花费大量时间：

  • 构思和编写精准的提示词（Prompt）。
  • 反复修改需求以纠正 AI 的错误输出。
  • 阅读和验证 AI 生成的大段代码（有时这比自己写还要累）。

有参与者甚至把 30% 以上的时间花在与 AI 对话上。对这类任务来说，AI 并不只是一个“生成器”，它也会变成一个需要管理和校验的外部系统。

4. 关键点：AI 交互的六种流派#

研究里更值得看的，不是“用了 AI 就一定会变差”，而是你在什么任务里、如何使用。

交互模式 描述 对技能的影响
AI 委派 (AI Delegation) 主要把任务交给 AI，自己只做少量调整或复制粘贴。 ❌ 更容易加深依赖
渐进式 AI 依赖 (Progressive AI Reliance) 一开始自己尝试，遇到困难后逐步把关键部分交给 AI。 ❌ 更容易过早放弃
AI 迭代调试 (Iterative AI Debugging) 不充分分析报错，反复把错误交给 AI 重新生成。 ❌ 更容易削弱分析过程
概念查询 (Conceptual Inquiry) 把 AI 当导师，询问“为什么”而非“帮我写”。 ✅ 更有助于概念理解
生成后理解 (Generation-Then-Comprehension) 让 AI 写，但在运行前先读懂关键逻辑。 ✅ 更有助于强化记忆
代码+解释混合 (Hybrid Code-Explanation) 要求代码的同时，要求 AI 补充解释。 ✅ 更容易同步逻辑理解

5. 可能机制：认知卸载#

我读下来，论文背后的解释可以放到两个概念里理解：

  • 认知卸载 (Cognitive Offloading)：AI 有点像外骨骼。它确实能帮人省力，但如果长期把关键推理过程都外包出去，技术能力也可能因为缺少练习而变弱。
  • 心理表征 (Mental Representation)：有经验的工程师通常会在脑中形成对代码的结构化理解。按论文作者的解释，手动组通过遭遇错误、查阅文档、独立解决问题，更容易建立这种心理表征；而 AI 组因为过程更“顺滑”，留下的深度痕迹可能更少。

6. 启示：刻意增加“摩擦力”#

论文最后提醒：AI 带来的生产力提升，不一定等于胜任力同步增长。

  • 对企业而言：如果把 AI 辅助推得过猛，又缺少刻意练习和 review 机制，初级员工在新工具上的技能形成可能会变弱，长期看会形成“能力负债”。
  • 对个人而言：在学习新领域时，应刻意增加“摩擦力”。先尝试自主思考和查阅文档，再利用 AI 进行概念上的点拨，而非逻辑上的替代。

结论：对我来说，更稳妥的用法是把 AI 当成解释器和陪练，而不是直接代打。如果你发现自己离了 AI 很难继续写代码或改 Bug，这至少是一个值得警惕的信号。

本文基于 preprint 论文：[Shen, J. H., & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245]