> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 探索规范驱动的开发
- URL: https://www.hubwiz.com/blog/exploring-spec-driven-development/
- Published: 2026-05-17T16:20:47.000Z
- Updated: 2026-10-13T15:51:44.000Z
- Description: 规范驱动开发代表了软件开发方法论的一次重大演进，特别适合 AI 辅助编程的时代。
- Author: admin
- Tags: VIBE CODING, SDD, SPEC-KIT, #Import 2026-10-14 14:41

当我第一次开始使用 AI 编码助手时，我注意到一件有趣的事情：虽然这些工具非常强大，但它们有时生成的代码并不能完全符合我的想法。你是否也遇到过这种情况？你描述了一个功能，AI 生成了一些代码，然后你花了数小时调试和调整，使其符合你的实际需求。

我反复遇到这个问题，直到我发现了规范驱动开发（SDD）。这种方法彻底改变了我与 AI 编码助手合作的方式，在这篇文章中，我将分享我的所学，以及你如何在在自己的项目中应用它。

在这篇文章中，你将了解：

- 什么是规范驱动开发以及它为何重要
- 它与流行的"氛围编程"方法相比如何
- 使用 GitHub SpecKit 和 Copilot 的实际工作流
- 你可以立即实践的实例

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-4epNqPAu88pkmBL8JSaztg.png)

## 1、什么是 SDD（规范驱动开发）？

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-JFkQec4-3IlKbn-TnVxWgQ.png)

规范驱动开发（SDD）代表着我们处理软件开发方式的根本性转变，尤其是在 AI 辅助编程的时代。让我用简单的语言来解释一下。

想一想传统的软件开发：我们通常先开始编码，然后边做边摸索。但有了 SDD，我们采取不同的方法——我们首先创建详细的规范，然后让这些规范指导整个开发过程。

在 SDD 中，规范充当需要构建的内容的权威真相来源。这一点至关重要：我们将"做什么"与"怎么做"分离开来。规范描述系统应该做什么，而实现则决定如何去做。

这种方法在涉及的所有人之间建立了一个清晰、无歧义的契约——业务利益相关者、产品经理、开发人员，是的，甚至包括 AI 编码智能体。

我发现特别有趣的是：SDD 的基本理念与我们多年来使用的实践——测试驱动开发（TDD）和行为驱动开发（BDD）是一致的。但 SDD 将规范概念提升到了更全面的层面。不仅仅是用户故事，SDD 规范还包括详细的验收标准、技术约束、架构决策和实现指南。

相当全面，对吧？让我们看看它与另一种流行方法相比如何……

## 2、SDD 相比氛围编程的优势

生成式 AI 的兴起普及了我所说的"氛围编程"——一种开发人员通过对话式提示与 AI 助手交互的方法，通常很少使用正式规范。虽然这种方法在一定程度上使编程民主化，但它带有 SDD 能够解决的重要局限性。

### 2.1 氛围编程的局限性

**1\. 质量不一致**

我早就注意到了这一点：GenAI 擅长模式识别，但在揣摩人心方面却很吃力。AI 生成代码的质量直接与你的提示和上下文的质量及清晰度相关。当提示含糊时，你会得到不可靠的代码，迫使你花大量时间调试 AI 生成的解决方案，而不是专注于实际的开发工作。

你是否曾经花在修复 AI 生成的代码上的时间比从头开始编写还要多？这正是我要说的。

**2\. 上下文管理挑战**

氛围编程常常导致上下文碎片化，分散在多个对话中。当规范没有被正式记录下来时，保持跨功能的一致性就变得几乎不可能——尤其是在团队环境中。

随着项目的增长，这真的会成为一个问题。不同的团队成员可能会向 AI 提出类似的问题，但由于他们基于不同的心智模型工作，得到的结果却不同。

**3\. 可扩展性有限**

随着项目的增长，氛围编程的非正式性就会崩溃。对于原型来说完美的东西，对于生产系统来说可能变得完全不可管理，尤其是在涉及多个开发人员或 AI 智能体时。

我亲眼目睹过这种情况——一个快速的 AI 驱动原型，如果不小心，可能会变成一个维护噩梦。

### 2.2 SDD 的优势

**1\. 清晰与精确**

SDD 通过要求规范清晰、完整且无歧义来消除模糊性。这种精确性直接转化为更高质量的 AI 生成代码，因为编码智能体有明确定义的需求可以参考。

