SDD vs Vibe Coding：AI 编程时代的"自由派"与"规范派"，如何兼得？

当代码可以像聊天一样生成，我们还需要规格说明吗？答案是：不仅要，还要结合着用。

一、两种范式的碰撞

2025年，AI编程工具全面爆发。Cursor、Claude Code、GitHub Copilot、Windsurf......开发者们从未如此"高产"------一个曾经需要两周的登录模块，现在两小时就能跑起来。

但与此同时，另一种声音也开始出现：

"AI写的代码，看是能看，但改起来真费劲。"

"跑了两周，突然发现整个架构方向都是歪的。"

"功能实现了，但边界条件全没考虑。"

这两种声音，恰好对应了当前AI编程的两种范式：Vibe Coding 和 Spec Driven Development（规格驱动开发）。

前者追求速度与直觉，后者追求严谨与可维护性。它们不是非此即彼的对立关系，而是AI编程光谱的两端。理解它们各自的定位，学会让它们协同工作，是每个AI时代的开发者都必须掌握的技能。

二、Vibe Coding：编程的"自由式"

2.1 什么是 Vibe Coding？

"Vibe Coding"这个词由前特斯拉AI总监、OpenAI联合创始人Andrej Karpathy提出。他的原话是：

"The hottest new programming language is English."

换成中文也一样------最热门的编程语言，是自然语言本身。

在实际操作中，Vibe Coding的工作流是这样的：
flowchart LR A $💡 灵感/想法$ --> B $✍️ 写一句Prompt$ B --> C $🤖 AI生成代码$ C --> D{😃 满意吗？} D -->|不满意| E $🔧 调整Prompt$ E --> C D -->|满意| F $✅ 交付$

整个过程就像一场对话：你描述想法，AI给你结果，你来来回回调整，直到差不多能用。

2.2 Vibe Coding 的魔力

为什么Vibe Coding让开发者如此"上头"？

极低的启动门槛。不需要写详细的设计文档，想到什么说什么，AI立刻给你反馈。这种感觉就像画画时先用铅笔打草稿------快速、自由、不设限。
探索效率极高。当你想验证一个想法、测试一个API、或者快速搭建一个Demo时，Vibe Coding是最佳选择。传统方式需要先设计、再编码、再调试；Vibe Coding可以让你在30分钟内看到可运行的原型。
创造力解放。因为你不用纠结于实现细节，所以可以把更多精力花在"想要什么"而不是"怎么做"上。这种体验特别适合前端页面、工具脚本、数据分析等探索性工作。

2.3 Vibe Coding 的暗面

然而，Vibe Coding的自由是有代价的，而这个代价会随项目规模呈指数级增长：

问题	表现
模糊性累积	"做个登录功能"------AI默认选了最简单的实现，而你忘了说要支持验证码
边界条件缺失	能跑通Happy Path，但错误处理、限流、降级策略一概没有
架构一致性差	每次对话都是独立的，AI不知道你项目的整体架构约束
可维护性黑洞	代码"能用"，但重构成本极高------因为没有人真正理解全部逻辑
幻觉放大	AI擅自在代码里"加戏"，引入你从未要求的功能或依赖

Karpathy本人也承认这一点。他在提出Vibe Coding的同时，也调侃说自己在Vibe Coding时经常"全盘接受AI的建议"，因为"懒得去深究"。

问题不在于模型不够强大。问题在于，我们是在凭感觉进行开发。

因此Vibe Coding也可以称之为意识流编程。

三、SDD：编程的"规范派"

3.1 什么是 SDD？

Spec Driven Development（规格驱动开发）并不是一个新概念。它的思想根源可以追溯到：

契约式设计（Design by Contract）：Bertrand Meyer在1986年提出的概念，强调软件模块之间应该通过明确的"契约"来交互
行为驱动开发（BDD）：用自然语言描述系统行为，然后驱动开发
测试驱动开发（TDD）：先写测试，再写代码

SDD的核心思想很简单：在写代码之前，先用结构化的规格说明（Spec）定义清楚"系统应该做什么"。

