摘要
1) 一句话总结 一项针对52名软件工程师的随机对照试验表明，在学习新编程技能时使用AI辅助会导致技能掌握度（尤其是调试能力）显著下降，交互方式直接决定了开发者是实现了技能提升还是认知外包。
2) 核心要点
- 研究设计：52名具有Python经验的（主要为初级）软件工程师参与了随机对照试验，任务是使用不熟悉的Python库（Trio）编写功能并接受测试。
- 测试成绩下降：AI组的平均测试得分为50%，而纯手工编程组为67%。AI组得分低17%（相当于近两个等级差距，p=0.01）。
- 调试能力受影响最大：在调试、代码阅读、代码编写和概念理解四类评估中，两组得分差距最大的是“调试（Debugging）”问题。
- 效率提升不显著：AI组平均完成速度仅快约2分钟（统计学上不显著）。部分原因是参与者花费大量时间与AI交互，个别人耗时达11分钟（占总时间30%）。
- 低分交互模式（得分<40%）：严重依赖AI生成代码或调试（如“AI委托型”、“渐进依赖型”），表现为认知外包，缺乏独立思考。
- 高分交互模式（得分≥65%）：将AI作为学习工具，行为包括生成代码后提问加深理解、要求AI解释代码，或仅进行概念探究（其中“概念探究型”是整体速度第二快的模式）。
- 熟练度与新技能的差异：虽然先前观察性研究显示AI能将已掌握技能的任务速度提升80%，但本研究表明，在学习新事物时，AI可能会阻碍新技能的获取。
3) 风险与局限
- 监督能力缺失风险：如果初级开发者为了追求速度而过度依赖AI，可能会牺牲技能发展，导致未来缺乏发现错误和验证AI生成代码所需的核心能力。
- 样本与时间局限：本研究样本量较小（52人），且仅在编程任务后进行了即时测试，即时表现能否预测长期的技能发展尚无定论。
- 未解的研究空白：目前尚不清楚AI对编程以外任务的影响、这种负面影响是否会随着工程师熟练度的提高而长期消散，以及在学习过程中AI辅助与人类辅助是否存在本质区别。
正文
研究表明，AI能帮助人们更快地完成部分工作。在对Claude.ai数据的一项观察性研究中，我们发现AI能将某些任务的速度提升80%。但这种生产力的提高是否伴随着代价？其他研究表明，当人们使用AI辅助时，他们对工作的投入度会降低，付出的努力也会减少——换句话说，他们将思考过程“外包”给了AI。
这是否会阻碍人们在工作中提升技能，或者在编程领域，是否会阻碍他们理解自己构建的系统？我们最新的随机对照试验以软件开发者为参与者，调查了在工作中使用AI的这一潜在负面影响。
这个问题具有广泛的影响——无论是对于如何设计促进学习的AI产品，工作场所应如何制定AI政策，还是对于更广泛的社会韧性而言。我们将目光聚焦于编程，在这个领域，AI工具已迅速成为标配。在这里，AI带来了潜在的冲突：随着编程变得更加自动化和高效，人类仍然需要具备发现错误、引导输出以及最终为高风险环境部署的AI提供监督的技能。AI究竟是技能发展和效率提升的捷径，还是说AI带来的生产力提升会削弱技能的发展？
在一项随机对照试验中，我们考察了：
- 软件开发者在有无AI辅助的情况下，掌握新技能（本例中为一个Python库）的速度；
- 使用AI是否会降低他们对自己刚编写的代码的理解程度。
我们发现，使用AI辅助会导致技能掌握程度出现统计学上的显著下降。在涵盖他们几分钟前刚使用过的概念的测试中，AI组参与者的得分比纯手工编程组低17%，相当于近两个等级的分数差距。使用AI略微加快了任务完成速度，但并未达到统计学上的显著水平。
重要的是，使用AI辅助并不一定会导致低分。人们使用AI的方式影响了他们保留信息的多少。掌握程度较高的参与者不仅使用AI来生成代码，还在这个过程中建立理解——无论是在独立编程时提出后续问题、要求解释，还是提出概念性问题。
研究设计
我们招募了52名（主要是初级）软件工程师，他们都至少有一年以上每周使用Python的经验。我们确保他们对AI编程辅助工具有一定了解，但对我们任务所基于的Python库（Trio）并不熟悉。
研究分为三个部分：热身；主要任务（使用Trio编写两个不同的功能，这需要理解与异步编程相关的概念，通常是在专业环境中学习的技能）；以及测试。我们告知参与者任务后会有测试，但鼓励他们尽可能快地完成工作。
我们将编程任务设计成模拟人们通过自学教程学习新工具的过程。每位参与者都会得到问题描述、初始代码以及解决问题所需Trio概念的简要说明。我们使用了一个在线编程平台，侧边栏配有AI助手，该助手可以访问参与者的代码，并在被要求时随时生成正确的代码。（注：这种设置不同于像Claude Code这样的代理型编程产品；我们预计此类程序对技能发展的影响可能会比本研究的结果更为显著。）
评估设计
在评估设计中，我们借鉴了计算机科学教育的研究，确定了四种常用于评估编程技能掌握程度的问题类型：
- 调试（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助手交互所花费的时间。有几个人花了长达11分钟（占分配总时间的30%）编写了多达15个查询。这有助于解释为什么平均而言，使用AI的参与者完成得更快，但生产力的提升在统计学上并不显著。我们预计，当AI用于重复性或熟悉的任务时，更有可能显著提高生产力。
不出所料，无AI组的参与者遇到了更多错误。这些包括语法错误和Trio概念错误，后者直接对应于评估中测试的主题。我们的假设是，遇到更多Trio错误（即对照组）的参与者可能通过独立解决这些错误提高了他们的调试技能。
然后，我们根据参与者与AI的交互方式对他们进行分组，识别出导致不同完成时间和学习结果的独特模式。
低分交互模式：低分模式通常涉及对AI的严重依赖，无论是通过代码生成还是调试。该组的平均测试得分低于40%。他们表现出较少的独立思考和更多的认知外包。我们进一步将他们分为：
- AI委托型（n=4）：完全依赖AI编写代码并完成任务。他们完成任务最快，过程中几乎没有遇到错误。
- 渐进依赖型（n=4）：开始时问一两个问题，但最终将所有代码编写工作委托给AI助手。他们测试得分很低，主要是因为没有掌握第二个任务中的任何概念。
- 迭代调试型（n=4）：依赖AI来调试或验证代码。他们问了更多问题，但依赖助手来解决问题，而不是澄清自己的理解。结果得分很低，完成两项任务的速度也较慢。
高分交互模式：我们将平均测试得分在65%或以上的行为视为高分模式。这些集群中的参与者既使用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增强的工作场所中，生产力的提升很重要，但这些提升所依赖的专业知识的长期发展同样重要。