Anthropic ：AI Coding 是如何造成你的职业技能衰退，你是如何一步步被蒙蔽

近日，Anthropic 发布了 《How AI assistance impacts the formation of coding skills》 ，这篇论文主要核心解释了一个问题：AI 写代码能让你更快交付，但会不会让你“学得更慢、懂得更少”？

因为 Anthropic 发现，在对 Claude.ai 数据的观察性研究中，虽然 AI 可以将某些任务的速度提高 80%，但这种生产力的提升是否会带来一些弊端呢？因为有其他研究表明，当人们使用 AI 辅助时，他们对工作的投入度会降低 ，投入的精力也会减少 ，换句话说：

或者再贴近生活点，你多久没有自己从头到尾阅读一篇文章或者论文了？你是不是都是通过 AI 去总结和思考，是不是只是在获得知识，而不是学会技能？

所以 Anthropic 这篇研究主要测试的是被试者的学习速度和掌握程度：

• 让开发者在短时间内学习一个自己没用过的 Python 异步库（Trio），做两段功能开发，然后立刻做测验，看是否真正理解“刚刚用到的概念”

• 用测验题覆盖他们刚刚接触到的关键能力：

  • Debugging（定位/解释错误）
  • Code reading（读懂代码在干嘛）
  • Code writing（选择正确写法/方法）
  • Conceptual（概念理解）

为了比“问卷”更有说服力，这是一个随机对比实验，而且对象是真实软件工程师：

• 受试者：52 名（多数偏初级）工程师，Python 使用至少 1 年且每周都用，没用过 Trio，但又要对 AI 辅助写码不陌生
• 过程：热身 → 用 Trio 写两个功能（像自学教程那种：题目 + starter code + 简短概念说明）→ 立刻测验
• AI 组：侧边栏有 AI 助手，能读到当前代码，也“随时可以在你要求时给出正确代码”
• 在这个过程里还做了定性分析：人工标注屏幕录制，统计花多少时间问 AI、问了什么类型的问题、哪里出错、是否自己动手改等

这套设计的目的不是让被试者主观汇报“我觉得我学会了/我觉得我更快了”，而是让你做题来验证“你到底会不会” 。

而测试结果也很出乎意料：更快一点点，但懂得少一截 ，根据结果可以看到：

• 速度提升不明显：AI 组平均快大约 2 分钟，但没达到统计显著，对此作者也解释：这类任务是“学习新库 + 非重复性”，AI 的生产力优势不一定能充分体现，AI 更可能在“熟悉/重复性任务”上显著提速。

• 掌握程度显著下降

  • AI 组测验平均 50%
  • 手写组平均 67%

差距相当于“接近两个等级”（例如从 B 跌到 D 的差距），并且统计上显著（文中给了 Cohen’s d=0.738, p=0.01，最明显的差距出现在 Debugging 题：也就是“知道哪里不对、为什么不对”，这对“AI 时代的工程师”反而是更关键的能力。

所以针对结果可以总结：AI 没让你稳定更快，但更容易让你“做完了却没学会”。

而对于这篇论文，最有价值的部分不是“用 AI 就完了”，而是“你怎么用” ，作者发现 AI 并不必然导致低分，关键在“交互模式”，他们从录屏里归纳出 6 种模式，并且能对应到明显不同的学习结果：

一、低分模式：把脑子外包给 AI（cognitive offloading）

这些模式平均分 < 40%：

1、AI delegation（完全委托写代码）

• 最快、几乎不出错（因为 AI 帮你躲开了错误）
• 但测验最差：被试人没经历“犯错—定位—修复—理解”的循环

2、Progressive AI reliance（越写越依赖）

• 一开始问一两次，后面逐渐把写法都交给 AI
• 特别是第二个任务的概念更没掌握

3、Iterative AI debugging（让 AI 负责排错/验证）

• 问得多，但问法是“帮我修/帮我确认对不对”
• 结果既不快、也没学会（因为关键的诊断推理被外包了）

这里有个很反直觉的点：

二、高分模式：用 AI 当“解释器/教练”，而不是“代写员”

作者把平均分 ≥65% 的行为看成“保学习”的模式：

1、Generation-then-comprehension（先生成，再逼自己理解）

• 看起来和“全委托”很像：也是先让 AI 给代码
• 但差别在于：后续会追问解释、验证理解，再自己整合

2、Hybrid code-explanation（要代码也要解释）

• 提示词里同时要求：生成 + 逐段解释/关键概念说明
• 更慢，但理解更好（你花时间读解释）

3、Conceptual inquiry（只问概念，不让它替你写）

• 只问“Trio 的这个机制是什么/为什么这么写”
• 代码主要自己写；错误也自己修
• 这个模式在高分里反而速度还不错（总体第二快，仅次于完全委托）

当然，作何也认为这不只是“写码圈焦虑” ，论文认为，AI 会让人降低认知投入、更不投入地完成任务（cognitive offloading） ，例如：

• 一篇 Microsoft Research 的工作（知识工作者调查）讨论了：在使用生成式 AI 时，人们会自我报告“认知努力降低”，且“对 AI 更有信心”与“更少进行批判性思考”相关
• 还有研究指出人机协作可能提升即时表现，但对后续独立工作/动机等带来复杂影响

所以可以认为，使用 AI 的过程，就是一个把“认知外包”的过程，这个过程现在从抽象概念落到了一个非常具体的技能上：异步编程库的学习与调试能力 。

这和之前大家关心的“Agent/自动化把活干完”是同一条线：

• 自动化越强，人类越像“监督者”
• 但监督者最需要的技能（读懂、诊断、概念把握）却可能被自动化削弱

于是出现一种结构性悖论：越依赖 AI，越缺乏监督 AI 的能力。

那怎么把这篇研究落到开发者日常用 AI 写码”？如何“既提速又不丢技能”，其实可以直接对照他们的高分模式，做几个很具体的操作习惯：

• 默认不让 AI 直接给最终代码，先让它解释概念/给方案/指出坑点；你自己写第一版。

• 如果要生成代码：强制解释 + 你复述，例如提示词里加两句：

  • “先给代码，再逐段解释每一段为什么需要。”
  • “最后用三条 bullet 总结该库/该模式的约束。”

• Debug 时别让 AI 直接修，先让它“定位与假设”

  • 让它列出 3 个可能原因 + 你应该如何验证（打印什么、看哪段源码、查哪个 API 合同），这能把“诊断推理”留在你这边，而不是直接外包成补丁。

• 把“卡住”当作训练，而不是失败，文章的过程其实明确表达过：认知努力、甚至“痛苦地卡住”，可能正是形成掌握度的重要条件

当然，作者自己也承认它是“第一步”，因此具备局限性：

• 样本量不大（52 人）
• 测的是“刚学完立刻测验”的短期理解，长期是否会追平还未知
• 任务是“学新库”，不等同于你平时做的所有开发（比如熟悉业务的 CRUD、重构、加测试等）

所以它更合理的结论不是“AI 会让人变菜”，而是：

而更长远的考虑是，你是不是在使用 AI 的过程中丧失了思考，随着 AI 越来越强，你是不是越来越弱？特别是初级工程师，过度依赖 AI 可能会导致“技能发育不良”：

而对企业/管理者，短期生产力的提升（AI 带来的效率）可能以长期专业能力的流失为代价，如果工程师失去了审查和调试 AI 代码的能力，未来的系统风险将增加。

参考原文

www.anthropic.com/research/AI…