Anthropic揭秘6种AI使用方式，你是“越用越会”还是“越用越废”

上周帮朋友调试一段Python异步代码时，他突然盯着屏幕叹气：“现在写代码全靠Copilot自动补全，上次被问Trio库的调试逻辑，我居然卡壳了——明明前阵子刚用它做过项目。”

这句话像个引子，正好点到了我读《AI如何影响技能形成》（How AI Impacts Skill Formation）这篇论文时的困惑：AI确实能帮我们快速搞定当下的任务，但那些“跳过思考直接得到答案”的瞬间，会不会正在悄悄偷走我们未来的专业能力？

我们解读最新技术，文末有相关信息。

作者：张长旺，图源：旺知识

这篇由Judy Hanwen Shen和Alex Tamkin（来自Anthropic）撰写的研究，没有堆砌复杂的算法公式，而是做了一个特别“接地气”的实验——让52名有Python经验但没接触过Trio库（一种异步编程工具）的开发者，分成两组完成相同的编码任务：一组用AI辅助，一组纯靠自己。结果非常意外：用AI的组，虽然都完成了任务，但后续的技能测试得分比不用AI的组低了17%，相当于从“良好”掉到“及格”；更有意思的是，AI组平均完成时间居然没比对照组快多少。

你有没有过类似的经历？用AI写完报告、编完代码，看似高效，可事后被问起细节时，脑子里一片空白？这篇论文其实就是在拆解这个“效率幻觉”背后的逻辑——我们以为AI是“工具”，却不小心把它变成了“拐杖”，久而久之，连自己走路的能力都忘了。

先搞懂一个关键问题：为什么AI会让我们“看似会了，实则不会”？

在聊实验细节前，我想先聊一个更本质的话题：为什么用AI学新技能，容易陷入“完成任务≠学会”的陷阱？

论文里提到一个词叫“认知卸载”（Cognitive Offloading），我更愿意把它比作“用导航开车”。你肯定有过这种体验：跟着导航走，哪怕走了十次，下次没导航还是找不到路；可如果第一次自己查地图、记路标，哪怕慢一点，下次也能独立找到。AI辅助学习，其实就是这种“导航效应”的放大版——它帮你跳过了“迷路、找路、记路”的过程，直接把你送到“任务完成”的终点，可那些“找路”时积累的理解和经验，才是真正的技能。

这篇论文选择“异步编程库”作为实验对象，特别巧妙。Trio不像Python的基础语法那样人人熟悉，它涉及“结构化并发”“协程”这些需要理解的概念，就像学一门新乐器的“指法”——你不能只靠AI帮你弹出曲子，得自己懂指法原理，才能应对不同的乐谱。

实验设计很简单但严谨：两组开发者都要在35分钟内完成两个Trio任务（比如写一个并发计时器、处理数据检索错误），AI组可以用基于GPT-4o的助手，对照组只能靠文档和搜索；任务结束后，所有人都要做一套14题的测试（包括概念理解、代码阅读、调试），而且测试时都不能用AI。

结果最让我印象深刻的不是“AI组得分低”，而是得分差距的分布：调试题的差距最大，代码阅读题差距最小。这像极了我们用AI的真实场景——AI能帮你生成代码，你多少会看一眼代码（所以阅读能力没差太多），但它不会帮你“犯错误”，而调试能力恰恰是在“犯错-查错-改对”的过程中练出来的。 对照组的开发者，平均每人会遇到3个错误，而AI组只遇到1个——那些被AI避开的错误，其实正是理解Trio库的关键“知识点”。

你可能会问：“那AI组至少快吧？”还真没有。论文里说，AI组虽然100%完成了任务（对照组有4人没做完），但平均时间只比对照组少了1.5分钟，而且有不少人花了大量时间和AI“沟通”——有人最多问了15个问题，有人写一个查询就花了6分钟。这像不像你用AI时的状态？为了让AI生成符合要求的代码，反复调整提示词，最后反而比自己写还累？

六种AI使用方式：为什么有人用AI也能学好，有人却越用越废？

这篇论文最有价值的部分，不是告诉我们“AI有害技能”，而是拆解了开发者和AI互动的六种模式——这才是真正能指导我们“正确用AI”的干货。

研究者通过屏幕录像，观察了25名AI组参与者的每一次操作，最后归纳出三类“高技能保留”模式和三类“低技能保留”模式。看完这些模式，我立刻对照了自己用AI的习惯，发现自己偶尔也会踩“低技能”的坑。

先看最危险的三种“低技能模式”，你大概率也中招过：

AI完全委托：4个参与者直接让AI写完整代码，自己复制粘贴就完事儿。他们是AI组里最快的（平均19.5分钟），但测试得分最低（39%）。这就像学生抄作业，作业交了，知识点一点没懂。

渐进式依赖：4个参与者一开始还自己写，遇到困难就全交给AI。比如有人写Task1时还查文档，写Task2时直接问AI“帮我完成get_user_data函数”。这种“半放弃”状态最容易让人产生“我会了”的错觉，最后测试得分也只有35%。

