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

最近，Anthropic 发布了一篇研究，标题挺长的，但核心问题很简单：AI 帮你写代码，到底是帮你更快，还是在让你更慢地学会东西？

说个稍微反直觉的结论：用 AI 辅助，某些任务的速度确实能提升 80%，但“做得快”和“学得会”之间，可能存在着一条微妙的鸿沟。更直白点讲，你有没有想过，自己有多久没有完整地、从头到尾读过一篇文章或一篇论文了？是不是习惯性地打开个 AI 总结，觉得“知道了”就划走了？这种从“获得知识”到“学会技能”的转变，恰恰是这篇研究想探讨的核心。

简单说，这是一次精心设计的随机对比实验，对象是 52 名真实的软件工程师（大多为初级水平）。他们需要用一个自己从未接触过的 Python 异步库（Trio）去完成开发任务，然后立刻接受测验，看看他们到底掌握了多少。

测验内容覆盖了 Debugging（错误定位与解释）、Code reading（代码理解）、Code writing（代码编写）和 Conceptual（概念理解）这几个关键能力。注意，这不是让他们自己填个问卷说“我觉得我学会了”，而是实打实地做题，验证你到底会不会。

结果呢？有点意思。

用 AI 的组平均只快了大约 2 分钟，这个差异在统计上并不显著。但测验成绩的差距就大了：AI 组平均得分 50%，而完全自己手写的组拿到了 67%——差出将近两个等级，从 B 直跌到 D。尤其在 Debugging 这类需要“知道问题在哪、为什么不对”的题目上，差距最为明显。而讽刺的是，这恰恰是 AI 时代对工程师更关键的能力。

所以，第一层的结论是：AI 并不一定能让你稳定地更快，但它更容易让你“做完了，却没学会”。

不过，这篇研究最有价值的部分，不是告诉你“用 AI 就完了”，而是探讨了“怎么用”才不至于丢了技能。研究者从录屏中归纳出 6 种交互模式，并且能直接对应到截然不同的学习结果。

低分模式：把脑子外包给 AI

这些模式的测验平均分普遍低于 40%，典型的“做了任务但没学到东西”。

• 完全委托写代码
  ：最快，几乎不出错（因为 AI 帮你躲开了所有坑），但测验结果最差。问题在于，你没有经历“犯错—定位—修复—理解”这个完整的学习闭环。

• 越写越依赖
  ：一开始还能问一两次，后面逐渐把写法和逻辑全部交给 AI，尤其对后面一个更复杂的概念掌握尤其差。

• 让 AI 负责排错
  ：问法往往是“帮我修一下”或“帮我确认对不对”，结果既不快，也没学会——因为关键的诊断推理被直接外包了。

高分模式：用 AI 当“教练”，而不是“代写员”

平均分 ≥65% 的模式，才是真正学会了的正确打开方式。

• 先生成，再逼自己理解
  ：看起来和“全委托”很像，也是先让 AI 给代码。但差别在于，你会在拿到代码后追问“为什么”，验证自己的理解，再自己动手整合。

• 要代码也要解释
  ：提示词里同时要求“生成代码 + 逐段解释”，这样你会花时间读解释，虽然慢，但理解更好。

• 只问概念，不让它替你写
  ：只问“Trio 的这个机制是什么”“为什么要这么写”，代码主要自己写，错误也自己修。这个模式在高分里速度反而第二快，仅次于完全委托。

这里有个很关键的点：使用 AI 的过程，本质上就是一个“认知外包”的过程。自动化越强，人类就越像监督者，但监督者最需要的技能——读懂、诊断、概念把握——却可能被自动化削弱。于是就形成了一种结构性悖论：

那么，落到日常开发中，怎么才能在“提速”和“保技能”之间找到平衡？其实可以直接对照上面那些高分模式，做几个非常具体的操作习惯：

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

• 如果要生成代码，强制加解释和复述
  。比如在提示词里明确要求：“先给代码，再逐段解释每一段为什么需要”，以及“最后用三条 bullet 总结该库/该模式的约束”。

• Debug 时别让 AI 直接修，先让它“定位与假设”
  。让它列出 3 个可能的原因，以及你应该如何验证（打印什么、看哪段源码、查哪个 API 合同）。这样就把“诊断推理”留在了你这边。

• 把“卡住”当作训练。
  认知努力，甚至那种“痛苦地卡住”的体验，可能正是形成真正掌握度的重要条件。

当然，研究本身也承认其局限性：样本量不大（52人），测的是“刚学完立刻测验”的短期理解，任务是“学新库”，不等于日常所有开发场景。所以它更合理的结论不是“AI 会让人变菜”，而是：

而对于企业和管理者来说，更长的考量是：短期生产效率的提升，是否正以长期专业能力的流失为代价？如果工程师逐渐失去了审查和调试 AI 代码的能力，未来的系统风险只会越来越大。