SDD：AI 时代从学院派理想变成工程必需品

SDD（Spec-Driven Development，规格驱动开发）不是新概念。

它的思想根源可以追溯到几十年前。

但在 AI 时代，它从「学院派理想」变成了「工程必需品」。

为什么？因为 AI 改变了游戏规则 —— 以前「写代码」是瓶颈，现在「理解需求」是瓶颈。

第一条：SDD 的思想史 —— 从理想国到必需品

1970s：Spec 的起源

软件危机（Software Crisis）

上世纪 70 年代，软件项目频繁延期、超支、失败。

业界意识到：问题不在代码，在需求。

于是诞生了：

• 结构化分析（Structured Analysis）
• 结构化设计（Structured Design）
• 瀑布模型（Waterfall Model）

核心思想： 在写代码之前，先写详细的规格说明。

理想： 如果你能把规格写得足够清楚，代码就是自然的结果。

1990s：敏捷的反击

敏捷宣言（2001） "

"Working software over comprehensive documentation"

敏捷运动认为：

• 详细的规格说明是浪费时间
• 需求会变，写了也会过时
• 不如直接写代码，快速迭代

SDD 被贴上了「瀑布派」的标签。

在敏捷时代，SDD 成了「反模式」。

2010s：BDD 的妥协

BDD（Behavior-Driven Development）

Dan North 提出 BDD：

• 不写「技术规格」，写「行为规格」
• 用自然语言描述：Given / When / Then
• 让开发者、QA、产品经理都能理解

BDD 是 SDD 的轻量版。

它承认「需要规格」，但反对「过度规格」。

2020s：AI 改变了游戏规则

AI 编码工具（Copilot、Codex、Claude Code）

AI 可以：

• 把自然语言转换成代码
• 自动生成测试
• 自动重构

这意味着什么？

「写代码」不再是最慢的环节。

「理解需求」成了新的瓶颈。

---

AI 时代的 SDD：

不是「瀑布派的重规格」。

不是「敏捷派的无规格」。

而是 「结构化的需求表达」。

• 不需要 100 页的规格文档
• 但需要清晰的输入、输出、约束
• 不需要 UML、形式化方法
• 但需要结构化的描述（目标、范围、验收标准）

SDD 从「学院派理想」变成了「工程必需品」。

因为 AI 需要清晰的输入才能产出可信的代码。

---

第二条：三个代表性工具的逐层分析

工具 1：OpenSpec —— 开源社区的努力

定位： 开源的规格描述语言

核心理念：

"A universal language for software specifications"

特点：

1. 结构化格式 —— 用 YAML/JSON 描述需求

spec:
  name: "User Login"
  input:
    - email: string
    - password: string
  output:
    - success: boolean
    - error: string
  constraints:
    - password must be 8+ characters
    - email must be valid format

2. 工具链集成 —— 可以生成代码、测试、文档
3. 版本控制 —— 规格和代码一样可以 diff、rollback

优势：

• 清晰、结构化
• 可追溯（规格 → 代码 → 测试）
• 跨平台（不绑某个 IDE）

局限：

• 社区驱动，生态不够成熟
• 需要手动维护规格和代码的同步
• 学习成本（新的 DSL）

适合场景：

• 开源项目
• 需要跨团队协作的大型项目
• 对规格有强合规要求的领域（医疗、金融）

---

工具 2：GitHub Spec-Kit —— 集成到工作流

定位： GitHub 原生的规格管理工具

核心理念：

"Specs as Issues"

特点：

1. 原生集成 —— 规格就是 GitHub Issue

## Spec: User Login

### Goal
Allow users to login with email and password

### Input
- Email (string, required)
- Password (string, required, 8+ chars)

### Output
- Success (boolean)
- Error message (string, optional)

### Acceptance Criteria
- [ ] Valid email + correct password → success
- [ ] Valid email + wrong password → error "Invalid credentials"
- [ ] Invalid email → error "Invalid email format"

2. AI 集成 —— GitHub Copilot 可以直接读取 Spec，生成代码
3. 追踪能力 —— Spec → PR → Code，全程可追溯

优势：

• 不需要新工具（就是 GitHub Issue）
• 和 AI 无缝集成
• 团队已经在用 GitHub，零切换成本

局限：

• 绑定 GitHub 生态
• 格式自由，容易不一致
• 缺少验证工具（无法自动检查 Spec 是否被代码实现）

适合场景：

• 已经在用 GitHub 的团队
• 中小型项目
• 想快速上手的团队

---

工具 3：AWS Kiro —— 云原生的一体化方案

定位： 云端的规格驱动开发平台

核心理念：

"From spec to deployment in one platform"

特点：

