wsl-docs

AI 辅助如何影响编程技能的形成

发布日期：2026-01-29原文链接：https://www.anthropic.com/research/AI-assistance-coding-skills23分钟阅读

摘要

一句话摘要

Anthropic 的一项随机对照试验表明，在学习新编程技能时使用 AI 辅助会导致开发者的代码理解和调试能力显著下降，但具体影响程度取决于开发者与 AI 的交互方式。

关键要点

  • 实验设计：研究对 52 名（主要为初级）软件工程师进行了随机对照试验，要求他们在有/无 AI 辅助的情况下学习并使用一个不熟悉的 Python 库（Trio）完成编程任务。
  • 理解能力显著下降：在任务后的测验中，AI 辅助组的平均得分为 50%，而纯手工编程组为 67%（相差近两个字母等级，p = 0.01）。
  • 调试技能受损最严重：两组之间得分差距最大的是“调试（Debugging）”类问题，表明过度依赖 AI 会削弱开发者识别和诊断代码错误的能力。
  • 效率提升不显著：在该学习型任务中，AI 组平均完成时间仅快了约两分钟，未达到统计学显著性（部分原因是参与者将高达 30% 的时间用于编写 AI 提示词）。
  • 低分交互模式（得分 <40%）：表现为严重的“认知卸载”，开发者完全委托 AI 编写代码、渐进式依赖 AI 或仅依赖 AI 进行迭代调试，缺乏独立思考。
  • 高分交互模式（得分 ≥65%）：开发者不仅使用 AI 生成代码，还主动利用 AI 建立理解（如生成后要求解释、混合查询或仅进行概念探究）。
  • 概念探究最高效：在所有高分模式中，“仅向 AI 提出概念性问题并独立解决错误”的开发者完成任务的速度最快。
  • 管理与政策启示：企业在追求 AI 带来的短期效率时，可能会以牺牲初级工程师的技能发展为代价；管理者需采用有意识的设计或政策，确保开发者保留验证和监督 AI 代码的能力。

风险与局限性（基于原文明确指出）

  • 样本量有限：本研究的样本相对较小（52 人）。
  • 缺乏长期追踪：评估是在编程任务结束后立即进行的，即时的测验表现能否预测长期的技能发展尚不确定。
  • 任务范围局限：尚未探讨 AI 对编程以外任务的影响，以及这种负面影响是否会随着工程师变得更加熟练而逐渐消失。
  • 对比基准缺失：研究尚未比较在学习过程中“AI 辅助”与“人类辅助”之间是否存在差异。
  • 工具形态差异：实验使用的是侧边栏 AI 助手，若使用自动化程度更高的代理式编程产品（Agentic coding products，如 Claude Code），对技能发展的负面影响可能会比本研究的结果更为显著。

正文

研究表明，AI 能帮助人们更快地完成部分工作。在一项针对 Claude.ai 数据的观察性研究中，我们发现 AI 可以将某些任务的速度提升 80%。但是，这种生产力的提升是否伴随着代价？其他研究表明，当人们使用 AI 辅助时，他们对工作的投入度会降低，并减少在工作上付出的努力——换句话说，他们将思考过程“卸载”给了 AI（认知卸载）。

目前尚不清楚这种认知卸载是否会阻碍人们在工作中提升技能，或者——以编程为例——阻碍他们理解自己正在构建的系统。我们最新的一项以软件开发者为参与者的随机对照试验，调查了在工作中使用 AI 的这一潜在负面影响。

这个问题具有广泛的影响——涉及如何设计促进学习的 AI 产品、工作场所应如何制定 AI 政策，以及更广泛的社会韧性等方面。我们将重点放在编程领域，在这个领域，AI 工具已迅速成为标配。在这里，AI 带来了一种潜在的张力：随着编程变得越来越自动化且工作速度加快，人类仍然需要具备发现错误、引导输出以及最终对部署在高风险环境中的 AI 进行监督的技能。AI 是否提供了一条同时实现技能发展和效率提升的捷径？还是说 AI 辅助带来的生产力提升会削弱技能的发展？

在一项随机对照试验中，我们考察了：1）在有和没有 AI 辅助的情况下，软件开发者掌握一项新技能（在本例中为一个 Python 库）的速度有多快；2）使用 AI 是否会降低他们理解自己刚刚编写的代码的可能性。

我们发现，使用 AI 辅助会导致掌握程度出现统计学上显著的下降。在一项涵盖他们几分钟前刚使用过的概念的测验中，AI 组参与者的得分比纯手工编程组低 17%，这相当于近两个字母等级的差距（例如从 A 降到 C）。使用 AI 略微加快了任务完成速度，但这并未达到统计学显著性的阈值。

