Vibe Coding 的三个月黑箱：为什么我选择 AI Coding + TDD

一个真实的场景

前段时间，一个朋友找我帮忙看他的项目。一个用 Cursor 从零搭起来的 SaaS 后端，三个月前还跑得好好的，现在任何改动都会连锁崩塌。他说：“我已经不敢碰那些代码了，连 AI 都修不好。”

我打开项目一看：没有测试，没有文档，函数名是 handleStuff 和 processData，同一段逻辑在四个文件里出现了三个不同的变体。AI 写的每一行代码都”能跑”，但没有人——包括 AI 本身——还能理解这个系统的全貌。

这就是我说的”三个月黑箱”。

先说清楚：我不反对 vibe coding。Andrej Karpathy 在 2025 年初提出这个概念时，描述的是一种”完全沉浸在氛围中，拥抱指数级增长，忘记代码的存在”的编程方式。对于原型验证、周末项目、一次性脚本，这种方式确实香。

数据也说明了这个趋势的规模：92% 的美国开发者每天都在用 AI 编码工具，46% 的新代码是 AI 生成的。这不是未来，这是现在。

但诱惑背后有代价。

当你用 vibe coding 的方式推进一个项目三个月，几件事会同时发生：

Context window 撞墙。 AI 每次只能看到有限的上下文。项目小的时候，它能”记住”整个系统；项目长大后，它开始遗忘，开始在不同文件里用不同风格解决同一个问题。代码重复率最高能达到 8 倍——不是因为 AI 笨，而是因为它每次对话都是从头开始理解你的系统。

安全漏洞静默积累。 研究显示，45% 的 AI 生成代码包含 OWASP Top-10 漏洞。SQL 注入、XSS、不安全的反序列化——这些不是高深的攻击向量，是基本功。AI 不会主动告诉你”这段代码有安全风险”，除非你问它。

调试成本反超。 63% 的开发者表示他们花了更多时间调试 AI 生成的代码。前期省下的时间，后期用 debug 补回来——甚至更多，因为你在调试一段你没有完全理解的代码。

无人能理解全貌。 这是最致命的。三个月后，代码库的复杂度超过了任何人（包括 AI）的理解能力。你不知道改一个地方会影响什么，不知道哪些代码是活的、哪些是死的。项目进入”只能加不能改”的状态。

我用 AI 写了 MCPHub 的几乎所有代码。这个项目现在有 2000 多个 star，稳定运行，持续迭代。但我从第一天起就没有”vibe”过——我给 AI 立了规矩。

在 MCPHub 里，我维护了一个 AGENTS.md 文件，它定义了 AI 辅助开发时的所有约束：代码风格、命名规范、测试要求、提交规则。每次让 AI 写代码时，这个文件就是它的行为边界。

这不是形式主义。没有 AGENTS.md 的 AI，就像一个不知道公司代码规范的新员工——技术能力可能很强，但写出来的东西和其他人的代码格格不入，越积累问题越大。

测试驱动开发不是新概念，但在 AI Coding 的语境下，它的价值被重新定义了。

在传统开发中，TDD 帮你理清需求、保证正确性。在 AI Coding 中，TDD 还多了一个作用：它是你对 AI 产出的验证机制。AI 写了一个函数，测试告诉你它到底对不对。AI 重构了一段逻辑，测试告诉你有没有破坏已有行为。

我的工作流大致是：

测试不会过期，不会遗忘，不会因为 context window 的限制而丢失信息。它是系统里唯一一个”永远记得规则”的东西。

AI 写代码的速度很快，但我从不自动合入。每一段 AI 生成的代码，我都会看过之后才放进去。

不是因为 AI 经常写错——准确率其实挺高的。而是因为：

我见过两种极端：一种人拒绝 AI，觉得”真正的程序员不用这些”；另一种人全盘交给 AI，觉得”以后都不用写代码了”。

两种都不对。

AI 是这个时代最强的编程杠杆，但杠杆需要支点。TDD 是支点，AGENTS.md 是支点，人工审查是支点。没有支点的杠杆只是一根棍子——用力越大，失控越快。

我的经验是：约束不是效率的敌人，约束是效率的前提。MCPHub 的开发速度不比任何 vibe coding 项目慢，但三个月后它依然可维护、可理解、可安全迭代。

如果你正在用 AI 写代码——大概率你是的——问自己一个问题：

三个月后，你还能看懂这个项目吗？

如果答案不确定，也许是时候给你的 AI 搭一个脚手架了。不需要放弃速度，只需要加一点结构：写测试、定规范、保持审查。

AI 不会变慢的。但没有约束的代码一定会。