AI编程如何导致职业技能衰退，你一步步被蒙蔽

最近，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，越缺乏监督AI的能力。

那么，日常开发中如何在“提速”与“保技能”之间找到平衡？可直接对照高分模式，形成具体操作习惯：

• 默认不让AI直接给最终代码。先让它解释概念、给方案、指出坑点；自己写第一版。
• 若生成代码，强制加解释和复述。例如在提示词中明确要求：“先给代码，再逐段解释每一段为什么需要”，以及“最后用三条bullet总结该库/该模式的约束”。
• Debug时别让AI直接修，先让它“定位与假设”。让它列出3个可能原因，以及应如何验证（打印什么、看哪段源码、查哪个API合同）。这样就将“诊断推理”留在了你这边。
• 把“卡住”当作训练。认知努力，甚至“痛苦地卡住”的体验，可能是形成真正掌握度的重要条件。

当然，研究也有局限性：样本量不大（52人），测试的是“刚学完立刻测验”的短期理解，任务是“学新库”，不等于日常所有场景。因此更合理的结论不是“AI会让人变菜”，而是：AI本身不是问题，关键在于你使用它的方式。

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