【译】AI 助手如何影响编程技能的形成

原文：How AI assistance impacts the formation of coding skills, Anthropic 作者：Judy Hanwen Shen, Alex Tamkin 发布日期：2026 年 1 月 29 日

AI 确实能让人把一部分工作做得更快。

在一项基于 Claude.ai 使用数据的观察性研究中，Anthropic 发现：AI 能让某些任务的完成速度提升 80%。但问题在于，效率的提升是否伴随着代价？已有研究表明，当人们使用 AI 辅助时，他们会对工作投入更少，也会减少亲自思考和动手的 effort——换句话说，人们会把一部分思考“外包”给 AI。

目前仍不清楚，这种认知卸载是否会妨碍人们在工作中持续增长技能；如果放到编程语境下，就是：它是否会削弱开发者理解自己所构建系统的能力。Anthropic 最新的一项随机对照试验，以软件开发者为参与者，专门研究了在工作中使用 AI 的这一潜在负面影响。

这个问题的意义不止于编程。它关系到我们该如何设计能促进学习的 AI 产品、企业该如何制定 AI 使用政策，以及更广泛意义上的社会韧性。之所以聚焦编程，是因为 AI 工具在这一领域已经迅速成为常态；而这也带来了一个张力：随着编程越来越自动化、工作节奏越来越快，人类依然需要具备发现错误、引导输出，并最终对部署在高风险环境中的 AI 进行监督的能力。AI 真的是一条既能提升效率、又能促进技能成长的捷径吗？还是说，它带来的生产力增长，恰恰会侵蚀技能发展？

在这项随机对照试验中，研究者主要考察了两件事：

1. 软件开发者在有无 AI 辅助的情况下，掌握一项新技能（这里指一个新的 Python 库）的速度有何差异；
2. 使用 AI 是否会让他们更难真正理解自己刚刚写出来的代码。

研究结果显示：使用 AI 辅助，会导致开发者的掌握程度显著下降。在一份测验中，题目考察的正是参与者几分钟前刚刚用到的那些概念；AI 组的得分比手写代码组低 17%，大致相当于低了将近两个等级。AI 的确让任务完成速度略快了一些，但这个差异并没有达到统计显著。

不过，使用 AI 并不意味着分数必然更低。人们如何使用 AI，会显著影响他们能保留下来多少信息。那些掌握程度更高的参与者，并不是单纯把 AI 当成“代码生成器”，而是把它当成理解的辅助工具：他们会追问、要求解释，或者在自己独立编码的过程中，用 AI 来回答概念性问题。

研究设计

研究招募了 52 名软件工程师（大多数是初级开发者）。这些人至少在过去一年里每周都会使用一次 Python。研究团队还确保他们对 AI 编程辅助至少有一定熟悉度，但对本次任务所使用的 Python 库 Trio 并不熟悉。

整个实验分为三部分：热身任务、主任务，以及最后的测验。主任务要求参与者使用 Trio 实现两个不同的功能；这需要他们理解与异步编程相关的概念，而这类技能通常是在真实工作场景中学习的。研究者提前告知参与者任务之后会有测验，但仍鼓励他们尽可能快地完成编码。

为了尽量贴近真实世界中“自学一个新工具”的过程，研究者把这项编码任务设计成类似自助教程的形式：每位参与者都会拿到问题描述、起始代码，以及一段简短说明，用来介绍解决任务所需的 Trio 概念。实验使用的是一个在线编码平台，侧边栏内置了 AI 助手；这个 AI 能访问参与者当前的代码，并且只要用户开口，它随时都能直接给出正确答案。¹

评估设计

在评估设计上，研究者借鉴了计算机科学教育领域的研究，将编程技能掌握程度划分为四类常见问题类型：

• 调试（Debugging）：识别并诊断代码错误的能力。这项能力对于判断 AI 生成的代码何时出错、以及为什么出错，至关重要。
• 代码阅读（Code reading）：阅读并理解代码行为的能力。这使人类能够在部署前理解并验证 AI 写出的代码。
• 代码编写（Code writing）：写出正确代码，或选择正确编码思路的能力。随着 AI 编程工具进一步普及，像记忆函数语法这样偏底层的编码能力，重要性可能会下降；但更高层次的系统设计能力不会。
• 概念理解（Conceptual）：理解工具和库背后核心原理的能力。只有具备概念理解，开发者才能判断 AI 生成的代码是否采用了合理的软件设计模式，是否符合该库原本 intended 的使用方式。

