Vibe Coding 爽完就返工？试试 Spec-Driven Development：AI 时代真正的工作流

不知道你有没有这种体验：周末晚上打开 Claude Code 或 Cursor，对着对话框敲下一句"帮我做一个用户认证系统"，AI 唰唰唰生成 2000 行代码，跑起来了。那一刻你觉得自己是神。结果第二天上班，你发现它用的是 Mock.js，或者框架跟你公司技术栈对不上，于是你开始改。第二周，你在修它猜出来的业务逻辑。第一个月，你开始怀疑：到底是 AI 在帮我写代码，还是我在帮 AI 擦屁股？

这不是你的问题，也不是 AI 能力不够。说白了就是：AI 能力超强，但我们给它的上下文不够。

今天聊聊 Spec-Driven Development（规范驱动开发，简称 SDD），以及它为什么正在取代纯 Vibe Coding，成为 AI 协作的新范式。

---

一、Vibe Coding 为什么爽完就返工？

Vibe Coding 的本质是"氛围编程"：你在对话框里凭感觉下任务，AI 凭感觉生成代码。这个过程非常上头，因为它跳过了所有前期设计，直接给你结果。

但问题恰恰出在这里。

1. 上下文缺失，AI 只能猜

你只说"帮我做一个用户认证系统"，AI 不知道：

• 你的技术栈是 NestJS 还是 Python？
• 数据库用 PostgreSQL 还是 MongoDB？
• 认证方式是 JWT 还是 Session？
• 要不要支持刷新令牌？要不要第三方登录？

于是它只能猜。猜对了是运气，猜错了就是返工。

2. 会话历史丢失，关键决策蒸发

Vibe Coding 严重依赖对话历史。但会话一旦丢失、被压缩或切换新窗口，之前聊过的约束就全没了。AI 开始自由发挥，幻觉随之而来。

你会发现，每一轮失败都在消耗两样东西：等待 AI 生成的时间，以及真金白银的 token。

3. 返工成本后置

第一天效率提升 10 倍，第二周开始返工，第一个月陷入自我怀疑。这不是段子，是大量开发者的真实经历。

纯 Vibe Coding 的问题在于：它跳过了第一次创造，直接进入第二次创造。返工是必然。

---

二、SDD：所有事物都要经过两次创造

这个概念来自史蒂芬·柯维的《高效能人士的七个习惯》------以终为始。

柯维认为，优秀的人做事会经历两次创造：

1. 第一次创造：心智创造------在脑子里把这件事想清楚，设计出样子。
2. 第二次创造：物理创造------动手把它做出来。

放到软件开发里：

• 第一次创造 = 写规范文档（Proposal / Design / Task）
• 第二次创造 = AI 或人根据规范写代码

你会发现，建筑行业早就这么干了：不画蓝图就不盖房。 商业领域也一样：不写商业计划就不创业。

但到了编码领域，Vibe Coding 的聊天窗口太诱人了，它让我们跳过第一次创造，直接让 AI 进行物理创造。结果就是：代码跑得起来，但后面一堆麻烦。

SDD 的核心就一句话：先撰写文档，再编写代码。

当代码生成成本越来越低，真正稀缺的是清晰、可执行、可验证的意图。

---

三、SDD 三件套：Proposal / Design / Task

SDD 不是说"文档越多越好"，而是按需加载。对大多数项目来说，三份文档就能完成第一次创造。

3.1 Proposal：为什么做、做什么、不做什么

Proposal 回答的是"这个系统应该是什么样，满足什么需求"。它通常包括：

• 背景：为什么需要这个系统？
• 目标：要解决哪些问题？
• 非目标：明确不做什么，防止范围蔓延。

示例：

# Proposal: 用户认证系统

## 背景
现有各服务各自实现登录，导致用户数据割裂，无法统一鉴权。

## 目标
- 提供注册、登录、刷新令牌能力
- 支持 JWT 无状态鉴权
- 与现有 NestJS 服务集成

## 非目标
- 不做第三方 OAuth（预留接口）
- 不做多因素认证