1. 可视化编辑器 —— 拖拽式创建规格
2. AI 生成 —— 自动生成代码、测试、基础设施代码
3. 云原生集成 —— 一键部署到 AWS
4. 验证引擎 —— 自动验证代码是否实现了 Spec

优势：

• 一体化（Spec → Code → Test → Deploy）
• 低门槛（可视化，不需要写 YAML）
• 自动验证（确保代码和 Spec 一致）

局限：

• 绑定 AWS 生态
• 黑盒式（不知道中间发生了什么）
• 成本高（企业级定价）

适合场景：

• 已经在用 AWS 的企业
• 快速验证想法的 MVP
• 需要端到端自动化的团队

---

三层对比

维度	OpenSpec	GitHub Spec-Kit	AWS Kiro
定位	开源 DSL	GitHub 原生	云平台
格式	YAML/JSON	Markdown	可视化
AI 集成	需要自己集成	原生 Copilot	内置 AI
生态绑定	无	GitHub	AWS
验证	需要自己写工具	无	自动验证
成本	免费	免费	企业级
学习曲线	中等	低	最低
控制权	最高	中等	最低

---

第三条：跨工具的通用原则

无论你用什么工具，SDD 的核心原则是一样的。

原则 1：结构化优于自由文本

Bad：

帮我写一个用户登录功能

Good：

## Goal
User can login with email and password

## Input
- email (string, required)
- password (string, required, 8+ chars)

## Output
- success (boolean)
- error (string, optional)

## Constraints
- Password must be hashed before storage
- Rate limit: 5 attempts per minute

## Acceptance Criteria
- [ ] Valid credentials → success
- [ ] Invalid credentials → error
- [ ] Rate limit exceeded → error "Too many attempts"

为什么？

AI 需要结构化输入才能产出可信代码。

自由文本容易产生歧义。

---

原则 2：独立于实现

Spec 描述「什么」，不描述「怎么做」。

Bad：

Use React to build a login form with useState hook...

Good：

User can login with email and password.
On success, redirect to dashboard.
On failure, show error message.

为什么？

• Spec 应该是技术中立的
• 实现细节可以变化，Spec 不应该变
• AI 可以根据技术栈选择最佳实现

---

原则 3：可验证

Spec 必须能被验证。

每个 Spec 都应该有：

• 验收标准（Acceptance Criteria）
• 测试用例（Test Cases）
• 边界条件（Edge Cases）

Bad：

Make the login fast

Good：

Login API response time < 200ms at 100 concurrent users

为什么？

如果不能验证，Spec 就是没有意义的。

---

原则 4：可追溯

Spec → Code → Test，全程可追溯。

Spec	Code	Test
User login	LoginService.ts	LoginService.test.ts

为什么？

• 当需求变化时，你知道要改哪些代码
• 当 Bug 出现时，你知道哪个 Spec 没被满足
• 当代码重构时，你知道不会破坏功能

---

原则 5：渐进式，不是一次性

SDD 不是「写 100 页规格再写代码」。

是「写一页规格，写一段代码，再写一页规格」。

Bad：

花一个月写完整规格，再开始写代码

Good：

1. 写核心功能的 Spec
2. 实现 MVP
3. 写扩展功能的 Spec
4. 迭代

为什么？

• 需求会变，写了也会过时
• 快速验证比完美规格更重要
• SDD 是持续的过程，不是一次性活动

---

写在最后：SDD 在 AI 时代的价值

传统时代：

• 写代码慢，所以跳过规格，直接写
• 规格是「锦上添花」，不是必需品

AI 时代：

• 写代码快，但理解需求慢
• 规格是「必需品」，不是锦上添花

SDD 的核心价值：

它是「人 - AI - 代码」之间的契约。

• 人告诉 AI 要什么（Spec）
• AI 根据规格生成代码（Code）
• 代码验证规格是否实现（Test）

没有这个契约：

• AI 不知道要什么
• 你不知道 AI 生成了什么
• 代码出了问题不知道谁的责任

有了这个契约：

• AI 有清晰的输入
• 你有可追溯的输出
• 代码有明确的验收标准

---

SDD 的未来

SDD 会越来越重要。

因为：

1. AI 会越来越强 —— 但 AI 依然需要清晰的输入
2. 项目会越来越复杂 —— 需要结构化的需求表达
3. 团队会越来越分布式 —— 需要跨团队协作的通用语言

SDD 不是「回到瀑布派」。

SDD 是「在 AI 时代，重新发明工程实践」。

---

SDD 的思想根源比 AI 编码工具早得多。

但 AI 让它从「学院派理想」变成了「工程必需品」。

这不是历史的倒退。

这是历史的进化。