大家好，我是蔡荔。作为长期关注 AI 与编程的从业者，我一直有个担忧：AI 辅助编程在帮我们完成任务的同时，会不会悄悄抹去工程师本该在写代码过程中学到的核心技能？

传统编程强调“learning by doing”，通过反复调试、理解概念、独立解决问题来内化知识。但如果我们过度依赖 AI 生成代码、修复错误，会不会牺牲掉这种“认知挣扎”（cognitive struggle），导致技能形成受阻？

最近 Anthropic 发布的一项随机对照试验正好验证了我的担忧。这项研究聚焦于软件工程师学习新编程库时使用 AI 辅助的效果，不仅量化了生产力与技能之间的权衡，还通过定性分析揭示了不同使用方式带来的巨大差异。下面我按照原文逻辑，完整梳理这项研究的来龙去脉。

一、 为什么要做这个研究？

Anthropic 的研究源于一个更广泛的背景：AI 工具如 Claude 和 ChatGPT 已被证明能显著提升熟悉技能的生产力。根据他们的观测数据，在用户已掌握技能的场景中，AI 可将效率提升高达 80%。例如，在软件工程中，AI 可以加速代码编写、调试和文档查询。

然而，当涉及学习全新技能时，情况就复杂了。研究者担心，AI 可能会导致“认知卸载”（cognitive offloading），也就是说用户会把思考责任外包给AI，从而阻碍技能发展。

为什么选择软件工程作为测试领域？因为这个领域正快速自动化：Cursor、Claude Code 这样的AI辅助编程工具已能生成大量代码，但人类仍需监督输出、捕捉错误，尤其在高风险环境中（比如医疗软件或金融系统）。

如果初级工程师在学习新库时过度依赖 AI，他们可能无法掌握调试、代码阅读和概念理解这些核心技能，最终影响对 AI 的有效监督。

Anthropic 强调，这不仅仅是生产力问题，更是长期能力构建的挑战。他们希望通过数据指导 AI 产品设计、工作流程和政策制定，在生产力与技能之间找到平衡。

二、 实验的设计

为了严谨验证假设，Anthropic 设计了一个模拟职场学习的实验。参与者是 52 名软件工程师，主要为初级水平（经验至少一年，目前每周都有使用 Python，但从未接触实验所用库）。他们被随机分为两组，确保分组均衡（经验、性别等因素）。

• 任务设计：学习并使用一个全新异步 Python 库（Trio），完成两个编码任务，限时 35 分钟。这模拟了工程师在工作中自学新工具的常见场景。Trio 库的选择很巧妙：它相对新颖，概念复杂（涉及异步编程），但文档齐全，便于对照。
• 分组：
• AI 辅助组（Treatment Group）：AI 辅助组可自由使用聊天式 AI 助手（如 Claude）进行代码生成、解释或调试。
• 无 AI 对照组（Control Group）：仅靠官方文档和自身知识完成任务，不能使用 AI。
• 环境：所有参与者使用标准化 IDE，屏幕录像记录过程（用于后续分析）。实验后，立即进行无 AI 条件的知识测验。

所有参与者使用标准化 IDE，全程屏幕录像（用于后续分析）。实验后立即进行无 AI 条件的知识测验。这种随机分配的设计避免了观察性研究的偏差（比如自选使用 AI 的用户可能本就更高效），确保了因果关系的可靠性。

三、 设计的评估

评估的重点不在“任务是否完成”，而是聚焦四种核心编程技能，这些技能对未来人机协作至关重要（尤其监督 AI 输出）：

• 调试能力（Debugging）：识别并修复代码错误的能力。在 AI 时代，这是人类“纠错”AI 的关键价值。
• 代码阅读（Code Reading）：理解和验证代码逻辑的能力。如果看不懂 AI 生成的代码，监督就成空谈。
• 概念理解（Conceptual Understanding）：掌握库背后原理的能力。只有懂“为什么”，才能创新和监督。
• 代码编写（Code Writing）：系统设计和逻辑构建能力，强调非语法记忆的高阶技能。

测验采用混合题型：多选、代码解释、调试场景和编写片段，总分满分 100%。这些评估维度基于计算机科学教育标准，确保了可靠性和效度。

四、 实验结果如何？

实验数据直击要害：AI 辅助并非万能捷径。

• 生产力方面：AI 组平均完成任务快约 2 分钟（无 AI 组：约 25 分钟），但差异统计上不显著（p=0.391）。这出乎意料，因为先前研究显示 AI 可加速 50%以上。原因在于，AI 节省的编码时间常被“提示工程”（撰写查询）所抵消，有些参与者花高达 30% 时间优化提示，最多的问了 15 个问题。
• 技能得分方面：AI 组平均分仅 50%，比无 AI 组的 67% 低 17%（相当于两个字母等级；Cohen's d=0.738，p=0.010）。其中调试能力下降最严重（AI 组低 20% 以上），概念理解和代码阅读也显著受影响。代码编写差距较小，可能是因为任务相对简单。

这些量化结果验证了我的担忧：AI 带来的短期加速可能以长期技能为代价，尤其在学习新技能时。

下图展示了核心发现：

五、 为什么会这样？定性分析

通过分析 52 名参与者的屏幕录像，Anthropic 揭示了背后的“为什么”：AI 的影响取决于互动模式。

他们识别出六种使用模式，分为低技能（<40% 分）和高技能（≥65% 分）两类，核心差异是“认知参与”与“认知卸载”。

5.1 低技能模式（认知卸载主导）包括三种情况：

一是“AI 委托”：完全让 AI 生成代码，只做复制粘贴，速度最快但学习为零。二是“渐进依赖”：初始尝试后快速外包给 AI，导致第二个任务零学习。三是“迭代调试”：用 AI 修 bug，但不探究原因，调试分数极低。

5.2 高技能模式（认知参与主导）也有三种情况：

一是“生成后理解”：让 AI 生成代码后追问解释，主动验证。二是“混合解释”：同时请求代码和说明，确保同步学习。三是“概念探究”：只问高层次问题，自己编码和调试——这种模式既最快又分数最高。

无 AI 组的优势在于被迫独立面对错误，通过“挣扎”内化技能。Anthropic 强调，使用方式是关键：将 AI 视为“教练”而非“答案机”，才能避免代价。

下图详细展示了六种交互模式及其结果差异：

六、 结论与行动建议

这项研究证明：AI 辅助编程并非技能捷径——在学习新技能时，它可能加速微乎其微，却显著削弱理解，尤其是调试能力。

这验证了我的担忧：AI 抹去“认知挣扎”，可能导致工程师技能退化，影响高风险领域的监督能力。

但这并非宿命。通过高技能模式，我们能将 AI 转为学习伙伴。以下是我的行动建议：

• 对个人：优先进行概念提问，主动验证 AI 输出，保持“刻意练习”的习惯。
• 对团队：奖励学习导向的使用方式，评估不只看速度，还要看知识收获。
• 对 AI 开发者：设计“学习模式”（如 Claude 的代码解释功能），促进认知参与。

来源：

Anthropic 博客 https://www.anthropic.com/research/AI-assistance-coding-skills

论文： https://arxiv.org/abs/2601.20245v1