关键在于，每个人——无论是人还是 AI——都在基于相同的清晰理解工作。这是一个改变游戏规则的因素。

**2\. 可维护的上下文**

规范是随着代码库演变的活文档。当需求变更时，规范首先被更新，确保所有利益相关者——人类和 AI——基于相同的理解工作。

这对 AI 智能体尤其重要，它们可以参考最新的规范，而不是依赖可能已经过时的对话。

**3\. 可验证的需求**

SDD 规范包含明确的验收标准，支持自动化验证。这将规范从被动的文档转变为主动的质量关卡，类似于 TDD 将需求转化为可执行的测试。

巧妙的设计，对吧？规范本身变成了一个可测试的工件。

**4\. 更好的团队协作**

正式规范提供了一种共同语言，业务利益相关者、产品经理和开发人员都可以理解和验证。这减少了误解，确保每个人都在构建的内容上保持一致。

我发现这在让新团队成员快速上手时非常有价值——他们可以阅读规范并理解正在构建什么，而无需直接深入代码。

**5\. 提升 AI 智能体性能**

对于像 GitHub Copilot 这样的 AI 编码智能体来说，结构良好的规范提供了它们生成准确、可靠代码所需的丰富上下文。SDD 本质上将需求"预处理"成 AI 智能体可以有效消费的格式。

这就是神奇之处所在。AI 不必猜测你想要什么——它有了详细的规范可以参考。

## 3、SDD 的理论级通用工作流

SDD 方法论遵循一个结构化的工作流，将抽象的需求转化为具体的实现。让我带你了解四个不同的阶段。

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-Te2RLI4h5YCA_oYJnC1GTw.png)

### 阶段 1：规范 - 定义"做什么"

规范阶段回答了一个基本问题："我们在构建什么？"这个阶段专注于定义行为、需求和验收标准，而不规定实现细节。

**关键组件：**

- **行为定义**：系统在各种条件下应做什么的清晰描述
- **用户故事和场景**：使用 Given/When/Then 等既定模式描述预期行为
- **验收标准**：功能被视为完成所必须满足的明确条件
- **边界情况和错误条件**：对异常场景的全面覆盖
- **非功能需求**：性能、安全、可扩展性约束

**关键原则**：这个阶段的核心技能是在消除歧义的同时避免过度规范。规范应足够清晰以指导实现，但又足够灵活以允许最优技术方案。

这是我通过惨痛教训学到的——如果你太模糊，AI 就无法有效地帮助你。但如果你太具体，你可能会错过更好的实现方法。

### 阶段 2：计划 - 确定"怎么做"

计划阶段解决的问题是："我们将如何构建它？"这是做出技术决策和确定架构边界的地方。

**关键组件：**

- **技术栈**：语言、框架、数据库和工具的选择
- **架构设计**：系统架构、组件交互和数据流
- **数据模型**：数据库模式、API 合约和数据结构
- **非技术需求**：性能目标、安全标准、可扩展性要求
- **实现约束**：特定的技术限制或要求（例如，"使用 MongoDB 进行持久化"或"所有 API 端点都需要认证"）

**关键原则**：计划阶段提供了实现将在其中进行的技术护栏，确保与架构标准的一致性和对齐。

这是你真正发光发热的地方——你做出的技术决策同时指导着人类开发者和 AI 智能体。

### 阶段 3：实现 - 构建解决方案

实现阶段是将规范和计划转化为可工作的代码。SDD 的一个关键原则是以小的、经过验证的增量工作，而不是一次性实现整个规范。

**关键原则：**

- **任务分解**：将规范分解为小的、可操作的任务，每个任务交付一个可测试的功能片段
- **增量交付**：以一口大小的块来实现功能，每个块都可以单独验证
- **检查点验证**：启用频繁的检查点，供人类验证代码与规范的一致性
- **进度跟踪**：保持对已完成和剩余工作的可见性

**关键原则**：将工作分解为小的、可测试的增量，可以早期获得反馈并进行路线修正，降低构建错误内容的风险。

这在与 AI 合作时尤其重要——你需要定期验证输出，以便及早发现问题。

### 阶段 4：验证 - 确保一致性

验证阶段确认实现与规范匹配并满足所有验收标准。

**关键组件：**

- **自动化测试**：从规范派生的测试，验证预期行为
- **人工审查**：人工验证实现满足业务需求
- **差距分析**：识别规范与代码之间的差异
- **决策制定**：确定差距应在代码中修复还是在规范中修订

