AI 编程后，越来越不会码了

摘要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 个百分点接近两个等级效应量 d0.738p0.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-01Martin-Lopez et al., More Code, Less Understanding? On the Impact of AI Assistants on Developers’ Productivity and Code Ownership, IEEE TSE, 2026Lisanne Bainbridge,Ironies of Automation, Automatica, 19(6), 1983METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity开发者自评与实测的落差作者唐悦玮 | 从后端出发用 AI 拓展到全栈的工程师。