AI 帮你写代码，也在悄悄把你变菜
过度依赖 AI 编码，工程师的调试能力平均下降 47%——这是造 Claude Code 的公司自己承认的。编码 Agent 带来的「认知债务」不会当场报错，却在悄悄拿走你判断代码好坏的能力。这篇聊聊它为什么危险，以及我自己在用的 5 条对冲纪律。
先说一个让我背后发凉的数据。
Anthropic 自己的研究里有一句话：过度依赖 AI 编码，工程师的调试能力平均下降 47%。这不是某个培训机构在贩卖焦虑，是造 Claude Code 的公司自己承认的。
更狠的是同一份研究里那句坦白：
"有效使用 Claude 需要监督，而监督 Claude 所需要的，正是那些可能因过度使用 AI 而萎缩的编码技能。"
翻译为人话：AI 帮你干的活，恰好正在拿走你验收这些活的能力。 你用得越爽，越没法判断它是不是在坑你。
这就是我今天想聊的——编码 Agent 的"认知债务"。它不像 bug 那样当场报错。它是慢性的，等你发现，护城河已经没了。
为什么"这次真的不一样"
每次聊到"AI 会不会让程序员变菜"，总有人抬杠：抽象层升级不是一直在发生吗？
- C++ 转 Java，没人担心大脑退化；
- 系统管理员迁到 AWS，也没谁因此看不懂网络了。
以前每一层抽象的提升，都没让人变笨。所以"AI 让你变菜"听起来像又一次狼来了。
区别在一个词：实证。
过去那些"抽象会不会让人退化"的担忧全是推测，从没有数据。而 AI 工具对认知的影响已经有实证研究了——它被证实会负面影响批判性思维和认知清晰度。前几次是"担心会退化"，这次是"已经测出来退化了"。
LinkedIn 一位管着 50 个工程师的总监说得更直接：
"要成长，人得经历艰难，得练出思考问题的那块肌肉。没有批判性思维，你怎么去质疑 AI 给的答案对不对？"
认知债务真正可怕的地方就在这里：它不让你写不出代码，它让你丧失判断代码对不对的能力。而在 AI 时代，判断力恰恰是你唯一还值钱的东西。
LLM 加速的，偏偏是错的那一环
我们复盘一下，一个好开发者做事的优先级本来是什么样：
- 理解代码，以及它和整个代码库的关系；
- 代码是否高效、达标；
- 在可读的前提下，代码尽量少；
- 最后才是——交付速度。
Agentic Coding 把这个列表整个倒过来了，速度顶到第一位。
可速度从来是高能力的副产品，不是原因。真正理解系统的人写得快，只是因为他早想清楚了。你反过来，把速度提到最前面，第一个被牺牲掉的就是准确性。
OpenCode 的创始人 Dax 一句话点破了本质：
"处理有挑战的新东西时，我敲代码的过程，本身就是我想清楚到底该做什么的过程。"
写代码即是思考。你把写代码这一步外包给 AI，等于把思考这一步也一起外包了。LLM 会用一堆假设去填补你没想清楚的模糊地带，于是你得回头审查、让它改、再消耗 token、再脱节——你没省掉思考，只是把它推迟到了更贵的时候。
顶级项目已经开始筑墙
如果你觉得这还只是观点之争，看看真金白银的选择。
SQLite —— 全世界装机量最大的数据库之一，2026 年 5 月在代码库里加了个 AGENTS.md，白纸黑字写着：
"SQLite 不接受智能体代码（agentic code）。但接受带可复现测试用例的智能体 bug 报告。"
最耐人寻味的是后来一次提交，把原文"目前（currently）不接受"里的"目前"两个字删掉了，提交说明叫"加强不接受智能体代码的声明"。从"暂时不要"变成了"永久不要"。
另一头，SQLite 论坛被 AI 生成的、质量参差不齐的 bug 报告淹没，被迫单开了一个 Bug 论坛来处理。
这群人是全世界最懂代码质量的一批。他们用行动告诉你：AI 生成代码的质量问题，已经严重到要主动筑墙的地步。
还有个更隐蔽的坑：注意力
认知债务不止发生在"深度"上，也发生在"广度"上。
独立开发者 David Wilson 一口气用 AI 启动了 16 个以上的项目，然后得出结论：
"这玩意儿对注意力简直是灾难。它是一个热核级的 ADHD 放大器。"
编码 Agent 能在一小时内，把一个模糊想法变成"带测试、带文档、看起来很完整"的项目。爽不爽？巨爽。但 Simon Willison 补了一刀：
"就算代码很稳健，我能合理维护的项目数量也是有限的——如果它们造出来就被立刻抛弃，那创造它们的意义又在哪？"
看起来是精雕细琢的成品，其实是转身就丢的碎片。你以为你在高产，实际上你在批量制造迟早被自己遗忘的垃圾。造得起，不等于养得起。
那到底该怎么用？
说了这么多，不是让你把 AI 关掉——那既不可能也没必要。认知债务的反面不叫"不用 AI"，叫"用得有纪律"。给几条我自己在 AssistantBrain 和 TinyPA 上正在执行、能直接抄的做法。
1. 主动给 AI 降级：从"主导"改成"委托"。
别让它当主角。让它帮你生成规格和计划，实现这一步你自己来（手写 20%–100%，看难度）。多写伪代码跟它聊，把"你想要的"和"它生成的"之间那段距离压到最短。记住这个梗：把 AI 当飞船电脑，别当 Data——你查询它、指挥它，但拍板的永远是你。
2. 立一条铁律：从不生成超过"一次能审查完"的代码量。
这是防认知债务最硬的一道闸。代码一次性吐得越多，你越不可能真读，越只能盖橡皮图章。宁可分五次让它写、每次都读透，也别一次让它写完你三天都读不完的东西。
3. 发布前，真的把代码读一遍——不是扫，是读。
配一个动作：对每个关键决定问一句硬核的"为什么用这个方案，不用那个？"。答不上来，就说明这段代码你并不拥有，出了事你也修不了。把"读不懂就不合入"设成不可谈判的规矩。
4. 调试这件事，自己扛。
出 bug 别第一反应甩给 AI 修。先自己形成假设、自己验证，再决定要不要让它帮忙。开头那下降的 47% 调试能力，就是在这个动作里一点点练回来的。这是你为数不多能主动对冲认知债务的场景，别浪费。
5. 用 James Shore 的维护成本数学，给自己算笔账。
他的算法很冷酷：你写代码快了 2 倍，就必须确保维护成本也减半；快 3 倍，维护成本得压到三分之一。否则——产出 ×2、维护 ×2，总维护成本其实是 ×4，那是灾难。所以选型时别只看"生成得多快"，要看"它有没有同时让代码更好维护"。只提速不降维护成本的用法，是在透支未来。
最后
AI 把"写代码"这件事变成了廉价商品。既然生成不再稀缺，那稀缺的是什么？
是理解力，能看懂它做了什么、为什么能跑、会在哪炸。是判断力，知道哪些能信、哪些必须自己验。这两样 AI 恰恰给不了你，还在悄悄把它们从你身上抽走。
所以真正的分水岭，不在你会不会用 AI 写代码——这谁都会。而在你用 AI 写了半年之后，摘掉 AI，你还剩下什么。
别让那个"剩下的你"，一年比一年菜。