从 Vibe Coding 到 Spec Coding：如何用 TDD 解决 AI 带来的“架构崩坏”AI 时代，仅靠规

ai 改动前原文：从 Vibe Coding 到 Spec Coding：如何用 TDD 解决 AI 带来的“架构崩坏”

在研发管理中，最令人窒息的场景莫过于此：你下发了一个任务，开发者“潜水”了一个月，最后提交了一个包含数千行代码的巨型 PR。当你忍着头痛打开 Review 时，却发现对方完全误解了业务逻辑，或者在这个项目中重新发明了轮子，甚至破坏了原有的分层架构。

现在，这个噩梦升级了。你不仅丢给对方一个任务，还附带了详细的规范文档（Spec）和强大的 AI 工具。表面上，他在编辑器里与 AI 谈笑风生，但在 PR 提交前，没人知道发生了什么。

最大的风险在于：对于业务和架构的错误理解，会被 AI 无限放大。 AI 越强大，这种“偏离航道”的速度就越快，破坏力就越强。

很多团队试图通过“规范驱动”来解决这个问题：要求 AI 生成长篇的 plan.md 或《功能拆解文档》，并组织团队在语雀或飞书上进行文档评审。

但这往往是一种错觉。文档评审最多只能确认**“业务理解”（做什么），却很难验证“架构落地”**（怎么做）。

看着文档里的“实现用户登录”，你看不出他会写出循环依赖。
看着文档里的“调用通用组件”，你看不出他会因为参数透传错误导致破坏性变更。这种基于自然语言的文档协作，颗粒度太粗，存在巨大的解释空间。多人协作中最昂贵的成本，就是这种“以为达成了共识”的误解。

如果让 AI 把代码实现细节全写在文档里，那是本末倒置。其实，我们早就有了最精准的协作语言——测试代码（TDD）。

我们需要从流程上入手，引入 TDD Review 环节，重构多人协作流：

第一步：Spec 也就是 Test 开发者拿到任务后，不急着让 AI 写实现代码，而是先让 AI 产出测试代码（Test Case）。
第二步：TDD Review（关键协作点） Review 负责人（架构师或 Tech Lead）介入。此时我们不看实现，只看测试。
- 看测试用例，确认**“你真的懂了需求”**（业务边界覆盖是否完整）。
- 看 Mock 数据和依赖注入，确认**“你真的懂了架构”**（是否复用了正确的组件，是否遵循了分层原则）。
第三步：Implementation 只有当测试代码通过 Review，达成“契约”后，开发者才继续让 AI 生成实现代码，跑通测试。

1. 它是“看得见、摸得着”的理解力证明 文档可以注水，但测试代码不会骗人。测试代码是一杆秤，它迫使开发者（和 AI）必须把模糊的需求，具象化为精确的函数调用和断言。Review 测试代码，就是在 Review 开发者对系统的真实认知。

2. 它是极低成本的“结对编程” 真正的结对编程太耗时，而 TDD Review 是一种“异步的结对”。Review 一个几百行的测试文件，远比 Review 一个几千行的完整功能要快得多，且思维密度极高。我们在代码还没写坏之前，就完成了思维的对齐。

3. 它是防止架构腐化的防火墙 在多人协作中，架构往往是被“无知”破坏的。通过 Review 测试代码中的 Setup 环节，我们可以轻易发现开发者是否在引入不该引入的包，或者是否在进行不合理的数据库调用。

规范驱动开发之所以体验不好，是因为我们把它做成了单向的约束，而非双向的协作。

TDD Review 本质上是一次“握手”。

它解决了“做什么”和“怎么做”的问题，并将其固化为代码。它让 Spec Coding 不再是纸上谈兵的文档，而是变成了可执行的协作契约。

在 AI 时代，解决“产出太多怎么读”的唯一解法，就是不读文档，读测试；不看实现，先看契约。 这才是高效团队应有的 Vibe。