Anthropic 自己做了个实验，然后亲手打了自己产品一巴掌。
Anthropic 刚刚发布了一篇研究论文，专门探讨一个扎心的问题：用 AI 辅助写代码，会不会让程序员变得更菜？
结果令人意外：
用了 AI 的程序员，测验分数比不用的低了 17%，相当于直降两个等级。
实验怎么做的？
研究团队招募了 52 名初级软件工程师，要求是：Python 至少用了一年，每周都在写；用过 AI 编程助手；但没接触过 Trio 这个 Python 异步编程库。
然后把他们随机分成两组：
AI 组：可以用 AI 助手帮忙写代码
对照组：只能靠自己!
两组人都要用 Trio 完成两个编程任务，然后立刻参加一个测验，考察他们对刚才用到的概念的理解程度。
结果……
速度上，AI 组平均快了大约两分钟，但这个差异在统计学上不显著。
但在理解程度上，AI 组的平均分只有 50%，而手写代码组是 67%，差了 17 个百分点。
而让人扎心的是，两组差距最大的题目是调试类问题。
也就是说，用 AI 写代码的人，在「找 bug」这件事上明显更弱。
没准，当未来的代码越来越多由 AI 来写，人类程序员最重要的工作就是审查和调试这些代码。
但如果程序员从一开始就靠 AI，连调试能力都没练出来，谁来给 AI 兜底呢？
为什么会这样呢？
研究者通过录屏分析了每个参与者的行为模式，发现了一个有趣的现象：
有些人花了大量时间跟 AI 对话：最多的一位发了 15 条消息，光是打字和思考问题就花了 11 分钟，占总时间的 30%。
这也解释了为什么 AI 组没有快多少：省下的写代码时间，都花在跟 AI 聊天上了。
而对照组虽然遇到了更多错误，但正是在独立解决这些错误的过程中，他们真正理解了 Trio 库的工作原理。
不是所有用法都一样
研究者把 AI 组的行为模式分成了六种，其中三种得分很低，三种得分较高。
低分模式（平均分低于 40%）：
完全委托型：让 AI 写全部代码，速度最快，但啥也没学到
渐进依赖型：一开始还问问问题，后来干脆全交给 AI
反复调试型：遇到 bug 就问 AI，自己不思考，结果又慢又不学东西
高分模式（平均分 65% 以上）：
先生成后理解型：让 AI 写完代码后，追问原理和解释
混合解释型：每次让 AI 写代码时都要求附带解释
纯概念型：只问概念性问题，代码自己写，虽然报错多，但最终理解最深
看出区别了吗？
高分组的共同特点是：保持思考。
他们不是不用 AI，而是用 AI 来帮助理解，而不是替代思考。
这意味着什么？
研究认为：在工作中激进地使用 AI，可能会阻碍技能发展。
这对初级工程师尤其危险。在时间压力下，新手程序员很可能为了快速完成任务而重度依赖 AI，代价是：他们可能永远学不会真正需要的技能。
当企业越来越多地用 AI 来写代码，但负责审查这些代码的人却是「被 AI 养大」的工程师，这里面的风险不言而喻。
研究者建议：
管理者在推广 AI 工具时，要有意识地保护员工的学习机会
初级工程师要明白，痛苦地卡住、报错、调试，其实是学习的必经之路
AI 产品的设计者也应该思考，如何让工具既提升效率，又不损害学习
事实上，主流 LLM 服务已经开始提供「学习模式」。
比如 Claude Code 的 Learning/Explanatory 模式，以及 ChatGPT 的 Study Mode。这些功能的设计初衷，就是为了减轻「认知卸载」的副作用。
研究的局限
研究者也承认，这项研究有其局限性：
样本量较小（52 人）
只测量了即时理解，不知道长期影响如何
任务只涉及一个 Python 库，可能无法推广到所有场景
使用的是聊天式 AI 助手，如果是 Claude Code 这种更自动化的 Agent，效果可能更极端
但无论如何，该项研究给我们的启示是：
AI 可以让你更快，但不一定能让你更强。
如果你正在学习编程，或者带团队的新人，不妨想想：效率和学习之间，如何找到平衡？
毕竟，最好的工具是让人变强的工具，而不是让人变成工具的工具。
热门跟贴