Anthropic实锤了：用AI写代码的程序员，正在批量"退化"！

无亟

Anthropic实锤了：用AI写代码的程序员，正在批量"退化"！


咱们聊个有意思的话题。如果你是程序员，或者你身边有程序员朋友，你肯定见过这样的场景：遇到个难题，或者要写个新功能，第一反应不再是翻文档，而是打开 AI 聊天窗口，把需求一说，一段代码就生成了。确实快，确实方便，感觉工作效率坐上了火箭。

但有没有那么一瞬间，你会隐隐觉得不安？这种“外包”给 AI 的思考方式，长期下来，会不会让我们的真本事打了折扣？

这可不是杞人忧天。最近，知名 AI 公司 Anthropic（也就是开发 Claude 的那家）就正儿八经地做了个研究，想看看 AI 辅助写代码，到底会不会影响我们学习新技能。结果嘛，可以说有点扎心，但又在意料之中。

1、一场精心设计的“考试”

Anthropic 找来了 52 名有一定经验的软件工程师，让他们学习一个他们从没接触过的 Python 库，然后用它来完成几个编程任务。

他们把这些工程师分成了两组。一组是“AI 辅助组”，可以随时随地向 AI 助手提问，让它帮忙写代码、解释概念。另一组是“手动编码组”，就像我们以前学习那样，只能靠自己看文档、独立思考来解决问题。

任务完成后，所有人都要参加一个闭卷考试，考的就是刚刚用到的那个新库的知识。这场考试很关键，它不只考你记住了什么代码，还考察了更深层次的能力，比如：

- 调试能力：给你一段有问题的代码，你能不能找出毛病在哪，并且知道为什么会出错。

- 代码阅读能力：给你一段代码，你能不能看懂它是干嘛的。

- 代码编写能力：让你从头写一段代码解决问题。

- 概念理解能力：你是否真的理解了这个工具背后的核心原理。

你看，这套考察方式非常全面，它想弄明白的，是你到底“学会了”，还是仅仅“完成了”。

2、结果出炉，有点尴尬

好了，激动人心的结果来了。你猜怎么着？

在最后的测试中，“AI 辅助组”的平均分是 50 分，而“手动编码组”的平均分是 67 分。整整差了 17 个百分点。这是什么概念？差不多就是从 B+掉到了 C 的水平，两个字母等级的差距。

更让人意外的是，大家普遍以为用了 AI 效率会高很多，但研究发现，AI 组完成任务的平均时间只比手动组快了大概两分钟，这个差距在统计学上都算不上显著。

也就是说，为了那微不足道的两分钟，AI 组的成员们牺牲了对新知识近两成的掌握度。这笔账算下来，好像不太划算。

研究还发现了一个特别值得警惕的现象：两组分数差距最大的部分，恰恰是“调试能力”。那些依赖 AI 的工程师，在辨别和理解代码错误方面表现得最差。这其实很可怕，因为在实际工作中，AI 生成的代码并非永远正确，我们作为人类工程师的最终价值，很大程度上就体现在这种审查、纠错和把控全局的能力上。如果连这个能力都退化了，我们和单纯的“代码搬运工”还有什么区别呢？

3、问题的关键：你把 AI 当“拐杖”还是“导师”？

看到这里，你可能会想：那是不是我们应该抵制 AI，回归原始的手动编程？

别急，研究的发现并没有这么简单粗暴。Anthropic 的科学家们通过观察工程师们与 AI 的互动录屏，发现了一个更有趣的结论：用不用 AI 不是关键，关键在于“怎么用”。

他们发现，那些分数很低的工程师，通常有这么几种典型的“坏习惯”：

1. 甩手掌柜式（AI delegation）：这些人从头到尾就一句话，“帮我写个实现这个功能的代码”。AI 给什么，他们就用什么，自己完全不思考。他们完成任务最快，但学到的东西也最少，分数自然垫底。

2. 渐进依赖式（Progressive AI reliance）：一开始还想自己试试，但稍微遇到点困难，就立刻转向 AI。慢慢地，就变成了完全依赖，把思考的责任全部推给了 AI。