重要的是，使用 AI 辅助并不一定会导致低分。人们使用 AI 的方式，会直接影响他们对知识的吸收与保留程度。表现出更强掌握能力的参与者不仅使用 AI 辅助来生成代码，还在这一过程中建立理解——无论是在独立编程时提出后续问题、要求解释，还是提出概念性问题。

研究设计

我们招募了 52 名（主要是初级）软件工程师，他们每个人在过去一年多里至少每周使用一次 Python。我们还确保他们至少对 AI 编程辅助有一定程度的了解，并且不熟悉 Trio（我们任务所基于的 Python 库）。

我们将研究分为三个部分：热身；主要任务（使用 Trio 编写两个不同的功能，这需要理解与异步编程相关的概念，这是一项通常在专业环境中学习的技能）；以及测验。我们告诉参与者任务结束后会有测验，但鼓励他们尽可能快地完成工作。

我们设计的编程任务模仿了人们通过自学教程学习新工具的方式。每位参与者都会得到一份问题描述、初始代码，以及解决该问题所需 Trio 概念的简要说明。我们使用了一个在线编程平台，侧边栏配有 AI 助手，该助手可以访问参与者的代码，并在被要求时随时生成正确的代码。[1]

评估设计

在我们的评估设计中，我们借鉴了计算机科学教育领域的研究，确定了通常用于评估编程技能掌握程度的四类问题：

  • 调试（Debugging）：识别和诊断代码错误的能力。这项技能对于检测 AI 生成的代码何时出错以及理解其失败原因至关重要。

  • 代码阅读（Code reading）：阅读并理解代码功能的能力。这项技能使人类能够在部署前理解并验证 AI 编写的代码。

  • 代码编写（Code writing）：编写或选择正确方法来编写代码的能力。随着 AI 编程工具的进一步整合，像记住函数语法这样的底层代码编写能力，将不如高层系统设计重要。

  • 概念理解（Conceptual）：理解工具和库背后核心原理的能力。概念理解对于评估 AI 生成的代码是否使用了合适的软件设计模式（这些模式应符合该库的预期使用方式）至关重要。

我们的评估最侧重于调试、代码阅读和概念性问题，因为我们认为这些对于监督越来越可能由 AI 生成的代码最为重要。

结果

平均而言，AI 组的参与者完成任务的时间快了约两分钟，尽管这一差异在统计学上并不显著。然而，在测试分数上存在显著差异：AI 组在测验中的平均得分为 50%，而手工编程组为 67%——这相当于近两个字母等级的差距（Cohen’s d = 0.738，p = 0.01）。两组之间得分差距最大的是调试问题，这表明如果 AI 阻碍了编程能力的发展，那么理解代码何时出错以及为何失败的能力可能是一个特别值得关注的领域。

定性分析：AI 交互模式

我们特别想了解参与者是如何完成我们设计的任务的。在定性分析中，我们手动标注了屏幕录像，以确定参与者花了多少时间向 AI 提问、他们提出了什么类型的问题、他们犯了哪些类型的错误，以及他们花了多少时间进行主动编程。

一个令人惊讶的结果是参与者花在与 AI 助手交互上的时间。有几个人花了长达 11 分钟（占分配总时间的 30%）进行了多达 15 次提问。这有助于解释为什么平均而言使用 AI 的参与者完成得更快，尽管生产力的提升在统计学上并不显著。我们预计，当 AI 用于重复性或熟悉的任务时，更有可能显著提高生产力。

毫不意外，无 AI 组的参与者遇到了更多错误。这些包括语法错误和 Trio 概念错误，后者直接对应于评估中测试的主题。我们的假设是，遇到更多 Trio 错误（即对照组）的参与者可能通过独立解决这些错误提高了他们的调试技能。

然后，我们根据参与者与 AI 交互的方式对他们进行分组，识别出导致完成时间和学习效果出现不同结果的独特模式。

低分交互模式：低分模式通常涉及对 AI 的严重依赖，无论是通过代码生成还是调试。该组的平均测验得分低于 40%。他们表现出较少的独立思考和更多的认知卸载。我们进一步将他们分为：

  • AI 委托（n = 4）：该组参与者完全依赖 AI 编写代码并完成任务。他们完成任务的速度最快，并且在过程中几乎没有遇到错误。

  • 渐进式 AI 依赖（n = 4）：该组参与者一开始只问了一两个问题，但最终将所有代码编写工作都委托给了 AI 助手。他们在测验中得分很低，主要是因为没有掌握第二个任务中的任何概念。

  • 迭代式 AI 调试（n = 4）：该组参与者依赖 AI 来调试或验证他们的代码。他们提出了更多问题，但依赖助手来解决问题，而不是为了理清自己的理解。结果他们得分很低，并且完成这两项任务的速度也较慢。

