AI 写代码越来越快，我们的代码能力却在悄悄退化

先说一个反直觉的结论：用 AI 写代码，正在让一部分人变得更弱 ------ 而当事人几乎察觉不到。

这不是贩卖焦虑。2026 年初，Anthropic 研究者 Shen 与 Tamkin 发布了一项随机对照实验（arXiv:2601.20245）¹：52 名至少有一年 Python 经验的开发者（多为初级工程师）学习一个此前都没用过的异步库 Trio，随后接受一场不允许用 AI 的测验。

表格

指标	AI 组	手写组
测验平均分	50%	67%
任务完成速度	快约 2 分钟	---

差距最大项：调试类题目，约 17 个百分点的差距，接近两个等级。而 "快 2 分钟" 在统计上并不显著 ------ 效率收益没有兑现，理解力却实打实地掉了。论文的结论：AI 带来的生产力，不是通往能力的捷径。

另一项研究更耐人寻味。METR 在 2025 年让 16 名资深开源开发者在最熟悉的库上完成 246 个真实任务 ²：开始前他们预测 AI 能省 24% 时间，做完后自评快了约 20%，但实测反而慢了 19%，自评与实测差了近 39 个百分点。

两个研究指向同一件事：退化是真实的，而我们对退化的感知是失灵的。 下面五个维度，是最典型的战场。

以前遇到报错，第一反应是看堆栈、打断点、二分定位，一步步逼近根因。现在很多人的第一反应是 ------ 把报错整段贴给 AI，等一个修复方案。

但这跳过了最关键的一步：理解为什么错。 Anthropic 的研究里，调试恰是两组差距最大的题型 ³------AI 组任务中遇到的报错更少（中位数 1 次 vs 3 次），可一旦报错出现，他们往往修不动。原因很直白：你没亲手调试过的东西，也调试不了。

调试能力不是记住某个报错的解法，而是 "形成预期模型 → 提出假设 → 收集证据 → 排除 → 验证" 这套思维肌肉⁴。跳过它，对类型系统、调用链、时序问题的敏感度会明显钝化。

Review 同事 PR 时，以前会逐行看逻辑、想边界、脑内推演数据流，现在越来越多人依赖 AI 一句话总结 "这段在做什么"。

问题是，AI 生成的代码看起来比人写的更规范 ------ 命名整齐、注释齐全 ------ 但它可以编译通过、测试全绿，同时悄悄违背你的真实需求。而识别这种偏差，恰恰依赖你自己的独立理解力。研究者把这种现象称为 "验证债" ：生成速度远超审查能力，代码越堆越多，能看懂它的人却越来越少。

create-next-app 一条命令，AI 再生成一版，项目就跑起来了。爽，直到有一天让你从空文件夹手搭一个 React 项目，可能连 webpack.config.js 的基本结构都得现查。

这不是记忆力问题，而是对 "从 0 到 1 到底发生了什么" 失去了掌控感 ------ 脚手架把 "为什么这么配" 的决策全隐藏了。平时无感，一旦需要定制构建流程，就会发现自己站在一个并不理解的系统面前。

structuredClone、URLSearchParams、Object.groupBy...... 以前是条件反射式的存在，现在变成 "知道有这东西，得问问 AI 怎么用"。

单看这条最不致命，毕竟没人要背 API 手册。真正的代价是流畅感的流失：当你不断在 "想做什么" 和 "知道怎么写" 之间插入一次查询，写代码就从 "表达" 退化成了 "翻译"。

以前拿到需求，会本能地先想：数据流怎么走、状态放哪、组件怎么拆、要不要引入某种架构模式。现在很多人直接把需求丢给 AI 要方案。

省事的代价，是跳过了 "思考为什么这么做" 这个动作。技术直觉要靠反复 "决策 --- 反馈 --- 修正" 才能长出来；长期不决策，直觉就停止生长 ------ 你一直在用 AI 的方案，却说不清它为什么好、什么时候会不好。对工程师而言，这几乎是最核心的能力。

好消息是，Anthropic 的研究同时给出了解法。他们识别出 6 种与 AI 交互的模式，其中 3 种侵蚀能力，另外 3 种能在正常使用 AI 的同时保留学习成果⁵：

表格

侵蚀型模式	均分	保留型模式	均分
完全委托 AI 生成	24%	概念型提问（自己写码）	86%
渐进式依赖	35%	生成 + 追问解释	65%
靠 AI 反复修错	39%	先生成、再理解	68%

最高分与最低分相差超过 60 个百分点。分水岭只有一条 ------你是在用 AI 替代思考，还是在用 AI 深化理解。

① 每周固定 "无 AI 编码时间" 不用多，每周 2 小时，关掉所有 AI 工具纯手写。挑个感兴趣的小项目练手 ------ 命令行工具、脚本都行，没有 KPI 压力，最适合练基本功。就像飞行员要定期练手动进近，为的是保持 "能独立判断" 的底气。

② 先自己设计，再让 AI 实现 哪怕一个小模块，也先在注释里把输入输出、边界条件、异常场景写清楚，再让 AI 补实现。先搭逻辑骨架，AI 填的是肉，不是脑。研究里 "概念型提问 + 自己编码" 拿到 86 分，本质就是这套流程。

③ 逐行审查 AI 生成的代码 AI 写的代码必须人工通读一遍，并且要能给别人讲清每一行在干什么。你可以不手写每一行，但必须读得懂每一行。审查时先预测 "这段会做什么" 再运行验证 ------ 预测失准处，就是你的盲区。

④ 让 AI 当 "老师" 而不是 "代练" 别问 "帮我优化这段代码"，而要问 "请用通俗的语言解释一下尾调用优化的原理"。AI 的讲解能力远强于它的写码能力，当私教用，收益远高于当代练用。

⑤ 用测试驱动 AI 写代码前先写测试用例，再让 AI 实现。测试用例本身就是你对业务规则的理解 ------AI 只负责实现，由你来定义 "什么算正确"。这一步也在守护方案设计能力。

别想着戒掉 AI。 它确实能大幅提升效率。关键从来不是 "用不用"，而是 "怎么用"。把它当结对编程的伙伴，而不是黑盒生成器，退化就能有效避免。
警惕 "AI 写的应该没问题"。 这种信任一旦建立，连最基本的审查能力都会被主动放弃。记住：AI 生成的注释是它自己描述的，不一定准确，甚至可能用漂亮的注释掩盖逻辑错误。
退化的速度比想象中快。 不需要三年不写代码 ------ 只要一年高强度依赖 AI，基础能力就会开始滑落。编程是典型的 "用进废退"。

最后回到 METR 那个研究最值得琢磨的一点⁶：开发者以为自己快了 20%，实际慢了 19%。我们对自身能力变化的感知，远没有以为的那么可靠。

所以，别等哪天 AI 不可用（服务中断、模型变更、面试白板）才发现自己不会了。定期给自己做一次 "无 AI 体检"，是当下每个开发者都该有的习惯。