# AI 帮你写代码，也在悄悄把你变菜

> 过度依赖 AI 编码，工程师的调试能力平均下降 47%——这是造 Claude Code 的公司自己承认的。编码 Agent 带来的「认知债务」不会当场报错，却在悄悄拿走你判断代码好坏的能力。这篇聊聊它为什么危险，以及我自己在用的 5 条对冲纪律。

- 原文链接: https://laojin.blog/blog/20260720_agentic_coding_cognitive_debt
- 作者: 老金
- 发布日期: 2026-07-20
- 标签: AI 编程, Claude Code, 认知债务, Agentic Coding, 判断力

---

![AI 帮你写代码，也在悄悄把你变菜](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260720/00_cover.png)

先说一个让我背后发凉的数据。

Anthropic 自己的研究里有一句话：过度依赖 AI 编码，工程师的调试能力平均下降 47%。这不是某个培训机构在贩卖焦虑，是造 Claude Code 的公司自己承认的。

更狠的是同一份研究里那句坦白：

> "有效使用 Claude 需要监督，而监督 Claude 所需要的，正是那些可能因过度使用 AI 而萎缩的编码技能。"

翻译为人话：**AI 帮你干的活，恰好正在拿走你验收这些活的能力。** 你用得越爽，越没法判断它是不是在坑你。

这就是我今天想聊的——编码 Agent 的"认知债务"。它不像 bug 那样当场报错。它是慢性的，等你发现，护城河已经没了。

---

## 为什么"这次真的不一样"

每次聊到"AI 会不会让程序员变菜"，总有人抬杠：抽象层升级不是一直在发生吗？

- C++ 转 Java，没人担心大脑退化；
- 系统管理员迁到 AWS，也没谁因此看不懂网络了。

以前每一层抽象的提升，都没让人变笨。所以"AI 让你变菜"听起来像又一次狼来了。

区别在一个词：实证。

过去那些"抽象会不会让人退化"的担忧全是推测，从没有数据。而 AI 工具对认知的影响已经有实证研究了——它被证实会负面影响批判性思维和认知清晰度。前几次是"担心会退化"，这次是"已经测出来退化了"。

LinkedIn 一位管着 50 个工程师的总监说得更直接：

> "要成长，人得经历艰难，得练出思考问题的那块肌肉。没有批判性思维，你怎么去质疑 AI 给的答案对不对？"

认知债务真正可怕的地方就在这里：它不让你写不出代码，它让你丧失判断代码对不对的能力。而在 AI 时代，判断力恰恰是你唯一还值钱的东西。

![AI 依赖上升，人的技能下滑](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260720/01_skill_atrophy.png)

---

## LLM 加速的，偏偏是错的那一环

我们复盘一下，一个好开发者做事的优先级本来是什么样：

1. 理解代码，以及它和整个代码库的关系；
2. 代码是否高效、达标；
3. 在可读的前提下，代码尽量少；
4. 最后才是——交付速度。

Agentic Coding 把这个列表整个倒过来了，速度顶到第一位。

![好开发者的优先级被整个倒过来](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260720/02_inverted_priority.png)

可速度从来是高能力的副产品，不是原因。真正理解系统的人写得快，只是因为他早想清楚了。你反过来，把速度提到最前面，第一个被牺牲掉的就是准确性。

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. 立一条铁律：从不生成超过"一次能审查完"的代码量。**

这是防认知债务最硬的一道闸。代码一次性吐得越多，你越不可能真读，越只能盖橡皮图章。宁可分五次让它写、每次都读透，也别一次让它写完你三天都读不完的东西。

![人在闸口把关：读得完才放行，太大就挡回去](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260720/03_discipline_gate.png)

**3. 发布前，真的把代码读一遍——不是扫，是读。**

配一个动作：对每个关键决定问一句硬核的"为什么用这个方案，不用那个？"。答不上来，就说明这段代码你并不拥有，出了事你也修不了。把"读不懂就不合入"设成不可谈判的规矩。

**4. 调试这件事，自己扛。**

出 bug 别第一反应甩给 AI 修。先自己形成假设、自己验证，再决定要不要让它帮忙。开头那下降的 47% 调试能力，就是在这个动作里一点点练回来的。这是你为数不多能主动对冲认知债务的场景，别浪费。

**5. 用 James Shore 的维护成本数学，给自己算笔账。**

他的算法很冷酷：你写代码快了 2 倍，就必须确保维护成本也减半；快 3 倍，维护成本得压到三分之一。否则——产出 ×2、维护 ×2，总维护成本其实是 ×4，那是灾难。所以选型时别只看"生成得多快"，要看"它有没有同时让代码更好维护"。只提速不降维护成本的用法，是在透支未来。

---

## 最后

AI 把"写代码"这件事变成了廉价商品。既然生成不再稀缺，那稀缺的是什么？

是理解力，能看懂它做了什么、为什么能跑、会在哪炸。是判断力，知道哪些能信、哪些必须自己验。这两样 AI 恰恰给不了你，还在悄悄把它们从你身上抽走。

所以真正的分水岭，不在你会不会用 AI 写代码——这谁都会。而在你用 AI 写了半年之后，摘掉 AI，你还剩下什么。

别让那个"剩下的你"，一年比一年菜。