AI 编程助手催生「认知债务」：中间层工程师正在消失

AI 编程助手正在悄然改写软件工程的人才结构。独立开发者 Florian Herrengt 近日撰文指出，随着 Claude 等大模型被广泛用于修 bug、解释代码甚至编写功能，团队中能够独立理解系统全貌的「中间层」工程师正在快速消失，取而代之的是一种难以偿还的「认知债务」。

现象：AI 越用越不会

Herrengt 描述了一个典型场景：线上出现一个怪异 bug，团队已经是第 4 次尝试修复——而且每次都是让 AI 去修。即便是擅长 AI 编程的 Fable 团队，也无法定位问题。开发人员转头去问负责该功能的同事「数据到底从哪里来」，得到的回答却是：「我也不太确定，让 Claude 看看。」

两人并排坐在屏幕前，看着 Claude 输出的一屏又一屏文字。没有人知道这些内容是否属实，但模型看起来十分自信。等到追问「这个值是怎么算出来的」时，又得到一句「让 Claude 解释一下」。Herrengt 直言，这个项目已经堆叠了太多层服务与抽象，以至于团队里没有任何人能够独立说清楚系统究竟在做什么。

根源：每一层都「问 AI」

Herrengt 将这种现象称为「认知债务」(cognitive debt)。他以一栋公寓楼作类比：传统软件工程里，初级工程师负责修修补补，中级工程师理解模块设计，高级工程师把握整体架构。如今 AI 工具接管了大量初级与中级工作，原本承担「把控全局、解释他人代码」职责的中间层，反而成了最容易被替代的角色。

更深层的问题在于，AI 给出的解释往往流畅、自洽，却未必对应真实的数据流与业务逻辑。当团队成员用 AI 去回答 AI 制造的疑问，理解的链条就被一层层外包出去，最终没有任何人对系统拥有第一手的认知。

启示：别把理解也外包出去

Herrengt 的观点并非否定 AI 编程的价值，而是强调一个被忽视的成本：每一次「让 Claude 帮我看看」，都可能是一笔新的认知债务。其偿还方式，是在引入 AI 辅助之前，确保团队中仍有人真正读懂代码、理解数据流向；引入之后，也要有人定期复核 AI 的解释与改动。

随着 Cursor、Copilot、Claude Code 等工具深度嵌入开发流程，这篇文章的警示对所有正在「AI 化」的工程团队都值得参考：决定系统长期健康度的，往往不是当下谁写得最快，而是谁还真正理解自己在写什么。