**关键原则**：当验证揭示差距时，团队面临一个明确的决策：如果代码不符合规范就修复代码，如果规范不完整或不准确就修改规范。有趣的是，一旦有了可靠的规范，氛围编程在解决实现问题时就会变得高效得多，因为上下文已经建立完善。

这就是我发现 SDD 真正力量的地方——它并没有消除对 AI 辅助的需求，但它使这种辅助更加可靠和高效。

## 4、SpecKit 用于 SDD 工作流的具体实现

GitHub SpecKit 提供了 SDD 原则的实践实现，与 GitHub Copilot 无缝集成，创建了一个强大的开发工作流。让我们探讨 SpecKit 如何将理论上的 SDD 工作流实际落地。

### 4.1 SpecKit 架构

SpecKit 由几个关键组件组成，它们协同工作以实现 SDD。让我为你逐一分解：

**1\. 命令和智能体**

- 存储在 `.github` 目录中的自定义编码智能体
- 每个命令对应 SDD 工作流的一个阶段
- 智能体利用 GitHub Copilot 的能力进行代码生成和分析

**2\. 模板和辅助脚本**

- 位于 `.specify` 目录中
- 五个核心脚本，自动化工作流的不同方面：
- `check-prerequisites`：验证所有必要文档是否存在
- `common`：共享工具和函数
- `create-new-feature`：初始化功能分支和规范文件
- `setup-plan`：准备计划阶段的工件
- `update-agent-context`：维护 AI 智能体的上下文

以下是 SpecKit 的目录结构：

```
├───.github
│   └───prompts
│           plan.prompt.md
│           specify.prompt.md
│           tasks.prompt.md
│   └───agents
│           plan.agent.md
│           specify.agent.md
│           tasks.agent.md
│
└───.specify
    ├───memory
    │       constitution.md
    ├───scripts
    │   └───powershell
    │           check-task-prerequisites.ps1
    │           common.ps1
    │           create-new-feature.ps1
    │           setup-plan.ps1
    │           update-agent-context.ps1
    │
    └───templates
            agent-file-template.md
            plan-template.md
            spec-template.md
            tasks-template.md

```

很有条理的结构，对吧？一切都有其位置，使得理解和维护变得容易。

### 4.2 SpecKit 命令工作流

让我们逐一详细了解每个命令。我将分享从使用它们中学到的经验。

#### 1\. 宪法命令

`constitution` 命令确立了开发过程的基本原则和约束。可以把它看作是为你的项目设定基本规则。

**功能：**

- 创建 `.specify/memory/constitution.md`
- 定义核心原则（例如，Library-First、CLI Interface、Test-First）
- 确立约束、安全要求和性能标准
- 设置治理规则和修订流程

**关键章节：**

- **核心原则**：5 条以上的基本开发原则及详细描述
- **附加要求**：安全、性能、工作流和合规标准
- **治理**：宪法如何执行和更新
- **版本控制**：版本控制和批准信息

以下是宪法在实际中的样子：

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-rZ0PqXf-QHyoA0iJCwnTBw.png)

我发现这特别有用，因为它确保了整个项目的一致性，无论谁或什么在进行实现。

#### 2\. 规范命令

`spec` 命令实现了 SDD 的"规范"阶段，回答了"做什么"的问题。

**功能：**

- 执行 `create-new-feature` 脚本
- 创建功能分支并初始化规范文件
- 在 `specs/branch-name/` 目录中生成结构化文档

**生成的文件：**

- `specs/branch-name/checklists/requirements.md`：详细的需求检查清单
- `specs/branch-name/spec.md`：主要规范文档

**工作流：**

1. 开发者启动一个新功能
2. 脚本创建适当的目录结构
3. 模板填充项目特定上下文
4. 规范文档就绪，等待优化

这就是你精确定义需要构建什么的地方，而不涉及实现细节。以下是规范文档的样子：

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-ezbLicINLycZz9IvKJ9iEg.png)

#### 3\. 计划命令

`plan` 命令实现了"计划"阶段，处理技术实现细节。

**功能：**

- 执行 `setup-plan` 和 `output-agent-content` 脚本
- 生成全面的计划文档
- 创建 GitHub Copilot 特定的指令

**生成的文件：**

- `plan.md`：总体实现计划
- `research.md`：技术选项调研
- `data-model.md`：数据库模式和数据结构
- `contracts.md`：API 合约和接口
- `quickstart.md`：入门指南
- `copilot-instructions.md`：给 GitHub Copilot 智能体的特定指令

