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

一、两种范式的碰撞

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让开发者如此"上头"？

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

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。来看一个例子：

## 任务：用户认证功能


### 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 的做法

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

## 推荐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的必备输入

关键原则

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

七、结语

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

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

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

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

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

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

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

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