3. 迭代调试式（Iterative AI debugging）：自己写了代码，一运行报错，看都不看错误信息，直接把错误连同代码一起丢给 AI，“帮我看看哪错了”。他们把 AI 当成了一个无情的改错机器，而不是一个帮助自己理解问题的老师。

发现了吗？这些低分模式的共同点，就是“认知外包”。他们主动放弃了思考、挣扎和犯错的机会，只想尽快拿到一个能运行的结果。

与之相对的，那些同样使用了 AI 但取得了高分的工程师，他们的用法就完全不同了：

1. 先生成后理解式（Generation-then-comprehension）：他们也会让 AI 生成代码，但代码到手后，他们会仔细阅读，然后追问 AI：“你为什么要用这个函数？”“这部分代码的逻辑能给我解释一下吗？”。他们把 AI 当成了一个可以随时请教的专家，用它来加深自己的理解。

2. 代码解释混合式（Hybrid code-explanation）：这些人在提问时就很有策略，他们会说：“请帮我写一段代码实现这个功能，并解释一下关键部分的原理。”他们从一开始就没把“代码”和“理解”分开，追求的是知其然，更知其所以然。

3. 概念探究式（Conceptual inquiry）：这是最高阶的用法。这些人几乎不让 AI 直接写代码。他们只问概念性的问题，比如：“在这个库里，处理并发的最佳实践是什么？”“A 方法和 B 方法有什么区别？”。他们把 AI 当作一个知识渊博的顾问，获取高层次的指导，然后自己动手去实践。他们完成任务的速度也很快，而且因为亲手解决了所有错误，学得非常扎实。

这些高分模式的共同点，是把 AI 当成了一个增强自己思考能力的杠杆，而不是替代自己思考的拐杖。他们始终是学习的主导者，AI 只是他们手中的一个强大工具。

4、拥抱“必要的痛苦”

这个研究其实揭示了一个我们既熟悉又常常想逃避的学习真理：真正的成长，离不开认知上的努力，甚至离不开“被卡住”时的那种痛苦。

研究发现，手动编码组的成员遇到的错误远比 AI 组多。但正是这一次次独立解决错误的过程，让他们对知识的理解更加深刻，调试能力也得到了实打实的锻炼。这就像健身，只有当你感觉到肌肉的酸痛，它才在真正地生长。轻松完成的重复动作，带来的效果微乎其微。

在追求效率的今天，我们很容易把“顺畅”和“高效”划等号，把“卡顿”和“挣扎”看作是需要尽快消除的障碍。但这项研究提醒我们，在学习新技能的领域，这种“必要的痛苦”恰恰是通往精通的必经之路。如果我们总是利用 AI 绕开这些困难，我们可能也就绕开了真正的成长。

5、写在最后：我们该怎么办？

那么，面对 AI 这把双刃剑，我们普通人，尤其是处于学习阶段的新人，到底该怎么办？

首先，要清醒地认识到，AI 在不同场景下的作用是不同的。对于你已经非常熟悉的任务，AI 可以作为强大的生产力放大器，帮你处理重复性工作。但当你学习一个全新领域时，就要警惕它可能带来的“学习短路”。

其次，要有意识地选择“高分用法”。下次再向 AI 提问时，不妨多问一句“为什么”。在复制粘贴 AI 生成的代码之前，先花几分钟读懂它。甚至可以挑战一下自己，只向 AI 问概念，然后逼自己把代码写出来。值得一提的是，像 Claude 和 ChatGPT 这样主流的 AI 工具，其实已经内置了类似“学习模式”的功能，它们可以引导你进行解释性和探索性的学习，这本身就是一种很好的工具设计。

对于企业和团队管理者来说，这个研究同样具有重要的警示意义。在推动团队拥抱 AI、提升效率的同时，更要思考如何为新人，特别是初级工程师，创造一个能够让他们“安全地犯错和挣扎”的环境。不能因为追求短期的项目速度，而牺牲了团队成员长期的技能成长。毕竟，一个团队的根基，永远是那些能够解决复杂问题、能够审查和驾驭 AI 的真人专家。

总而言之，AI 的浪潮无法阻挡，它是一个能极大解放我们生产力的工具。但工具终究是工具，是成为它的主人，利用它增强自己的智慧；还是成为它的奴隶，让自己的思考能力逐渐萎缩，选择权，始终在我们自己手里。

###