前几天，我删除了自己最近跑通的 4 个项目。

从产品交付的角度看，这是个疯狂的举动。它们不是半成品，而是完全达到了 MVP（最小可行性产品）的标准，功能随时可以上线。

在这个被称为“Vibe Coding（氛围编程）”的时代，我只写了一个极其简单的 PRD（产品需求文档），剩下的全交给了 AI。它帮我优化文档、生成架构设计，最后一口气完成了所有编码。我的代码参与度接近于 0。

但我依然选择把它们推翻重来。

因为当系统跑通后，我翻开代码库，面对的却是一阵令人窒息的陌生感。我完全不知道 AI 为什么要写出这样的逻辑，这些代码在不同项目中毫无通用性可言。更可怕的是，我意识到如果系统在六个月后出现核心级 Bug，未来的我将完全不知道今天的我在干什么。

这是一种比技术债更致命的东西。

欠下隐形的“认知债”

软件工程界曾有一个共识：程序不仅是运行在机器上的指令，更是开发者大脑中构建的“理论模型”。

AI 的介入正在悄然摧毁这个模型。

下面是国外一位老哥的经历：

上个月，我目睹团队中一位开发者调试了四十五分钟。

不是因为这个bug有多复杂——它是一个经典的异步状态竞争条件，每个资深开发者都曾因此踩过坑，从此再也不会忘记。他花了四十分钟把错误信息粘贴进Claude，反复尝试各种建议，却完全不理解其中任何一个。直到我坐到他身边，他才花了最后五分钟真正去读堆栈跟踪信息。

一旦他读懂了，不到两分钟就修复了问题。

令人不安的部分来了：他不是一个糟糕的开发者。他聪明、有动力。但他被工具、文化、现代软件开发的激励机制训练成了：在寻求理解之前，先求助AI。

这种习惯正在使他变差。最糟糕的是，他的产出看起来毫无问题：功能如期上线，测试全部通过。在每次站会所追踪的每一项指标上，他都显得高效。

但这些指标之下，正在发生某些事情。这些事要六个月后才会显现——当问题真正棘手，而AI再也无法提供清晰答案时。那时，那些通过挣扎学习的人与那些用自动化绕过挣扎的人之间的差距，就再也无法忽视了。而到那时，弥补这个差距已极其困难。

与我遇到的问题何其相似？

产出指标上的繁荣掩盖了底层的空心化。根据 2026 年 Margaret-Anne Storey 提出的“三重债务模型”，我们正在从积累“技术债”转向积累“认知债”（Cognitive Debt）。技术债留在代码里，而认知债留在开发者的脑子里。当项目的高级抽象完全由 AI 代劳时，你得到了输出，却没有获得理解。你拿到一个能跑的代码库，但没有任何新的神经通路形成。

MIT 媒体实验室在 2025 年针对 AI 辅助的一项神经学实验给出了冰冷的证据：完全依赖 AI 生成内容的人，其大脑的神经连通性最弱，对产出物的“归属感”降至最低，甚至无法准确复述自己项目的核心逻辑。

这就是能力的幻觉。当你看着 AI 生成的完美方案时，你以为自己掌握了它。但实际上，你只是一个被架空的旁观者。

复制粘贴的繁荣与架构的坍塌

在 Vibe Coding 的爽感之下，整个行业的代码库正在发生质变。

GitClear 在一份涵盖 2.11 亿行代码的《2025 AI 助手代码质量报告》中揭示了一个反直觉的真相：AI 并没有让我们的代码变得更优雅。相反，2024 年史上第一次，开发者提交的“复制粘贴代码”占比飙升至 18%，而代表深度思考的“重构代码”比例暴跌至不到 10%。

这完美解释了我为什么会看不懂自己项目的代码，以及为什么 AI 写的逻辑在不同项目中毫无通用性。

在没有约束的情况下，AI 永远倾向于“让它现在能跑”的最短路径，而不是“让它未来能演进”的系统架构。它会用硬编码绕过复杂的解耦，用冗余的重复逻辑替代精妙的抽象。当你跳过查文档、建构心理模型、试错、修正的循环，直接粘贴报错并拿到可运行方案时，大脑不需要更新任何模型。

没有修正，就没有刻印。你交付了代码，却失去了对系统的控制权。

重建护城河：给硅基同事立规矩

为了夺回控制权，在删除那几个 MVP 后，我做了一件事：为 AI Agent 重新设定严苛的工作流和规范。

我不再允许它进行无边界的 Vibe Coding。相反，我为它套上了文档规范、架构规范、代码规范和测试规范的枷锁。我强迫它在写下第一行代码前，必须先输出带有上下文的系统架构（IA before AI）；我要求它的每一次模块实现，都必须符合我已经确认过的前置契约。

这就好比把 AI 从一个不受控制的“神谕”，降维成一个必须遵守公司 SOP 的“对练伙伴”。神谕直接给你答案，让你产生依赖；对练伙伴则在边界内执行，让你保持对全局的掌控。

要在这个自动化时代保持清醒，我们需要在日常交互中引入阻力：

规则一：反向橡皮鸭调试。 拿到方案后，先向 AI 解释你的理解：“这是我对架构的构思，我遗漏了什么？”迫使自己在接收代码前主动提取逻辑。你说的话和实际代码之间的差距，才是真正发生认知同频的地方。

规则二：警惕“不费吹灰之力”。 任务结束时度量自己的挣扎感。如果整个开发过程让你觉得毫无摩擦、极度轻松，这意味着 AI 替你吃掉了所有难消化的部分，你正在走向认知破产。

规则三：三十秒的前置语音。 iSentry 团队有一个极好的工程实践：在把问题抛给 AI 之前，开发者必须先录制一段 30 秒的语音笔记，描述自己对 Bug 的猜测和解决方案。不到一分钟的停顿，强制你在外包思考之前建立心理模型。

挣扎的时机决定一切

我并非在抵制 AI。恰恰相反，AI 是有史以来最强大的开发工具。

真正的分水岭在于：你是在挣扎之前引入 AI，还是在挣扎之后引入它？

如果你一看到需求就立刻让 AI 铺设代码，你是在用自动化绕过认知摩擦。但如果你先与系统设计搏斗，形成了清晰的架构边界，卡在具体的实现细节上时再向 AI 提问 —— “我规定了这样的测试规范，目前的实现哪里有漏洞？” —— 这时，挣扎固化了上下文，AI 会精准敲掉障碍，学习和开发效率将呈指数级加速。

语法和 API 的记忆正在急速贬值，但知道如何用规范去驾驭工具（Harness Engineering）、逼迫自己深入思考架构的能力，正在成为最高昂的溢价。

不要让你的代码库成为你大脑的黑盒。三年后，靠挣扎建立起系统思维的人，和用自动化消除所有开发摩擦的人，将会走向完全不同的两个世界。

欢迎关注我的公众号，第一时间获取最新文章。