在这些能力中，研究者尤其看重调试、代码阅读和概念理解，因为他们认为，这三类能力对于未来监督越来越多由 AI 生成的代码尤其关键。

结果

平均来看，AI 组完成任务大约快了两分钟，但这一差异并不具有统计显著性。真正显著的差异出现在测验成绩上：AI 组平均得分为 50%，而手写代码组为 67%，大致相当于相差接近两个等级（Cohen’s d=0.738，p=0.01）。

两组之间分差最大的部分出现在调试题上。这说明，如果 AI 的确阻碍了编程技能的发展，那么“判断代码哪里错了、为什么错了”这件事，很可能会成为最值得担心的薄弱环节。

定性分析：人与 AI 的交互模式

研究团队还特别关心：参与者究竟是怎样完成这些任务的。

在定性分析中，研究者手动标注了屏幕录像，记录了参与者花了多少时间组织提问、提了哪些类型的问题、犯了哪些错误，以及他们真正花在主动编码上的时间。

一个颇让人意外的结果是：一些参与者花了大量时间与 AI 助手互动。有人最长用了 11 分钟——相当于总时长的 30%——去组织多达 15 次提问。这也解释了为什么 AI 组虽然平均更快，但生产力提升并没有达到统计显著：人与 AI 的交互本身，也需要成本。研究者推测，如果任务更重复、或者开发者对任务本身更熟悉，AI 对效率的提升更可能变得显著。

不出所料，无 AI 组遇到的错误更多，其中既包括语法错误，也包括 Trio 概念上的错误；而后者正好对应测验中要考察的主题。研究团队由此提出一个假设：那些在实验中亲自撞上更多 Trio 错误、并自己解决它们的参与者（也就是对照组），很可能正是在这个过程中提升了调试能力。

接着，研究者根据参与者与 AI 的互动方式，将他们分成不同模式，并观察这些模式与完成时间、学习效果之间的关系。

低分交互模式通常表现为对 AI 的高度依赖，不管这种依赖是用来生成代码，还是用来调试。这个群体的平均测验成绩低于 40%。他们表现出更少的独立思考，以及更明显的认知卸载。进一步可分为三类：

• AI 全权代劳（AI delegation，n=4）：这组参与者几乎完全依赖 AI 写代码、完成任务。他们完成得最快，过程中几乎不出错，甚至完全不出错。
• 逐步转向 AI 依赖（Progressive AI reliance，n=4）：这组人一开始只问一两个问题，但后来把所有代码编写都交给了 AI。由于第二个任务中的概念几乎没有真正掌握，他们在测验中表现很差。
• 迭代式 AI 调试（Iterative AI debugging，n=4）：这组参与者主要让 AI 帮他们调试或验证代码。他们问得更多，但更像是在让助手替自己解决问题，而不是借此澄清自己的理解。结果是分数依旧不高，而且完成两个任务的速度也更慢。

高分交互模式指的是平均测验成绩达到 65% 以上的行为模式。这些参与者同样会使用 AI 生成代码，也会问概念问题，但用法明显不同：

• 先生成、再理解（Generation-then-comprehension，n=2）：他们先让 AI 生成代码，再手动复制或粘贴到自己的工作区。代码生成之后，他们还会继续向 AI 提问，以加深理解。这种方式并不快，但测验理解水平更高。有意思的是，这种模式表面上看和“AI 全权代劳”很像，关键区别在于：他们会用 AI 来检验、补足自己的理解。
• 代码+解释混合提问（Hybrid code-explanation，n=3）：他们提出的请求往往同时包含“生成代码”和“解释代码”。阅读并理解这些解释会花更多时间，但也确实帮助了他们掌握内容。
• 概念探究型（Conceptual inquiry，n=7）：他们只向 AI 询问概念问题，然后依靠自己建立起来的理解完成任务。虽然这组人同样会遇到不少错误，但他们更多是靠自己解决。平均来看，这是高分模式里速度最快的一组，在所有模式中也仅次于“AI 全权代劳”。