这听起来像是回到了瀑布模型的"需求文档先行"，但实际上完全不同------SDD的规格说明是活的，它直接驱动AI生成代码、测试、文档，并且随项目演进持续迭代。

3.2 SDD 的工作流

flowchart TB A $📋 编写Spec文件$ --> B $🤖 AI评审Spec$ B --> C{🔍 Spec是否清晰？} C -->|不清晰| D $👤 人工修正Spec$ D --> B C -->|清晰| E $🧪 根据Spec生成测试$ E --> F $💻 根据Spec生成代码$ F --> G $📊 根据Spec验证结果$ G --> H $📖 Spec即为文档$

与Vibe Coding的关键区别在于：你不再只是"描述想法"，而是在"定义行为与约束"。

3.3 一份好的 Spec 长什么样？

SDD的Spec可以用Markdown文件来写，清晰、可版本控制、可直接喂给AI。来看一个例子：

markdown 复制代码

## 任务：用户认证功能

### API 定义
- 端点：`POST /api/user/login`
- 输入格式：JSON
- 输出格式：JSON

### 行为规约
1. 输入：用户名（支持手机号/邮箱/普通用户名）+ 密码
2. 连续登录失败 ≥ 3 次时，额外要求4位图形验证码
3. 登录成功返回 200，响应体包含：
   - access_token（JWT，有效期2小时）
   - refresh_token（UUID，有效期14天）
   - user_id、角色列表、scope
4. 认证失败返回 401，响应体包含错误码和错误描述

### 安全约束
- 同一IP每分钟限流10次
- 连续10次失败后锁定账户：
  - 首次锁定15分钟，每次递增15分钟，上限12小时
- 密码存储使用 bcrypt（cost=12）

### 可观测性
- 记录登录日志：请求时间、IP、User-Agent、来源（APP/Web）
- 暴露 Prometheus 指标：login_total、login_failure_total、login_latency

### 技术栈
- 语言：Python 3.12+
- 框架：FastAPI
- 数据库：PostgreSQL
- 缓存：Redis

注意：这份Spec里，没有一行代码，但定义了一切。AI拿到它之后，可以：

生成符合约定的API实现
生成对应的单元测试和集成测试
生成API文档
在重构时验证行为一致性

四、正面交锋：Vibe Coding vs SDD 全方位对比

4.1 核心差异一览

维度	Vibe Coding	SDD（规格驱动开发）
思考方式	反应式：边做边想	结构式：先想再做
输入	自然语言Prompt	结构化Spec（Markdown/YAML/JSON）
驱动因素	直觉 & 对话反馈	行为规约 & 约束条件
AI的角色	主力编码者	协作执行者
人的角色	提示词工程师	产品经理 + 架构师
文档	事后补救（大概率没有）	Spec即文档
测试	手动验证为主	Spec驱动自动生成
可追溯性	弱（谁知道AI为什么这么写）	强（Spec是唯一可信来源）

4.2 一个具体案例的对比

假设需求是："构建一个商品推荐API"。

Vibe Coding 的做法

复制代码

你：用嵌入向量构建一个推荐API
AI：好的，这是代码...
你：加上分页
AI：已添加...
你：排除同品牌商品
AI：已排除...
你：好像没做超时处理？
AI：抱歉，我来加上...

结果：功能"能用"，但你很可能漏掉了：

相似度阈值（推荐了完全不相关的商品怎么办？）
冷启动策略（新商品没有嵌入向量怎么办？）
降级方案（向量搜索服务挂了怎么办？）
评估机制（你怎么知道推荐效果好还是差？）

SDD 的做法

在写一行代码之前，先定义：

markdown 复制代码

## 推荐API行为规约

### 输入
- product_id: string（必填）

### 处理流程
1. 根据 product_id 从向量库检索嵌入向量
2. 执行余弦相似度搜索
3. 过滤规则：
   - 排除同品牌（brand_id 相同）
   - 相似度阈值 < 0.82 的视为不相关
   - 排除已下架商品
4. 结果排序：相似度降序
5. 限制返回 top 10

### 降级策略
- 向量库不可用时 → 回退到基于标签的规则推荐
- 匹配结果 < 3 时 → 自动回退到热门商品推荐