你会发现，光是把"非目标"写清楚，就能避免 AI 自由发挥加一堆你用不上的功能。

3.2 Design：怎么做

Design 回答的是技术实现方案。它把脑子里的架构落到文档上，成为 AI 编码的上下文。

# Design: 用户认证系统

## 技术栈
- NestJS + Prisma + PostgreSQL
- JWT access token + refresh token
- bcrypt 密码哈希

## 数据模型
User { id, email, passwordHash, createdAt }

## 接口
POST /auth/register
POST /auth/login
POST /auth/refresh

这一步的价值在于：把你和 AI 之间的"猜谜游戏"变成"对图施工"。

3.3 Task：先做什么、再做什么

Task 把设计拆解成可执行、可验证的任务列表。关键是要有依赖顺序。

# Tasks

- [ ] T1 初始化 NestJS 项目与 Prisma 连接
- [ ] T2 实现 User 模型与数据库迁移
- [ ] T3 实现注册接口与密码哈希
- [ ] T4 实现登录接口与 JWT 签发
- [ ] T5 实现刷新令牌与鉴权守卫
- [ ] T6 编写集成测试

有了 Task，AI 不再一次性吐出 2000 行代码，而是按步骤推进。每完成一个任务，你都可以验证，而不是最后才发现方向错了。

文档不是写给老板看的，是写给 AI 看的上下文。

---

四、一个最小可跑的 SDD 工作流

你可以用 Spec-Kit 这类工具初始化规范目录，也可以手动创建三个 Markdown 文件。核心是思想，不是工具。

假设项目结构如下：

specs/
  proposal.md
  design.md
  task.md
src/

然后给 AI 下指令时，不再是"帮我做一个认证系统"，而是：

请先阅读以下文件：
- specs/proposal.md
- specs/design.md
- specs/task.md

然后从 task.md 中第一个未完成的任务开始实现。

要求：
1. 不要修改 specs/ 目录下的任何文档
2. 每完成一个任务，运行测试并报告结果
3. 如果发现规范有歧义或冲突，立即停止并向我提问

这样做有三个直接好处：

1. 上下文稳定：每次新会话都从同一份文档开始，不再依赖脆弱的聊天历史。
2. 可验证：任务粒度小，每一步都能跑测试，问题早发现。
3. 可复用：规范文档可以沉淀到仓库，下次迭代或新成员接入时直接复用。

对于大项目，还可以进一步按需加载：不要把所有模块的 Design 都塞给 AI，而是根据当前任务只加载相关部分。比如实现认证模块时，只读认证的 design.md，不读支付模块的设计。这样既省 token，又减少干扰。

---

五、SDD 不是负担，是新的工作内容

很多开发者一听到"先写文档"就头疼，觉得这会拖慢开发速度。但你要想清楚：以前你也不是不设计，而是在脑子里设计，或者边写边设计。 现在只是把这个过程显性化、文档化。

而且，写文档这件事本身也可以让 AI 辅助。你可以先让 AI 根据需求生成 Proposal 草稿，你再修改确认。关键是：规范文档必须由人来拍板，不能全盘交给 AI 生成。

SDD 借鉴了建造业的蓝图、商业的计划书，本质上是把"先设计后施工"引入 AI 编码。当代码生成成本越来越低，真正稀缺的就不再是写代码的速度，而是清晰、可执行、可验证的意图。

先设计，再编码；先文档，再 Agent。

---

结语

Vibe Coding 不是一无是处，它适合快速探索原型、验证想法。但一旦进入持续交付阶段，纯靠"氛围"驱动，返工几乎是必然。

SDD 的核心不是写文档，而是完成第一次创造。把做什么、为什么做、怎么做、如何一步步做，用文档固定下来。然后让 AI 在规范的约束下，高效完成第二次创造。

下次再打开 AI 编码工具时，不妨先停下来问自己一句：

我现在是准备画蓝图，还是准备直接盖房？

代码生成成本越来越低，真正稀缺的是清晰、可执行、可验证的意图。SDD 不是让你少写代码，而是让你写对代码。