摘要：Anthropic 的随机对照实验里，用 AI 的一组测验低 17 个百分点，速度却没快到哪去。作者翻出更细的一层：差别不在动手多少，在遇到几个错误。这篇拆开退化发生在哪、六种用法里哪三种能保住能力，以及为什么你察觉不到自己在退。
有个问题我找了半个小时，最后是 AI 找到的。
那段代码没有报错。日志干净，监控正常，接口返回 200，只是某个数据计算的不对。我翻了链路、加了日志、读了配置，一直在等一个异常把我带到出错的地方——没有异常。
半年前不是这样。半年前我能从一行堆栈定位到第三层调用的参数错位，靠的是那种"这个位置不该出现这个值"的直觉。
现在我的第一反应是：把报错贴给AI。
我一直以为这是个错觉
刚开始用 AI 写代码那阵，我给自己找了套解释：工具变强了，人当然不用记那么多细节。编译器接管了寄存器，框架接管了样板，搜索引擎接管了 API 签名——每一层抽象都在替人卸货。凭什么到了 AI 这一层，就成了堕落？
这个解释听起来很顺，但它有个漏洞：它把"不记细节"和"看不懂"混成了一件事。
2026 年 1 月，Anthropic 的两位研究者 Judy Shen 和 Alex Tamkin 做了一次随机对照实验（arXiv:2601.20245）。52 名工程师，每周都在写 Python、且持续一年以上，但都没用过异步库 Trio。一半可以用 AI 辅助，一半只能靠自己。任务做完立刻考试，考的是刚用过的概念。
结果很干净：AI 组平均 50 分，手写组 67 分。17 个百分点，接近两个等级，效应量 d=0.738，p=0.010。
更值得看的是另一半——速度。AI 组平均快了两分钟，统计上不显著。
你花钱买的是"更少的时间"，拿到的是"更浅的理解"，而账单上写着"两分钟"。
问题不在手，在错误
如果故事到这里就结束，那它只是又一篇"AI 让人变笨"。真正让我停下来的是论文里的一张分解表。
按题型拆开看，两组差距最大的不是写代码题，是调试题。差距最小的，是代码阅读题。
那为什么偏偏是调试题？
阅读题差距小，好理解——两组在任务里读的代码量差不多。可调试题差这么多，就不能用"动手少了"解释了。手写组当然动的手多，可 AI 组也在动手：他们要看输出、要接受或拒绝建议、要把生成的代码贴进去。
答案是错误的数量，也就是练手的机会。整个任务过程中，对照组中位数遇到 3 个错误，AI 组只遇到 1 个。
那些错误不是噪音，是教材。论文特别提到，对照组撞上的多是跟 Trio 核心概念直接相关的报错（TypeError、RuntimeWarning），这种错误会逼着你去搞明白"这个库到底怎么调度协程"。AI 组没撞上几个——因为大部分坑在被看见之前就被填平了。
还有一个更扎人的对照：直接粘贴 AI 代码的人，和手动把代码抄一遍的人，测验分数没有显著差异。
抄一遍没用。你手在动，脑子没被迫动。真正决定学会没学会的，是你有没有被一个具体的错误卡住过，然后自己爬出来。
四十多年前就写好的剧本
1983 年，人因工程研究者 Lisanne Bainbridge 在《Automatica》上发过一篇五页的短文，叫《Ironies of Automation》。
她讲的是工厂和电厂的自动化，逻辑很朴素：设计者把能自动化的都交给机器，剩下没法自动化的才留给人。于是留给人的，恰恰是机器处理不了的那部分——异常、突发、极端情况。
而人平时已经不动手了。日常操作全由机器负责，人的工作变成在旁边盯着。长时间盯着一个几乎不出错的系统，本身就是人不擅长的事。等真正需要人接手，那些很久没练的技能早就生疏了。
四十三年后，这段描述放在 AI 编程上几乎不用改字。
只是生疏吗？有更硬的证据。2026 年发表在《IEEE Transactions on Software Engineering》上的一项交叉设计实验，69 名参与者（含 14 名职业开发者），每人各做一次有 AI 和没 AI 的任务。AI 组任务完成度中位数是对照组的两倍多——这个数字很漂亮。但被问到自己刚写的代码时，正确率中位数从 100% 掉到 87.5%（论文）。
写得多一倍，讲不清的比例多了一成。
论文里那个关于"代码所有权"的定义我很喜欢：不是你能不能读这段代码，是你能不能替自己的实现选择辩护。
越依赖，越验不动
把两个实验叠起来看，会出现一个闭环，而且它自己会转。
AI 生成的代码有个特点：语法永远漂亮，命名永远规范，注释永远齐全。它错的时候不会显得可疑，错在语义里——少判了一个边界、多吞了一个异常、把并发问题挪到了别处。这类错误靠通读是抓不住的，只能靠你在脑子里跑一遍。
可你在脑子里跑一遍的能力，恰好是上面说的、正在退化那个。
于是闭环成立：用得越多，验的能力越弱；验的能力越弱，漏过去的错越多；漏过去的错越多，你越不敢不用它。
我把这个叫验证悖论，虽然它算不上什么新发现——Bainbridge 那篇文章里已经有雏形了。真正新鲜的是，2026 年我们终于有了数字，而且这些数字是造工具的那家公司自己测出来的。
六种用法，三种毁、三种保
分数之外，论文还做了另一件事：把参与者的屏幕录像一段段看完，归纳出 6 种使用模式。按测验分数分成两堆，整齐得有点意外。
哪几种在毁，哪几种能保住？先看坏消息。
低分那堆（平均不到 40 分）有三种：
- AI 全托：几乎全程让 AI 写，速度最快，遇到的错误最少。
- 渐进外包：开头自己问一两个问题，最后所有编码都交给 AI。
- 边问边调：遇到问题就交给 AI 修，提问次数很多。
高分那堆（平均 65 分以上）也有三种：
- 先生成后追问：让 AI 生成，但生成完会追问"为什么这么写"，用它检验自己的理解。
- 混合式：一次提问里既要素代码也要解释，读完解释再动手。
- 只问概念：不要求 AI 写代码，只问概念，然后自己下手。这组遇到最多错误，但全都自己解决了，还是高分堆里最快的。
最扎心的是"边问边调"。它看起来最努力——不停地提问、不停地让 AI 解释报错、一步步跟着修。结果它不光分数低，完成速度还比全托组慢。
为什么？因为它把"遇到错误"这个动作，也外包了。
你收到了报错，但你没读它。你看到了堆栈，但你没猜过原因。你每问一次，就把一次本该自己爬出来的机会让掉了。提问次数多，不代表思考次数多。
而高分那三种有个共同点：**它们都不让 AI 把推理过程一起吞掉。**要解释、只问概念、生成后追问——形式不同，本质是同一个动作：把"为什么"留在自己这边。
换个场景，还是一样的
调 SQL 的时候最明显。慢查询丢给 AI 改写，它给你加个索引、改个 join 顺序，从 8 秒降到 0.3 秒。但你不知道它为什么快——是走了覆盖索引，还是把过滤条件下推了。下次遇到另一条慢查询，你还是只能丢给它。
线上排查也一样。你把日志丢过去，它圈出三行可疑。你照着改，问题消失了。可那三行为什么可疑，你没建立过判断。
架构评审更隐蔽。它会给你一份看起来很专业的取舍分析，条理清楚，术语准确。而你失去的是"自己掂量哪条路更贵"的那点手感。
这些场景有个共同点：结果可验证，过程不可见。结果对了，你就不会追问过程；而不追问，过程就永远不属于你。
但别急着把 AI 关掉
看到这儿，最顺的反应是干脆别用了。
先别。
这个实验的样本是 52 人，多数是初级工程师，任务是 1 小时内学会一个陌生的库，考的是即时理解。它不能推出"所有人在所有场景下都会退化"——论文自己在局限里写得很清楚。
有一处局限反而更值得担心。作者说，他们测的是聊天式界面的影响，而这应该是下限：Agent 式的工具需要人参与的环节更少，对学习的抑制可能更强。
这么看，我们现在测到的还是最轻的那一档。
代价也要说清楚。那三种高分用法都比全托慢——只问概念那组撞的错误最多，边撞边解决，时间成本实打实。你如果正在赶一个明天要上线的需求，这些做法一个都用不上。
还有一个成本是隐性的：你得先知道自己哪块在退。而这件事恰恰很难，因为退化是渐进的，而且你对它的感知会跟着一起钝掉。
马上行动
有没有不用改工作流的做法？有，改一个顺序就行。
下次遇到报错，先自己看五分钟。不许粘贴，不许问 AI。五分钟里只做一件事：猜原因，然后找一个证据支持或推翻这个猜测。
五分钟到了还没头绪，再去问 AI。这时候你问的问题会不一样——不是"这怎么修"，而是"我猜是这里的事务没提交，对吗"。
前者换来一段能跑的代码，后者换来一次判断的校准。区别就在这里。
回头看这一路，能带走的就几条。退化的第一块是调试，不是打字。差别不在动手多少，在遇到几个错误——对照组中位数 3 个，AI 组 1 个，抄一遍没用。最像努力的"边问边调"反而最差，因为它把"遇到错误"也外包了。能保住学习的只有那三种：只问概念、要代码也要解释、生成后追问为什么。
这个实验也有它的分量边界：52 人、一小时、聊天界面。它测的是下限，不是判词。
所以分界线其实很短：你可以把执行交给它，别把困惑也交给它。
困惑是你的，错误也是你的。这两样东西一旦交出去，剩下的就是熟练地按下接受键——那种熟练，不叫能力。
参考资料
- Judy Hanwen Shen, Alex Tamkin, How AI Impacts Skill Formation, arXiv:2601.20245, 2026-01
- Martin-Lopez et al., More Code, Less Understanding? On the Impact of AI Assistants on Developers’ Productivity and Code Ownership, IEEE TSE, 2026
- Lisanne Bainbridge,Ironies of Automation, Automatica, 19(6), 1983
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（开发者自评与实测的落差）
作者：唐悦玮 | 从后端出发，用 AI 拓展到全栈的工程师。