### 性能要求
- P99延迟 < 200ms
- 需要 Redis 缓存（TTL: 30分钟）

### 可观测性
- 记录每次推荐请求的延迟和相似度分布
- 提供离线评估脚本（基于标注数据集）

拿到这份Spec，AI可以一次性生成：

完整的推荐服务实现
单元测试（覆盖正常流程、降级策略、边界条件）
评估脚本
监控面板配置

4.3 适用场景矩阵

场景	推荐范式	原因
快速原型/ Hackathon	Vibe Coding	速度优先，明天就可能扔掉
个人工具脚本	Vibe Coding	你一个人用，知道所有隐式假设
探索性数据分析	Vibe Coding	需求在不断变化，Spec跟不上
前端UI快速迭代	Vibe Coding	肉眼可见，调就完了
生产级后端API	SDD	边界条件多，出问题影响大
多服务协作系统	SDD	契约不清晰 = 下游全崩
金融/医疗等合规系统	SDD	可审计性是不可妥协的
多人协作的大型项目	SDD	Spec是团队的共同语言
需要长期维护的核心模块	SDD	代码会换人，Spec会留下

五、最佳实践：如何让两者协同工作？

这才是本文最重要的部分。 Vibe Coding和SDD不是二选一，而是可以根据项目阶段交替使用。以下是我在实践中总结的组合策略。

5.1 三阶段混合工作流

flowchart TB subgraph 阶段1 $"阶段一：Vibe 探索"$ A1 $💡 模糊想法$ --> A2 $🤖 Vibe Coding快速出原型$ A2 --> A3 $👀 体验 \& 验证可行性$ A3 --> A4{🤔 方向对吗？} A4 -->|不对| A1 A4 -->|对了| A5 $📝 沉淀为Spec草稿$ end subgraph 阶段2 $"阶段二：Spec 固化"$ B1 $📋 完善Spec$ --> B2 $🤖 AI评审Spec$ B2 --> B3 $🔧 补充边界条件$ B3 --> B4 $👥 团队Review$ B4 --> B5 $✅ Spec定稿$ end subgraph 阶段3 $"阶段三：Spec 驱动实施"$ C1 $🧪 生成测试$ --> C2 $💻 生成实现$ C2 --> C3 $📊 验证 \& 部署$ C3 --> C4 $🔄 迭代更新Spec$ end A5 --> B1 B5 --> C1

阶段一：Vibe 探索（快速试错）

这个阶段的目标是验证想法的可行性，不是写出完美代码。

用Vibe Coding快速搭建MVP
大胆尝试不同的技术路线
不要纠结代码质量------这段代码大概率会被重写
把重点放在"这样做的用户体验对吗？"而不是"代码写得优雅吗？"

产出物：一个能跑的原型 + 对需求的初步理解

阶段二：Spec 固化（沉淀共识）

一旦确认方向正确，立刻刹车，转入Spec模式。

把探索阶段积累的理解，整理成结构化的Spec
让AI帮你Review：把Spec发给AI，让它指出模糊之处
团队Review：Spec是团队的共同语言，必须达成共识
特别关注边界条件：错误处理、降级策略、性能约束、安全要求

产出物 ：一份经过Review的Spec文件（建议放在项目仓库的/specs/目录下）

阶段三：Spec 驱动实施（严谨交付）

先让AI根据Spec生成测试用例（TDD + SDD的组合拳）
再让AI生成实现代码
用Spec验证产出：跑测试、做Code Review、对照Spec逐条检查
随着需求变化，先更新Spec，再更新代码------保持Spec永远是"唯一可信来源"

产出物：可交付的代码 + 测试 + 文档（Spec本身就是文档）

5.2 "Vibe中写Spec"------反向操作

另一个非常实用的技巧是：用Vibe Coding的方式来帮你写Spec。

比如你想做一个支付模块，自己不确定要考虑哪些边界条件？直接把需求丢给AI：

复制代码

你：我准备做一个支付模块的Spec，帮我brainstorm一下需要考虑哪些方面，特别是容易遗漏的边界条件？

AI：（列出几十个要点，包括幂等性、回调重试、分布式事务、对账、退款流程......）

