涌现观点|用 AI 写代码的那组,测验少了 17% Anthropic 这篇实验说清楚了原因

很多团队在晒「AI 让提效 80%」的 PPT。我看了那些曲线，第一反应不是兴奋，是担心：这 80% 是省下来的时间，还是省下来的理解？

最近我翻完 Anthropic 那篇 《How AI assistance impacts the formation of coding skills》^[1]，更确定了一件事：在「学新东西」这件事上，AI 辅助不是在帮你，是在替你。替多了，你就真的不会了。

借来的时间，还的是理解力

Gartner 有个预测：到 2028 年，90% 的企业软件工程师会用 AI 助手；2024 年初这个比例还不到 14%。
Anthropic 自己的观察研究也显示，用 Claude.ai 做任务，部分场景能快 80%。

快是快了。但另一批研究在说别的事：用 AI 的人更容易把思考交给机器，对工作投入变少，动脑变少。
所以真正的问题不是「快了多少」，而是「快的同时，你少学了什么」。

我自己的理解是：这有点像借高息贷款。当下进度条拉满，代价是理解力和对系统的掌控感。等你要还「利息」的时候，往往就是出大事的时候。

用 AI 的那组，测验直接掉两档

Anthropic 做了个随机对照实验：52 个软件工程师，学一个没用过的 Python 库（Trio），一半用 AI 辅助，一半手写。做完任务立刻测验。

结果很干脆：

也就是说：AI 组并没有在时间上赢多少，但在「刚学完的东西能不能答对」上输了一大截。
报告里写得很清楚：用 AI 辅助，和新东西学不扎实是明显相关的。调试题尤其如此，你少了自己踩坑、自己修，就少了一轮「真学会」的过程。

得分最低的那批人，是怎么用 AI 的

报告里把用 AI 的方式做了分类。得分最低的那几类，共性都是「尽量让 AI 干，自己少想」。

一类是几乎全权交给 AI：需求贴过去，代码贴回来，自己只负责复制粘贴。
一类是开头还自己写几行，一卡住就全部交给 AI。
还有一类是写还是自己写，但一报错就扔给 AI 修，不问「为什么错」，只问「怎么改能过」。

共同点是：代码能跑，但对背后的机制（比如 Trio 的异步模型）没建起清晰的理解。
报告里提到，有人会在侧边栏里反复问「这段为什么跑不通」，却很少去啃文档里的概念。结果就是任务交差了，测验崩了。

这种「能跑就行」的用法，在真实世界里已经出过事。2025 年 7 月 Replit 的删库事件里，一个 AI 代理在代码冻结期内动了生产库，删掉了约 1200 名高管的数据。事后负责人说：几秒钟毁掉了几个月的工作。
没人想当下一个这种案例。要避免，就得有人真的懂系统在干什么，而不是只懂「AI 给了什么」。

高分的那批人，把 AI 当讲解员

同一批实验里，也有一批人分数很高。他们的用法不一样：少要「直接给我代码」，多要「先讲清楚这个概念」「这段为什么这样写」。

有的人是先把代码生成出来，再专门追问 AI：这段在干什么？为什么用这个 API？
有的人是一开始就问概念，再自己写，错了再针对性问。
报告里有个出乎意料的结果：那种「只问概念、自己多写」的人，完成速度排第二，仅次于完全委派给 AI 的人。也就是说，多花一点时间在「搞懂」上，并没有拖慢多少，但测验分数拉出一大截。

Reddit 上有人总结得挺准：敲进去 AI 生成的代码本身没优势，有没有优势看你愿不愿意多花心思去搞懂。
区别就在于：你是把 AI 当自动补全，还是当可以追问的讲解员。

AI 写得多，谁在兜底？

GitClear 扫过 2 亿多行代码后的结论是：AI 生成的代码让重复率明显上升，大家却越来越少做重构。
也就是说，代码变多、变像，但未必更好维护。长期下去，谁来理清这一团，谁能在没有 AI 的时候修得了 Bug，会越来越成问题。

IMF 2026 年的一份讨论稿里提到：在 AI 技能需求高的地区，中等技能白领的就业水平比其它地区低 3.6%。
我读下来的感受是：如果初级工程师从一开始就靠 AI 出活、少了自己踩坑和修 Bug，几年后他们升上去做架构、做决策，谁还能在 AI 挂掉或不够用时兜底？

所以我会更看重「没有 AI 时还能不能把事说清楚、把系统修好」的人。会写 Prompt 有用，但会解释代码、会排查根因，在接下来几年里仍然稀缺。

刻意保留一点「学习难度」

教育学里有个概念叫「生产性失败」：先让人在任务里卡住、暴露出自己哪里不会，再给讲解或工具，理解会更深。Manu Kapur 用大量实验验证过这一点。
对应到编程上，就是：先自己试、自己错、自己调，再借助 AI，比一上来就全交给 AI 更能形成长期能力。

所以我会更在意「怎么用 AI」，而不是「用不用 AI」。
几个可以落地的做法：

• 让 AI 先给多套方案或思路，人来做选择和取舍，而不是直接要最终代码。
• 对新人，在一定时期内限制或关闭自动补全，逼他们自己查文档、记 API。
• 在评审或周会里，随机抽一段 AI 生成的代码，让写的人脱离 AI 讲清楚每一段在干什么。讲不清的，就视为技术债，要补文档或重构。

Claude 和 ChatGPT 都有「学习/解释」类模式，会先问你「你打算怎么做」「你卡在哪」，再给建议，而不是一上来就贴代码。这类模式更适合「学新库、新框架」的场景。

写在最后

Anthropic 这份实验的结论很明确：在学新技能的时候，用 AI 辅助写代码，会明显拉低后面测验的表现，平均约 17%，调试题上尤其明显；完成时间上反而没拉开差距。
低分者多半是「委派」「渐进依赖」或「一报错就扔给 AI 修」；高分者多半在「概念」上花时间，把 AI 当讲解员而不是出代码的工具。

对团队来说，效率数字好看是一面，另一面是：谁在真正理解系统？谁在 AI 不可用时还能修能改？
那 17% 的分差，更像是提醒：别用「提速」换掉「学会」。
你更在意短期交付速度，还是长期能解释、能兜底的人？怎么选，每个团队自己定。