研究者强调，这里的定性分析并不能直接证明交互模式与学习结果之间存在因果关系，但它的确揭示了：某些行为模式更容易伴随较好的学习结果，而另一些模式则更容易走向相反方向。

结论

研究结果表明，在职场中，尤其是在软件工程场景下，大规模激进引入 AI，确实存在取舍。

关键问题不在于“是否依赖 AI”，而在于以什么方式依赖 AI。当人们在追求效率时与 AI 的交互方式，会直接影响他们究竟能学到多少东西。面对时间压力和组织层面的效率要求，初级开发者或其他专业人士，很可能会为了尽快交付任务，把 AI 当成完成工作的捷径；代价则是技能成长受损，尤其是当问题出现时，调试和排查能力会变弱。

尽管这项研究仍然是初步性的，但它已经为企业提供了一个重要提醒：随着 AI 编写代码的比例越来越高，相关的生产力收益，可能恰恰建立在对“验证 AI 代码所需能力”的消耗之上——尤其当初级工程师本应建立这些能力的阶段，就被 AI 提前“包办”了。管理者需要更有意识地思考：究竟该如何在组织内大规模部署 AI 工具，以及应当配套怎样的制度或产品设计，才能让工程师在工作过程中继续学习，并真正保有对自己构建系统的有效监督能力。

对于软件工程新手，乃至其他行业的初学者来说，这项研究也提供了一点值得重视的证据：如果希望借助 AI 真正成长，有意识地进行技能训练仍然非常重要。认知上的努力，甚至包括那种令人痛苦的“卡住”时刻，本身很可能正是形成熟练度所必需的。这同样适用于个人层面：你如何使用 AI、你选择什么样的工具，都会影响学习效果。如今一些主流 LLM 服务也开始提供更偏学习导向的模式，例如 Claude Code Learning and Explanatory 模式，以及 ChatGPT Study Mode。理解人类在使用 AI 时是如何学习的，也将反过来指导我们如何设计 AI：理想的 AI 辅助，不应只让人做事更快，也应帮助人一边更高效地工作，一边持续获得新技能。

此前关于 AI 是否会提升或损害编程生产力，研究结论并不一致。有研究认为 AI 有帮助，也有研究指出它可能起反作用。Anthropic 自己此前的研究曾发现，AI 能把某些工作任务的完成时间缩短 80%。这看起来似乎与本文结论相冲突，但两项研究问的其实不是同一个问题，采用的方法也不同：此前那项观察性研究考察的是，当参与者已经具备相关技能时，AI 如何影响生产力；而这次研究关注的是，当人们正在学习新东西时，会发生什么。因此，一种完全可能的情况是：AI 一方面会加速成熟技能上的产出，另一方面也会拖慢新技能的形成。当然，这一关系还需要更多研究去厘清。

这项研究只是理解“人类—AI 协作如何影响劳动者体验”的第一步。样本量仍然较小，而且本次评估只测量了编码任务结束后不久的理解情况；即时测验表现能否预测长期技能发展，仍是一个尚未解决的问题。未来还有许多问题值得继续研究：例如，AI 对编程之外任务的影响是否类似？随着工程师对 AI 工具愈发熟练，这种影响是否会随时间减弱？以及，在学习过程中，AI 辅助与人类辅导之间到底有何本质差异？

归根结底，如果我们希望在 AI 广泛存在的前提下，依然保住人的技能成长，就需要用更宽广的视角去理解 AI 对劳动者的影响。在一个被 AI 增强的工作场所里，生产力提升当然重要；但同样重要的，是那些支撑这些生产力增长的长期专业能力能否持续积累。

想看完整论文，可阅读：How AI Impacts Skill Formation。

致谢

本项目由 Judy Hanwen Shen 和 Alex Tamkin 牵头完成。本文的编辑支持来自 Jake Eaton、Stuart Ritchie 和 Sarah Pollack。

研究团队还感谢 Ethan Perez、Miranda Zhang 和 Henry Sleight——正是通过 Anthropic Safety Fellows Program，他们让该项目得以推进。同时也感谢 Matthew Jörke、Juliette Woodrow、Sarah Wu、Elizabeth Childs、Roshni Sahoo、Nate Rush、Julian Michael 和 Rose Wang 为实验设计提供的反馈。

欢迎关注我的其它发布渠道

WeChat