**工作流：**

1. 加载 spec.md 和 constitution.md 作为上下文
2. 执行阶段 0（调研）
3. 执行阶段 1（设计）
4. 运行 `update-agent-context` 以维护 AI 上下文
5. 完成包含所有文档的计划工作流

计划模板如下：

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-fER-bXTYA6OINld-tXClkw.png)

而实际生成的 plan.md 是这样的：

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-HPDRFHW-qb5p59Dymn1S5w.png)

我喜欢它能自动创建全面的文档，指导人类开发者和 AI 智能体完成实现过程。

#### 4\. 任务命令

`tasks` 命令将计划分解为可操作、可测试的增量。

**功能：**

- 执行 `check-prerequisites` 脚本以验证准备就绪
- 验证所有必要文档是否存在（规范、计划、数据模型等）
- 生成任务分解

**生成的文件：**

- `specs/branch-name/tasks.md`：带有跟踪功能的详细任务列表

**任务特征：**

- 可操作：每个任务可以清晰地定义和执行
- 可测试：完成情况可以验证
- 独立：任务可以在可能的情况下并行处理
- 基于阶段：按开发阶段组织
- 有时限：有完成时间预估

以下是任务分解的样子：

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-CvOS861gZHeth7ILiObWaQ.png)

这就是真刀真枪的地方——将计划分解为具体的、可操作的步骤。

#### 5\. 实现命令

`implement` 命令通过生成实际代码将规范变为现实。

**功能：**

- 执行各种命令（git 操作、代码生成等）
- 利用 GitHub Copilot 进行代码生成
- 更新任务跟踪

**生成的工件：**

- 项目源代码
- 已更新的 `tasks.md`，标记已完成项目

**工作流：**

1. 按顺序或并行处理任务列表
2. 使用 GitHub Copilot 基于规范生成代码
3. 执行 git 操作进行版本控制
4. 更新进度跟踪
5. 提供已完成和剩余工作的状态

**关键原则**：基于阶段或任务逐步实现代码。避免一次生成整个项目。

这是我通过惨痛教训学到的——一次生成太多代码会使审查和验证变得困难。最好是小增量地工作。

最终基于 SDD 工作流构建的应用如下：

![None](https://www.hubwiz.com/blog/content/images/2026/05/1-j5OL0ZtRTvrQiKPHBAPcGA.png)

### 4.3 实用实现技巧

根据我使用 SpecKit 的经验，以下是一些关键见解：

1. **从熟悉的项目开始**：从一个你了解的项目开始——你既了解业务需求也了解代码实现。这使你能够有效地验证 SpecKit 的输出。
2. **参考官方示例**：从头开始跟踪 GitHub 的官方项目，以理解 SDD 方法和 SpecKit 的运行原理。这确实帮助我快速上手。
3. **人在回路中**：不要绝对信任 AI。在关键步骤中，人工干预和手动验证是必要的，以逐步建立对工具的信心。这在刚开始时尤其重要。

## 5、结束语

规范驱动开发代表了软件开发方法论的一次重大演进，特别适合 AI 辅助编程的时代。GitHub SpecKit 提供了一个实用的、可实现的框架来应用 SDD 原则，与 GitHub Copilot 无缝集成，创建了一个强大的开发工作流。

通过从氛围编程的非正式性转向 SDD 的结构化方法，团队可以实现：

- **更高质量的代码**：清晰的规范带来更好的 AI 生成代码
- **更好的可维护性**：活文档随代码库一起演进
- **改进的协作**：所有利益相关者的共同语言
- **可扩展的流程**：方法从原型到生产系统都适用
- **AI 优化**：结构良好的上下文带来更好的 AI 智能体性能

随着 AI 继续改变软件开发，像 SDD 这样提供结构和清晰度的方法论将变得越来越重要。GitHub SpecKit 提供了一条实用的前进道路，让团队能够在拥抱 AI 驱动的开发的同时，保持成功软件项目所必需的纪律和质量标准。

---

原文链接: [Exploring Spec Driven Development (SDD)- A Practical Guide with GitHub SpecKit and Copilot](https://levelup.gitconnected.com/exploring-spec-driven-development-sdd-a-practical-guide-with-github-speckit-and-copilot-72fd9a70535a?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处

> **这是「AI 编程 / Vibe Coding」专题的一部分。**完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/)