迭代式AI调试：4个参与者反复让AI帮忙找错，比如把报错信息直接粘贴给AI，让AI改代码。他们花的时间最长（平均31分钟），得分却最低（24%）。这像极了遇到bug不自己看日志，全靠AI“救命”的开发者——下次遇到类似bug，还是不会修。

再看三种能“保留技能”的高认知模式，值得我们借鉴：

概念查询型：7个参与者只让AI解释概念，比如“trio.sleep能支持小数秒吗？”“start_soon函数为什么不返回值？”，代码还是自己写。他们是高分组里最快的（平均22分钟），得分65%。这就像遇到问题先问老师“原理”，再自己动手做，既省时间又学得到东西。

混合代码解释型：3个参与者让AI生成代码时，会加一句“顺便解释下这段代码里的nursery机制”。他们花的时间和对照组差不多，但得分68%。这种方式把AI变成了“带讲解的参考答案”，而不是“直接给答案的作弊工具”。

生成后理解型：2个参与者先让AI生成代码，然后逐行问AI“这里为什么用await？”“这个错误处理逻辑是怎么考虑的”。他们得分最高（86%），虽然花了24分钟，但真正把AI的知识变成了自己的。这让我想起高中时的学习方法：先看例题，再自己推导一遍，比单纯刷题有效得多。

看到这里你可能会发现：这三种高技能模式，本质上都抓住了一个核心——让AI负责“解释”，而不是“代劳”。就像好的老师不会帮你做题，而是帮你理解题目；好的AI使用方式，也不是让它帮你完成任务，而是帮你扫清理解障碍。

论文里有个细节特别戳我：高分组的参与者，哪怕用了AI，也会自己主动“制造”思考机会。比如有人会故意把AI生成的代码改几个地方，看会不会报错；有人会先自己写一段，再让AI检查——这种“主动找茬”的行为，恰恰是技能形成的关键。而低分组的参与者，大多是“AI给什么就用什么”，连代码里的变量名错了都没发现。

不止是编程：AI时代，我们该如何守护“不可替代的技能”？

读到论文的讨论部分时，我突然想到一个跨领域的例子：医学领域有研究发现，依赖AI辅助诊断的医生，阅片能力会逐渐下降（论文里引用了Macnamara等人2024年的研究）；就像用惯了计算器的人，会慢慢忘记乘法表——这不是AI的错，而是我们使用AI的方式出了问题。

这篇论文给我的最大启发，不是“少用AI”，而是“重新定义AI的角色”。在技能学习中，AI不该是“执行者”，而该是“脚手架”——它帮你搭起框架，让你更容易往上爬，但爬的过程还得靠自己。

比如我现在用AI写代码时，会刻意做三件事：

先自己写核心逻辑，遇到不懂的概念再问AI（比如“Trio的memory channel怎么用”），而不是直接让AI写完整函数；

AI生成代码后，我会逐行注释，解释每个部分的作用——如果说不出理由，就再问AI“这里为什么要这么写”；

故意删掉AI生成的错误处理部分，自己写一遍，对比和AI的差异——这种“主动犯错”的练习，比单纯看AI的代码记得更牢。

对企业来说，这篇论文的警示也很重要。现在很多公司鼓励员工用AI提高效率，但很少关注“员工是否真的学会了新技能”。 就像论文里说的：“在安全关键领域（比如医疗、航空软件），人类需要具备调试AI代码的能力，如果员工的技能被AI削弱，最终会带来更大的风险。”

比如一个刚入职的程序员，用AI快速完成了项目，看似高效，但半年后还是不懂底层逻辑，遇到复杂问题还是要靠资深同事——这其实是企业的“隐性成本”。或许企业可以借鉴论文里的高认知模式，比如要求员工用AI时，同步提交“AI使用笔记”，记录自己从AI那里学到的概念，而不是只提交最终代码。

最后想说：AI能帮我们解决问题，但带我们走得更远的是“理解”

读这篇论文时，我总会想起《小王子》里的一句话：“真正重要的东西，眼睛是看不见的。”

AI能帮我们看到“完成的代码”“运行的结果”这些看得见的东西，但那些“为什么这么写”“报错了该怎么查”的理解，是AI给不了的，只能靠自己一点点积累。 就像学做饭，AI能给你菜谱，但你得自己试错才知道“火候大了会糊”“盐放多了会咸”——这些试错的经历，才是真正的“厨艺”。

或许未来的“技能竞争”，不再是“谁能用AI完成更多任务”，而是“谁能用AI更快学会新技能”。 毕竟，AI的迭代速度越来越快，今天流行的工具，明天可能就被淘汰，但那些“理解原理、解决问题”的底层能力，永远不会过时。

下次你用AI写代码、做报告时，不妨多问自己一句：“我真的理解这里面的逻辑吗？”——这句简单的自问，可能比多完成一个任务，更能帮你在AI时代走得稳、走得远。

参考资料

标题： How AI Impacts Skill Formation

作者： Judy Hanwen Shen、Alex Tamkin

单位： Anthropic

链接： https://arxiv.org/pdf/2601.20245