本文是「学习方法与效率」系列第 9 篇，长期用 AI 写代码后，调试、阅读、搭建、API 记忆和方案设计会怎样退化，以及如何恢复。可按目录跳读。
来源：掘金文章｜作者：kyriewen｜发布日期：2026-07-31 整理：2026-11-02｜类型：文章摘要
一句话结论
AI 是外骨骼，不是替代器官。效率提升是真的，但如果把调试、阅读、搭建、API 记忆和方案设计全部外包，独立编程的「肌肉」会萎缩。
作者的经历
从年初开始，作者几乎每天用 Claude Code 或 Cursor 写代码。 以前要写半天的 CRUD 页面，现在二十分钟就能搞定。 真正让他警觉的是一件小事：同事问 Promise.allSettled 和 Promise.all 的区别，他张了张嘴，发现自己需要「想一下」才能回答。 这个问题两年前他能脱口而出。 他的判断是：不是自己变笨了，而是把这块肌肉交给 AI 练了半年，它萎缩了。
文中引用的三个信号
- Anthropic 的一项研究：重度依赖 AI 编程工具的开发者，独立调试和代码阅读能力比手动编码组低 17 个百分点。
- 美国心理学会今年的报告：过度依赖生成式 AI 会降低批判性思维和岗位专项技能。
- The Register 上出现的新词「AI Atrophy」：AI 导致的技能萎缩。
以上三项均为文章转述，原文没有给出来源链接，引用时应保留「文中引用」的限定，不宜直接当作定论。
五个退化
1. Debug：第一反应从读错误变成问 AI
以前的流程是：看报错信息、定位文件、打断点、看调用栈、找到原因。 现在遇到红色波浪线，第一反应是把报错复制给 AI。 问题不在于 AI 给的答案对不对，大部分时候是对的。 问题在于跳过了「理解为什么出错」这一步。 连续半年跳过，对类型系统的心智模型就会变模糊。 以前能凭直觉判断「这里可能有空值」，现在要等 TypeScript 报错才知道。
自测方法：下次遇到 TypeScript 报错，先不问 AI，自己读完报错信息。 如果发现自己读不懂了，那就是退化的信号。
2. 代码阅读：看别人的代码变吃力
以前 review 同事的 PR，会逐行看逻辑、想边界情况、考虑性能。 现在打开一个 200 行的组件，第一反应是让 AI 帮忙总结。 这不是看不懂语法，而是看代码时主动思考的密度降低了。 文章举了一个 useDebounce 的例子：delay 变化时会重置 timer，可能导致回调永远不触发。 以前一眼能看出这个问题，现在需要「想一下」才能想到。 习惯让 AI 总结代码、解释逻辑，自己的阅读肌肉就在萎缩。 就像天天打车的人，突然发现自己不记得路了。
自测方法：找一个没参与过的开源项目，随便打开一个核心模块看 15 分钟。 如果频繁想「好复杂，让 AI 解释一下」，那就是退化的信号。
3. 从零搭建：离了模板不会开始
不用 create-next-app、不用 AI，从一个空文件夹开始搭一个 React 项目，还能搞定吗。 webpack.config.js 里的 entry、output、module rules、devServer 是否还记得。 作者发现自己不记得了，以前闭着眼都能写，现在需要查文档。 脚手架工具存在就是为了省时间，不必每次手搭。 但知道底层怎么运作和不知道是两码事。 当脚手架出现奇怪的构建错误时，懂原理的人能定位问题，不懂的人只能问 AI 碰运气。
自测方法：不用任何脚手架，手搭一个最小的 React 开发环境。 如果连 webpack.config.js 的基本结构都要查，那就是退化的信号。
4. API 记忆：常用方法都要问 AI
文章列了几个前端常用 API：
- 数组去重：
[...new Set(arr)]或Array.from(new Set(arr)) - 深拷贝：
structuredClone(obj)，还是JSON.parse(JSON.stringify()) - 日期格式化：
Intl.DateTimeFormat - URL 参数解析：
URLSearchParams - 数组分组（ES2024）：
Object.groupBy
这不是记忆力的问题，而是不再需要记这些了，问 AI 比翻 MDN 快十倍。 代价是对 JavaScript 标准库的掌握，从「信手拈来」变成「知道有这么个东西但要查」。 写代码的流畅感没了：以前像说话一样自然，现在像在翻译，知道要做什么，但需要 AI 帮忙翻成具体的 API 调用。
自测方法：打开一个空文件，不查任何东西，写一个函数，接受 URL 字符串并返回所有查询参数组成的对象。 如果卡在 URLSearchParams 的用法上，那就是退化的信号。
5. 方案设计：不再自己想架构
这个变化最隐蔽，也最危险。 以前遇到新需求，会先在脑子里过一遍：数据流是什么样，状态放哪，组件怎么拆，用 Context 还是状态管理库。 现在直接把需求告诉 AI，让它出方案。 文章举例，做一个支持筛选、排序、分页的数据表格，以前的思考过程是：筛选和排序状态放 URL params，数据用 React Query 管理，分页用 cursor 而不是 offset，表格组件和数据逻辑分离。 现在的过程是：告诉 AI 需求，AI 输出 500 行代码，看了看能跑，就用了。 AI 出的方案不一定差，但跳过了「思考为什么这样做」的过程。 下次遇到类似需求，还是不知道应该用 cursor 分页还是 offset 分页，还是需要问 AI。 技术方案设计能力需要在真实场景中不断判断、犯错、修正，才能建立直觉。 把这个过程交给 AI，技术直觉就停止生长了。
自测方法：试着在纸上、不看任何东西，画出当前项目的前端架构图，包括数据流、状态管理、API 调用层和组件层级。 如果画不出来，不是因为架构复杂，而是没有真正思考过它。
能力退化自测清单
| 能力 | 退化信号 | 自测方法 |
|---|---|---|
| Debug | 遇到报错先问 AI，不看信息 | 下次报错先自己读完再说 |
| 代码阅读 | 看 PR 想「让 AI 总结一下」 | 看一个开源项目核心模块 15 分钟 |
| 从零搭建 | 离了脚手架不知道怎么开始 | 手搭一个最小 React 开发环境 |
| API 记忆 | 常用方法要先问 AI | 不查东西写一个 URL 参数解析函数 |
| 方案设计 | 需求来了直接丢给 AI | 纸上画出当前项目的架构图 |
核心比喻
文章的核心比喻是：AI 是外骨骼，不是替代器官。 穿上外骨骼能举起 200 公斤，但自己的肌肉至少要能举起 40 公斤。 否则有一天外骨骼出故障，断网、API 挂了，或者需要在一个不能用 AI 的环境里写代码，人就会失去独立工作的能力。 文章还提到，上个月海外 AI 编程工具大规模封禁国内账号，那些完全依赖 AI 的开发者突然发现自己「不会写代码了」。
可执行建议
作者给出的最小行动是：每周花 2 小时不开 AI 写代码。 不需要每天，但要保持频率，就像健身不必每天去，但不能长期中断。 在这个基础上，可以再补充几条：
- 遇到报错先自己读一遍，再决定是否问 AI。
- 定期做一次无 AI 自测：读代码、手搭环境、写常用 API、画架构图。
- 把 AI 用在确认和加速上，不要用在替代理解上。
- 关键模块和核心链路保留手写习惯，边缘代码可以放心交给 AI。
边界
文章是作者半年使用体验的复盘，不是严格的对照实验。 17 个百分点等研究结论由文章转述，原文没有给出来源链接，不能当作定论。 作者也明确说不是要戒掉 AI，而是保留基本的手写与独立思考能力。 对已经高度依赖 AI 的团队，更现实的做法是设置无 AI 时段、关键模块手写，而不是全面禁用工具。