你：很好，基于这些，帮我生成一份初始Spec草稿。

Vibe Coding负责发散，SDD负责收敛。 这个组合非常强大。

5.3 按模块粒度灵活切换

不是整个项目只能选择一种范式。同一个项目里，可以按模块粒度灵活切换：

复制代码

项目/
├── specs/
│   ├── user-auth.spec.md        ← SDD（安全敏感，边界条件多）
│   ├── payment.spec.md          ← SDD（金融合规，不能出错）
│   └── recommendation.spec.md   ← SDD（算法行为需要精确控制）
├── src/
│   ├── admin-dashboard/         ← Vibe Coding（内部工具，快速迭代）
│   ├── analytics-reports/       ← Vibe Coding（探索性需求，频繁变化）
│   └── landing-page/            ← Vibe Coding（营销页面，视觉驱动）

判断标准：问自己"如果这个模块出bug，影响有多大？"

影响小 → Vibe Coding
影响大 → SDD

5.4 Spec 的"恰到好处"原则

SDD最大的陷阱是过度规约（Over-Specification）。记住：

Spec不是写作文，不需要面面俱到。它只需要定义"做什么"和"不做什么"的边界。

好的Spec像篱笆：划定边界，而非规划每一寸土地。

Spec层级	包含内容	示例
必须	API契约、数据模型、安全约束、降级策略	"同一IP每分钟限流10次"
建议	推荐的技术方案、性能目标	"P99 < 200ms，缓存TTL 30分钟"
避免	具体实现细节、类结构、内部算法	"使用工厂模式创建PaymentProcessor"

当发现自己在Spec里写"请使用XXX设计模式"时，停笔。那是AI该操心的事情。

六、给团队的实践路线图

如果你所在的团队正在引入AI编程，以下是一个循序渐进的路线图：

第一步：从Vibe Coding开始（第1-2周）

让团队成员先用Vibe Coding的方式感受AI编程的魅力。建立对AI能力的直觉：什么它能做好，什么它容易搞砸。

第二步：引入轻量Spec（第3-4周）

选一个中等复杂度的模块，尝试写一份Spec再让AI实现。对比一下Vibe Coding的产出和SDD的产出，让团队自己感受到差异。

第三步：建立Spec模板与规范（第5-8周）

沉淀团队的Spec模板，明确什么该写、什么不该写。把Spec文件纳入代码仓库，和代码一起做版本管理。

第四步：将Spec融入CI/CD（第9周起）

Spec变更 → 自动触发AI评审
代码提交 → 自动检查是否符合Spec
Spec文件成为Code Review的必备输入

关键原则

Spec是"唯一可信来源"。任何时候，Spec和代码有冲突，先对齐Spec。
先Spec后代码。需求变更时，先改Spec，再让AI重新生成。
Vibe探索，Spec交付。用Vibe Coding找到方向，用SDD确保质量。
不做过度规约。Spec定义行为边界，不是替代AI思考。

七、结语

回到文章开头的问题：当代码可以像聊天一样生成，我们还需要规格说明吗？

需要，比以往任何时候都需要。

不是因为代码质量下降了------AI生成的代码在语法层面几乎不会出错。而是因为：

模糊性无法规模化。一个5人团队可以靠口口相传对齐理解，一个50人的团队只能靠文档。
AI是通才，不是全才。它不懂你的业务上下文，不理解你的架构约定。Spec就是你和AI之间的"上下文桥梁"。
代码廉价，清晰度昂贵。在这个AI能秒出代码的时代，真正稀缺的不再是"写代码的能力"，而是"想清楚要写什么的能力"。

Vibe Coding让你跑得快，SDD让你跑得远。

真正的AI编程高手，懂得在"快"和"远"之间自由切换。

当你用Vibe Coding探索出一个绝妙的想法，然后用SDD把它打磨成生产级的解决方案------那一刻，你会真正感受到AI编程的完整力量。

如果你觉得这篇文章有帮助，欢迎分享给正在探索AI编程的同事。也欢迎在评论区聊聊：你在日常开发中，更偏向Vibe Coding还是SDD？你是怎么平衡两者的？