高分交互模式：我们将平均测验得分在 65% 或以上的行为视为高分测验模式。这些集群中的参与者既使用 AI 生成代码，也使用 AI 进行概念查询。

  • 先生成后理解（n = 2）：该组参与者首先生成代码，然后手动将代码复制或粘贴到他们的工作中。代码生成后，他们向 AI 助手提出后续问题以加深理解。这些参与者在使用 AI 时速度并不是特别快，但在测验中表现出更高水平的理解。有趣的是，这种方法看起来与“AI 委托”组几乎相同，唯一的区别在于他们使用 AI 来检验自己的理解。

  • 代码与解释混合（n = 3）：该组参与者编写了混合查询，在要求生成代码的同时要求对生成的代码进行解释。阅读并理解他们所要求的解释花费了更多时间，但有助于他们的理解。

  • 概念探究（n = 7）：该组参与者只提出概念性问题，并依靠他们提升的理解力来完成任务。尽管该组遇到了许多错误，但他们也独立解决了这些错误。平均而言，这种模式是高分模式中最快的，也是整体上第二快的，仅次于“AI 委托”。

我们的定性分析并未在交互模式与学习成果之间建立因果关系，但它确实指出了与不同学习成果相关的行为。

结论

我们的结果表明，在工作场所（特别是在软件工程领域）激进地引入 AI 是需要付出代价的。研究结果强调，并非所有的 AI 依赖都是相同的：我们在追求效率时与 AI 交互的方式会影响我们学到多少东西。考虑到时间限制和组织压力，初级开发者或其他专业人员可能会依赖 AI 尽可能快地完成任务，而代价是牺牲了技能的发展——尤其是当出现问题时调试问题的能力。

尽管是初步的，但这些结果提出了重要的考量因素，因为企业正在向 AI 编写代码比例高于人类编写代码的阶段过渡。如果初级工程师的技能发展从一开始就因为使用 AI 而受到阻碍，那么生产力的提升可能是以牺牲验证 AI 编写代码所需技能为代价的。管理者应有意地思考如何大规模部署 AI 工具，并考虑采用能够确保工程师在工作中继续学习的系统或有意识的设计选择——从而使他们能够对所构建的系统行使有意义的监督。

对于软件工程或任何其他行业的新手工作者来说，我们的研究提供了初步证据，证明了在使用 AI 工具时，有意识地培养自身技能具有重要价值。认知努力——甚至痛苦地陷入困境——对于培养精通能力可能很重要。这也是一个适用于个人如何选择与 AI 协作以及使用哪些工具的教训。主要的 LLM 服务也提供了旨在促进理解的学习模式（例如，Claude Code 学习与解释模式或 ChatGPT 学习模式）。了解人们在使用 AI 时如何学习也有助于指导我们如何设计 AI；AI 辅助应该使人类能够更高效地工作，同时发展新技能。

先前的研究对于 AI 是有助于还是阻碍编程生产力得出了不一的结论。我们自己的研究发现，AI 可以将完成某些工作任务的时间减少 80%——这一结果似乎与本文提出的发现存在冲突。但这两项研究提出了不同的问题，并使用了不同的方法：我们早期的观察性工作测量了参与者在已经具备相关技能的任务上的生产力，而本研究考察了人们在学习新事物时会发生什么。AI 有可能既能在人们已熟练掌握的技能上提升生产力，又会阻碍新技能的获取，尽管还需要更多研究来理解这种关系。

本研究只是揭示人机协作如何影响工作者体验的第一步。我们的样本相对较小，并且我们的评估是在编程任务结束后不久测量理解能力的。即时的测验表现是否能预测长期的技能发展，是本研究尚未解决的一个重要问题。仍有许多未解之谜我们希望未来的研究能够探讨，例如 AI 对编程以外任务的影响、这种影响是否会随着工程师变得更加熟练而在纵向上消散，以及在学习过程中 AI 辅助与人类辅助是否存在差异。

最终，为了在 AI 存在的环境中适应技能发展，我们需要以更广阔的视角来看待 AI 对工作者的影响。在 AI 增强的工作场所中，生产力的提升固然重要，但这些提升所依赖的专业知识的长期发展同样重要。

阅读完整论文了解详情。

致谢

本项目由 Judy Hanwen Shen 和 Alex Tamkin 领导。Jake Eaton、Stuart Ritchie 和 Sarah Pollack 为本篇博客文章提供了编辑支持。

我们要感谢 Ethan Perez、Miranda Zhang 和 Henry Sleight 通过 Anthropic 安全研究员项目（Anthropic Safety Fellows Program）使本项目成为可能。我们还要感谢 Matthew Jörke、Juliette Woodrow、Sarah Wu、Elizabeth Childs、Roshni Sahoo、Nate Rush、Julian Michael 和 Rose Wang 提供的实验设计反馈。

脚注

  • 重要的是，这种设置不同于像 Claude Code 这样的代理式编程产品；我们预计此类程序对技能发展的影响可能会比这里的结果更为显著。

相关文档

关联主题

关系图谱

反向链接