Vibe Coding 的终局：AI 编程为什么还需要写规格文档

Vibe coding 让原型开发变得极快，但项目一旦变大就开始失控。本文解释这背后的原因，以及规格驱动开发如何把 AI 编程效率再提一个台阶。

Vibe coding 并没有死——它只是进化了。快速原型阶段，随手一句 prompt 就能跑起来确实爽；但随着项目变大，纯粹依赖"感觉"驱动 AI 写代码会带来一个固定的崩溃序列：改了按钮，导航栏坏了；修了导航栏，登录失效；修了登录，样式全没了。根本原因不是 AI 不行，而是你给的是一块空地，而不是蓝图。规格驱动开发（Spec-Driven Development）的核心就一条：先想清楚再开工，让 AI 按图施工。

Vibe Coding 为什么在小项目上好用

Prompt → 生成 → 复制 → 运行 → 报错 → 再 Prompt——这个循环对于周末项目来说完全够用。没有样板代码，没有环境配置，脑子里的想法当天晚上就能跑起来。这种体验让很多人重新爱上了编程。

问题在于，这套循环本质上是边界不清的状态机。你在改 A，AI 同时在想 B 和 C；你在修第三轮，AI 已经忘了第一轮的约束。会话越长，上下文越乱，每次修一个地方就破坏两个地方。

项目变大之后的典型崩溃序列

你："把这个按钮改成绿色"
AI：改了按钮，顺手重构了导航栏
你："你为什么动导航栏"
AI："我觉得这样更好"
你："你修的那个导航栏让登录挂了"
AI：修了登录，删掉了一半样式

这不是 AI 的 bug，是没有规格导致的必然结果。AI 在补全你没说的部分，而你根本没告诉它哪些地方不能动。

规格驱动开发：先写蓝图，再让 AI 施工

规格驱动开发不是要抛弃 AI，而是在 prompt 之前多做一件事：把需求写清楚。

一个最简单的 spec.md 包含四类信息：

目标用户是谁——AI 才能判断哪些功能有意义
必须有哪些功能——第一版必须做，不是"以后可以加"
哪些东西不能改——约束比需求更重要，AI 最容易在这里越界
完成的判断标准——没有终止条件，AI 会无限打磨

文件名叫 spec.md、requirements.md 还是 tasks.md 都无所谓，重要的是在第一行代码生成之前把这些问题回答完。

规格写完之后，Vibe Coding 效率反而更高

这听起来像是在给 AI 编程加负担，实际上恰好相反。有了规格之后：

AI 生成的代码不再需要整体推倒重来，只需要小改
"不是这样" 的次数大幅减少，因为你一开始就说清楚了
每次 prompt 更短，因为规格文件已经携带了大量上下文
Token 消耗更少，因为不用反复纠正方向

一个经历过这种转变的开发者的描述："花在编码前的时间越多，项目完成得越快；重新生成越少，每次生成都在推进项目往前走。"

在 Cursor / Claude Code 里的具体用法

在 Cursor 里，把 spec.md 放在项目根目录，用 @spec.md 在每次 prompt 开头引用。Claude Code 则可以通过 CLAUDE.md 或 Project Context 把规格固定在会话里。

关键操作：每次新功能开工前，先更新规格文件，再开始 prompt。不要在实现到一半的时候才想起规格文件里某个约束。

常见问题

问：写规格文档会不会拖慢开发速度？ 答：短期看是额外的 30-60 分钟，但能减少后续数小时的返工。项目越大，这个 ROI 越高。对于两天内能做完的原型，可以直接 vibe coding，不需要正式规格。

问：规格要写多详细？ 答：能回答"哪些东西绝对不能改"就够了。不需要写正式的 PRD，一份能给 AI 明确约束的清单就足以避免 80% 的失控场景。

问：Vibe coding 完全被取代了吗？ 答：没有。凌晨两点有个想法想快速验证，直接开 AI 工具就行，不需要先写规格。Vibe coding 在探索阶段仍然无可替代，规格驱动是在探索之后、正式开发阶段才介入的。

参考资料

Vibe Coding: Endgame