How AI Assistance Impacts the Formation of Coding Skills
原标题：How AI Assistance Impacts the Formation of Coding Skills 中文标题：AI 辅助如何影响编码技能的形成
原文链接：https://www.anthropic.com/research/AI-assistance-coding-skills
一句话摘要
一项针对 52 名软件开发者的随机对照实验发现，使用 AI 辅助的开发者在技能掌握测试中得分比手动编码组低 17%（约两个字母等级），但关键在于"如何使用"AI——主动提问和寻求理解的使用方式可以同时兼顾效率与学习。
完整核心内容翻译
引言
已有研究表明，AI 帮助人们更快地完成工作的"部分"内容。一项对 Claude.ai 数据的观察性研究显示，AI 可以将某些任务的完成时间缩短 80%。然而，生产力的提升引发了关于权衡的重要问题。其他研究表明，当个人使用 AI 辅助时，他们对工作的"投入度下降"，并"减少"了投入的认知努力——本质上是将认知工作外包给了 AI。
核心的不确定性在于：认知外包是否会阻碍工作中的技能发展？具体到编码场景，是否会阻碍对所构建系统的理解？本研究通过一项针对软件开发者的随机对照实验来调查这一潜在的负面影响。
这个问题具有广泛意义：它关系到促进学习的 AI 产品设计、工作场所的 AI 政策，以及社会韧性。编码是一个特别相关的领域，因为 AI 工具已经迅速成为标准配置。一个关键的张力浮现出来：随着编码变得更加自动化和加速化，人类仍然需要具备发现错误、引导输出、在高风险环境中对 AI 进行有效监督的技能。根本问题是：AI 是否同时提供了技能发展和效率提升的捷径，还是 AI 辅助带来的生产力收益会侵蚀技能发展？
研究设计
研究人员招募了 52 名主要为初级的软件工程师，每人每周使用 Python 超过一年。参与者对 AI 编码辅助有一定了解，但不熟悉研究中使用的 Python 库 Trio。
研究分为三个阶段：热身；主要任务——使用 Trio 编写两个功能（需要理解异步编程）；以及评估。参与者事先被告知将进行评估，但同时被鼓励快速工作。
编码任务模拟了自学教程式的学习场景。每位参与者获得问题描述、初始代码和简要的概念说明。在线平台包含一个可以访问代码的 AI 助手侧边栏，能够根据请求生成正确的代码。
评估设计
评估借鉴计算机科学教育研究，确定了四种技能掌握评估题型：
- 调试：识别和诊断代码错误——对检测不正确的 AI 生成代码和理解失败原因至关重要
- 代码阅读：理解代码功能——使验证 AI 编写的代码成为可能
- 代码编写：编写或选择合适的代码方法
- 概念理解：理解工具和库背后的核心原理——对评估 AI 生成的代码是否采用了与库设计意图一致的适当软件设计模式至关重要
评估特别强调调试、代码阅读和概念理解问题，认为这些对于监督日益由 AI 生成的代码最为重要。
核心结果
AI 组参与者完成任务大约快两分钟，但这一差异未达到统计显著性。然而，测试分数的差异是显著的：
| 组别 | 平均得分 | 效应量 | p 值 |
|---|---|---|---|
| AI 辅助组 | 50% | Cohen's d=0.738 | 0.01 |
| 手动编码组 | 67% | — | — |
差距约为两个字母等级。最大的分数差距出现在调试题上，表明理解代码何时以及为何失败，是 AI 妨碍编码技能发展时最令人担忧的方面。
定性分析：AI 交互模式
研究人员通过手动标注屏幕录制，识别了查询组成时间、问题类型、错误类型和主动编码时长。
一个出人意料的发现是：参与者花了大量时间与 AI 助手交互。有些人花了多达 11 分钟（占分配时间的 30%）来组织多达 15 个查询。
研究人员根据 AI 交互模式将参与者分组，识别出在完成时间和学习效果上截然不同的结果。
低分交互模式（平均测验得分低于 40%）
- AI 委托型（n=4）：完全依赖 AI 编写代码和完成任务。完成速度最快，几乎没有错误。
- 渐进式 AI 依赖型（n=4）：开始时提一两个问题，但最终将所有代码编写委托给 AI。由于未掌握第二个任务的概念，得分很低。
- 迭代式 AI 调试型（n=4）：依赖 AI 进行调试或代码验证。虽然提问更多，但他们依赖助手解决问题，而非寻求理解澄清。得分低且完成速度慢。
高分交互模式（平均测验得分 65% 或以上）
- 先生成后理解型（n=2）：先生成代码，然后手动复制或粘贴。随后提出后续问题以提高理解。速度不特别快，但测验理解度更高。与 AI 委托型类似，不同之处在于他们使用 AI 来验证自己的理解。
- 混合代码-解释型（n=3）：组合请求代码生成和代码解释。阅读和理解解释需要更多时间，但增强了理解。
- 概念探究型（n=7）：仅提出概念性问题，依靠提高的理解来完成任务。虽然遇到大量错误，但独立解决了它们。这种模式在高分模式中最快，在所有模式中仅次于 AI 委托型。
结论
结果表明，在工作场所——尤其是软件工程领域——激进地引入 AI 涉及权衡。研究发现强调，并非所有的 AI 依赖都是等价的：在追求效率时的交互方式影响着学习量。考虑到时间限制和组织压力，初级开发者可能倾向于依赖 AI 以最快速度完成任务，而以技能发展为代价——尤其是在问题出现时的调试能力。
这些结果虽然是初步的，但在公司转向更高的 AI 代码/人工代码比率时提出了重要的考量。如果初级工程师的技能发展因早期使用 AI 而受损，那么生产力收益可能以验证 AI 编写代码所需技能的缺失为代价。
对于软件工程或其他领域的新手工作者，本研究提供了支持有意识技能发展的证据。认知努力——包括"痛苦地卡住"——很可能对技能掌握的发展至关重要。主要 LLM 服务提供了学习模式（包括 Claude Code 的学习和解释模式以及 ChatGPT 的学习模式），旨在促进理解。
先前的研究对 AI 是"帮助"还是"阻碍"编码生产力产生了混合结果。这些研究实际上在回答不同的问题：早期的观察性工作衡量的是参与者已具备相关技能时的生产力，而本研究考察的是学习场景。AI 可能同时在已有技能上加速生产力，又在新技能习得上造成阻碍。
技术要点
AI 辅助导致 17% 的技能掌握度下降（Cohen's d=0.738）：这是一个中到大的效应量，在仅 52 人的样本中即达到统计显著性（p=0.01），表明效应的真实性和实质性。
调试技能受损最严重：AI 组与手动组在调试题上的差距最大。这尤其令人担忧，因为随着 AI 生成更多代码，人类的调试和监督能力变得更加重要而非更不重要。
六种 AI 交互模式的分类学：研究识别出从"完全委托"到"概念探究"的六种模式，其中"概念探究型"同时实现了高学习效果和高效率——这可能是 AI 辅助学习的最优模式。
生产力提升未达显著性：AI 组仅快约两分钟且差异不显著，但技能掌握的下降高度显著。这表明在学习场景中，AI 的效率收益可能被高估，而学习成本被低估。
认知努力是技能形成的必要条件："痛苦地卡住"对掌握技能可能是必要的——这一发现与教育心理学中"可取的困难"（desirable difficulties）理论高度一致。
深度解读
这是一个关于"速度 vs. 深度"的经典权衡。 本研究的核心发现并不令人意外——教育心理学数十年的研究已经表明，轻松获得答案不利于长期记忆和技能形成。但本研究的价值在于它用严格的实验设计（RCT）在编码这个高度现实的场景中量化了这一效应。
"概念探究型"指向了一条兼得之路。 在六种交互模式中，"概念探究型"（仅提概念问题、独立编码）是高分模式中最快的，仅次于完全委托。这暗示了一种可能的最优策略：用 AI 作为概念导师而非代码生产工具。这对 AI 产品设计有直接启示——是否应该在学习场景中限制代码生成功能，转而强化概念解释功能？
"调试技能差距"是一颗定时炸弹。 如果整整一代开发者在 AI 辅助下成长，却从未充分发展调试技能，那么当 AI 生成的代码出现微妙的、AI 自身无法识别的错误时——正如 Schwartz 在"Vibe Physics"中反复记录的那样——谁来发现和修复这些错误？这是一个系统性风险。
小样本但大信号。 52 人是一个相对小的样本，但 Cohen's d=0.738 是一个相当大的效应量。这意味着即使在小样本中，效应也足够大到被检测出来。这为更大规模的后续研究提供了强有力的动机。
"学习模式"的产品化。 文章提到 Claude Code 和 ChatGPT 都已推出"学习模式"。这表明 AI 公司已经意识到这个问题并试图通过产品设计来缓解。但问题在于：在时间压力下，有多少用户会主动选择较慢的学习模式而非高效的生成模式？
延伸思考
长期效应可能不同：本研究衡量的是编码后几分钟内的即时理解。但长期来看，AI 辅助组是否会通过更多的项目暴露弥补这一差距？或者差距会随时间扩大？
经验水平的调节效应：本研究主要使用初级工程师。对于高级工程师学习新技术时，AI 辅助的"学习成本"是否更低，因为他们已有的框架知识可以补偿？
组织层面的困境：公司面临一个真实的两难：短期内需要初级工程师尽快产出（倾向于高 AI 依赖），长期需要他们成长为能够独立判断的高级工程师（倾向于低 AI 依赖）。如何在组织政策中平衡这一矛盾？
"可取的困难"vs."不必要的痛苦"的边界：并非所有的认知困难都有助于学习。查找一个丢失的分号和理解异步编程的概念模型是完全不同的认知挑战。AI 应该消除哪些困难、保留哪些困难？
对编码教育的根本性影响：如果未来大多数代码由 AI 生成，计算机科学教育是否应该从"编写代码"转向"审计代码"——更像是代码审查者和系统架构师的培养路径，而非程序员的培养路径？