GitHub 最新提出的 规范驱动开发 (Specification-Driven Development, SDD) 核心思想，一场由 AI 驱动的软件开发革命。

这篇文章它详细阐述了 SDD 如何通过 /specify, /plan, /tasks 等命令，将开发工作流的效率提升到全新维度，把开发者从“人肉翻译机”的角色中解放出来。

文章来源：驱动规范开发（SDD）

---

权力的反转

几十年来，代码为王。

规范始终为代码服务——它们如同我们搭建好、一旦“真正的”编码工作开始便被抛弃的脚手架。我们撰写产品需求文档（PRD）以指导开发，创建设计文档以阐明实现，绘制架构图以实现可视化。但所有这些，终究都从属于代码本身。

代码即真理，其余的一切充其量只是美好的愿望。代码是事实的唯一来源，随着它的演进，规范文档很少能跟上步伐。由于资产（代码）与实现合二为一，我们很难在不依赖代码本身的情况下，去构建一个平行的实现。

规范驱动开发（SDD）彻底颠覆了这种权力结构。

在这里，规范不再服务于代码，而是代码服务于规范。产品需求文档（PRD）不再是实现的指南，而是生成实现的源头。技术方案不再是指导编码的文档，而是产出代码的精确定义。这并非对软件构建方式的渐进式改良，而是对开发驱动力的根本性反思。

从软件诞生之初，规范与实现之间的鸿沟就一直困扰着我们。我们试图通过更完善的文档、更详尽的需求、更严格的流程来弥合它。但这些方法都失败了，因为它们都默认了鸿沟的存在是必然的，只是试图去缩小它，却从未想过消除它。

SDD 则通过让规范及其具体的实现计划变得“可执行”，从而彻底消除了这条鸿沟。 当规范和实现计划能够直接生成代码时，鸿沟便不复存在——剩下的，唯有“转换”。

这场变革之所以在当下成为可能，是因为人工智能（AI）已能理解并实现复杂的规范，并创建出详尽的实现计划。然而，缺乏结构引导的原始 AI 生成只会带来混乱。SDD 正是通过那些足够精确、完整且无歧义的规范及后续的实现计划，为 AI 提供了生成可用系统所需的结构。

规范成为了最核心的产物，而代码则降级为它（通过实现计划）在特定语言和框架下的具体“表达形式”。

在这个新世界里：

• 软件维护意味着演进规范。
• 开发团队的意图通过自然语言（“意图驱动开发”）、设计资产、核心原则和其他指南来表达。
• 开发的通用语言 (lingua franca) 提升到了一个更高的维度，代码成了“最后一公里”的落地方式。
• 调试意味着修复那些生成了错误代码的规范及其实现计划。
• 重构则意味着为了更清晰地表达意图而重组规范。

整个开发工作流都围绕着“规范”这个唯一的真相来源重新组织，而实现计划和代码则成了不断被重新生成的输出。无论是为应用添加新功能，还是因为迸发的创意要构建一个全新的平行实现，都意味着我们只需回到规范，创建新的实现计划。因此，这个过程是 0 -> 1, (1’, …), 2, 3, … N。

开发团队从而可以将精力真正聚焦于他们的创造力、实验精神和批判性思维上。

SDD 的实战工作流

工作流始于一个想法——通常是模糊且不完整的。通过与 AI 的迭代对话，这个想法逐渐演变成一份全面的 PRD。AI 会提出澄清性问题，识别边缘情况，并帮助定义精确的验收标准。在传统开发中可能需要数天会议和文档工作的任务，在 SDD 中只需数小时专注的规范工作即可完成。

这改变了传统的软件开发生命周期（SDLC）——需求和设计不再是离散的阶段，而是贯穿始终的持续性活动。这也为团队协作提供了支持，团队评审过的规范可以被表达、版本化、创建分支和合并。

当产品经理更新验收标准时，实现计划会自动标记出受影响的技术决策。当架构师发现一个更优的模式时，PRD 也会随之更新以反映新的可能性。

在整个规范制定过程中，研究代理（research agents）会收集关键的上下文信息。它们会调查库的兼容性、性能基准和安全影响。组织的内部约束也会被自动发现并应用——例如公司的数据库标准、身份验证要求和部署策略，都会无缝集成到每一份规范中。

基于 PRD，AI 会生成实现计划，将需求映射到技术决策上。每一个技术选型都有文档化的理由，每一个架构决策都能追溯到具体的需求。在此过程中，持续的一致性验证不断提升质量。AI 会分析规范中的模糊之处、矛盾和缺漏——这不是一次性的门禁检查，而是一个持续的优化过程。

代码生成始于规范及其实现计划足够稳定之时，但它们无需“完全定稿”。早期的生成可能是探索性的——用于测试规范在实践中是否合理。领域概念化为数据模型，用户故事化为 API 端点，验收场景则化为测试用例。这通过规范将开发与测试融为一体——测试场景不再是代码写完后才编写，它们本身就是那份既能生成实现、又能生成测试的规范的一部分。

反馈闭环甚至延伸到了初始开发之后。生产环境的指标和事故不仅触发紧急修复，更会反过来更新规范，用于下一次的重新生成。性能瓶颈会成为新的非功能性需求，安全漏洞则会成为影响未来所有生成的约束。

这种在规范、实现和运维现实之间的迭代之舞，才是真正理解浮现的地方，也是传统 SDLC 演变为持续进化的关键。

为何 SDD 在当下至关重要？

三大趋势使得 SDD 不仅成为可能，更成为必需：

1. AI 能力的跃迁：AI 的能力已达到一个临界点，可以根据自然语言规范可靠地生成可工作的代码。这并非要取代开发者，而是通过自动化从规范到实现的机械性翻译工作，来极大地增强他们的效能。它能放大探索与创造力，让“从头再来”变得轻而易举，并为增删和批判性思维提供支持。

2. 软件复杂度的指数级增长：现代系统集成了数十个服务、框架和依赖。通过手动流程来保持所有这些组件与最初的设计意图保持一致，正变得日益困难。SDD 通过规范驱动的生成方式，提供了系统性的对齐机制。未来的框架可能会演变为优先支持 AI 而非人类，或者围绕可复用组件进行架构。

3. 变化速度的加快：如今，需求变化的速度远超以往。业务转向（Pivot）不再是例外，而已是常态。现代产品开发要求基于用户反馈、市场状况和竞争压力进行快速迭代。传统开发将这些变化视为干扰。每一次转向都需要手动将变更传播到文档、设计和代码中。其结果要么是缓慢谨慎的更新限制了速度，要么是鲁莽快速的变更积累了技术债。

SDD 甚至可以支持“假设/模拟”实验：“如果我们为了促进 T 恤销量这一商业需求，需要重新实现或改变应用，我们该如何实施并进行实验？”

SDD 将需求变更从障碍转化为了正常的工作流。当规范驱动实现时，业务转向就变成了系统性的重新生成，而非手动重写。在 PRD 中修改一个核心需求，受影响的实现计划会自动更新。修改一个用户故事，相应的 API 端点会重新生成。这不仅仅关乎初始开发，更关乎在不可避免的变化中保持工程速度。

核心原则

• 规范即通用语言 (Lingua Franca)：规范成为最核心的产物，代码则降级为其在特定语言和框架下的表达形式。维护软件即是演进规范。
• 可执行的规范：规范必须足够精确、完整且无歧义，足以生成可工作的系统。这消除了意图与实现之间的鸿沟。
• 持续优化：一致性验证是持续进行的，而非一次性的门禁检查。AI 会作为一个不间断的流程，分析规范中的模糊、矛盾和缺漏。
• 研究驱动的上下文：在规范制定的全过程中，研究代理会收集关键的上下文信息，调查技术选项、性能影响和组织约束。
• 双向反馈：生产环境的现实反哺规范的演进。性能指标、事故和运维经验都成为优化规范的输入。
• 分支用于探索：从同一份规范生成多种实现方法，以探索不同的优化目标——例如性能、可维护性、用户体验或成本。

实现方法

在今天，实践 SDD 需要整合现有工具并在整个过程中保持纪律。该方法可以通过以下方式实践：

• 使用 AI 助手进行迭代式的规范开发。
• 使用研究代理收集技术上下文。
• 使用代码生成工具将规范翻译为实现。
• 改造版本控制系统以适应规范优先的工作流。
• 通过 AI 对规范文档的分析进行一致性检查。

关键在于，始终将规范视为唯一的真相来源，而代码则是服务于规范、由规范所生成的输出，而不是反过来。

通过命令简化 SDD 流程

通过三个强大的命令，SDD 方法论将“规范 → 计划 → 任务”的工作流自动化，从而得到显著增强：

/specify 命令

此命令将一个简单的功能描述（用户提示）转换为一个完整的、结构化的规范，并自动管理代码仓库：

1. 自动功能编号：扫描现有规范以确定下一个功能编号（例如 001, 002, 003）。
2. 创建分支：根据你的描述生成一个语义化的分支名称，并自动创建它。
3. 基于模板生成：复制并根据你的需求定制功能规范模板。
4. 创建目录结构：为所有相关文档创建正确的 specs/[branch-name]/ 结构。

/plan 命令

一旦功能规范存在，此命令会创建一个全面的实现计划：

1. 规范分析：读取并理解功能需求、用户故事和验收标准。
2. 章程合规性：确保计划符合项目章程和架构原则。
3. 技术翻译：将业务需求转换为技术架构和实现细节。
4. 详尽文档生成：为数据模型、API 契约和测试场景生成支持性文档。
5. 快速启动验证：生成一份包含关键验证场景的快速启动指南。

/tasks 命令

计划创建后，此命令会分析计划及相关的设计文档，以生成一个可执行的任务列表：

1. 输入：读取 plan.md（必需），以及（如果存在）data-model.md、contracts/ 和 research.md。
2. 任务派生：将契约、实体和场景转换为具体的任务。
3. 并行化：标记出可以独立执行的任务 [P]，并规划出可以安全并行的任务组。
4. 输出：在功能目录下写入 tasks.md，准备好交由任务代理（Task agent）执行。

示例：构建一个聊天功能

看看这些命令如何改变传统的开发工作流：

传统方法：

1. 编写 PRD 文档 (2-3 小时)
2. 创建设计文档 (2-3 小时)
3. 手动设置项目结构 (30 分钟)
4. 编写技术规范 (3-4 小时)
5. 创建测试计划 (2 小时)
总计：约 12 小时的文档工作

使用 SDD 命令的方法：

# 步骤 1: 创建功能规范 (5 分钟)
/specify 一个带消息历史和用户在线状态的实时聊天系统

# 这会自动：
# - 创建分支 "003-chat-system"
# - 生成 specs/003-chat-system/spec.md
# - 用结构化的需求填充该文件

# 步骤 2: 生成实现计划 (5 分钟)
/plan 使用 WebSocket 实现实时消息，PostgreSQL 存储历史，Redis 管理在线状态

# 步骤 3: 生成可执行任务 (5 分钟)
/tasks

# 这会自动创建：
# - specs/003-chat-system/plan.md
# - specs/003-chat-system/research.md (WebSocket 库的对比)
# - specs/003-chat-system/data-model.md (Message 和 User 的 schema)
# - specs/003-chat-system/contracts/ (WebSocket 事件, REST 端点)
# - specs/003-chat-system/quickstart.md (关键验证场景)
# - specs/003-chat-system/tasks.md (从计划派生出的任务列表)

在 15 分钟内，你便拥有了：

• 一份包含用户故事和验收标准的完整功能规范。
• 一份包含技术选型和理由的详细实现计划。
• 可用于代码生成的数据模型和 API 契约。
• 覆盖自动化和手动测试的全面测试场景。
• 所有文档都在一个功能分支中得到了妥善的版本控制。

结构化自动化的力量

这些命令不仅节省时间，它们还强制保证了一致性和完整性：

1. 杜绝遗漏细节：模板确保了从非功能性需求到错误处理的每个方面都得到考虑。
2. 决策可追溯：每个技术选型都与具体的需求挂钩。
3. 鲜活的文档：规范与代码始终保持同步，因为代码由规范生成。
4. 快速迭代：在几分钟内修改需求并重新生成计划，而不是几天。

这些命令将规范从静态文档转变为可执行的产物，完美体现了 SDD 的原则。它们将规范制定过程从一种“必要之恶”转变为开发的真正驱动力。

模板驱动质量：结构如何约束 LLM 以获得更优成果

这些命令的真正威力不仅在于自动化，更在于模板如何引导大语言模型（LLM）的行为，产出更高质量的规范。这些模板就像精密的提示词，以富有成效的方式约束着 LLM 的输出。

1. 防止过早陷入实现细节

功能规范模板明确指示：

- ✅ 关注用户需要什么 (WHAT) 以及为什么需要 (WHY)
- ❌ 避免讨论如何实现 (HOW) (不涉及技术栈、API、代码结构)

这种约束迫使 LLM 保持适当的抽象层次。当 LLM 可能本能地跳到“使用 React 和 Redux 实现”时，模板会将其拉回到“用户需要实时更新他们的数据”这个核心需求上。这种分离确保了即使实现技术发生变化，规范也能保持稳定。

2. 强制使用明确的不确定性标记

两个模板都强制要求使用 [需要澄清] 标记：

当根据用户提示创建此规范时：
1. **标记所有模糊之处**：使用 [需要澄清：具体问题]
2. **不要猜测**：如果提示中没有明确说明，就标记出来

这避免了 LLM 做出看似合理但可能错误的假设这一常见行为。例如，LLM 不会猜测“登录系统”就是使用邮箱/密码认证，而是必须将其标记为 [需要澄清：未指定认证方式 - 邮箱/密码、SSO、OAuth？]。

3. 通过清单进行结构化思考

模板中包含全面的清单，如同规范的“单元测试”：

### 需求完整性
- [ ] 不再有 [需要澄清] 标记
- [ ] 需求是可测试且无歧义的
- [ ] 成功标准是可衡量的

这些清单迫使 LLM 系统性地自我审查其输出，捕捉那些否则可能被忽略的缺漏。这就像是给了 LLM 一个质量保障框架。

4. 通过“门禁”实现章程合规

实现计划模板通过阶段性“门禁”来强制执行架构原则：

### 阶段 -1：预实现门禁
#### 简洁性门禁 (第七条款)
- [ ] 使用的项目是否 ≤ 3 个？
- [ ] 是否没有进行“未来规划式”的过度设计？
#### 反抽象门禁 (第八条款)
- [ ] 是否直接使用框架特性？
- [ ] 是否是单一的模型表示？

这些门禁防止了过度工程化，迫使 LLM 为任何增加的复杂性做出明确的辩护。如果一个门禁检查失败，LLM 必须在“复杂性追踪”部分记录原因，从而为架构决策建立问责制。

5. 分层管理细节

模板强制执行了合理的信息架构：

**重要提示**：此实现计划应保持高层级且易读。
任何代规格
都必须放置在相应的 `implementation-details/` 码示例、详细算法或冗长的技术文件中。

这防止了规范变成难以卒读的代码转储这一常见问题。LLM 学会了保持适当的细节层次，将复杂内容提取到单独的文件中，同时保持主文档的导航性。

6. 植入测试先行思维

实现模板强制执行测试先行开发：

### 文件创建顺序
1. 创建 `contracts/` 目录并定义 API 规范。
2. 按顺序创建测试文件：契约测试 → 集成测试 → 端到端测试 → 单元测试。
3. 创建源文件以使测试通过。

这种顺序约束确保了 LLM 在实现之前就思考可测试性和契约，从而产生更健壮、更可验证的规范。

7. 防止臆测性功能

模板明确不鼓励臆测：

- [ ] 没有臆测的或“可能需要”的功能
- [ ] 所有阶段都有明确的前置条件和交付物

这阻止了 LLM 添加那些会使实现复杂化的“锦上添花”的功能。每个功能都必须追溯到一个有明确验收标准的具体用户故事。

复合效应

这些约束共同作用，产出的规范具备以下特点：

• 完整：清单确保无所遗漏。
• 无歧义：强制澄清标记突出了不确定性。
• 可测试：测试先行思维融入流程。
• 可维护：适当的抽象层次和信息层级。
• 可实现：具有具体交付物的清晰阶段。

模板将 LLM 从一个富有创造力的作者，转变为一个纪律严明的规范工程师，将其能力引导到持续产出高质量、可执行的规范上，从而真正地驱动开发。

“宪法”基石：强制执行架构纪律

SDD 的核心是一部“宪法”——一套不可动摇的原则，用于指导规范如何转变为代码。这部宪法（memory/constitution.md）扮演着系统的架构 DNA，确保每一次生成的实现都保持一致性、简洁性和高质量。

开发的九大条款

宪法定义了九大条款，塑造了开发过程的方方面面：

第一条款：库优先原则

每个功能都必须以一个独立的库开始——没有例外。这从一开始就强制了模块化设计：

Specify 中的每个功能都必须以一个独立的库开始其生命周期。
任何功能都不得直接在应用代码中实现，除非它首先被抽象成一个可复用的库组件。

该原则确保规范生成的是模块化、可复用的代码，而非庞大的单体应用。当 LLM 生成实现计划时，它必须将功能构建为具有清晰边界和最少依赖的库。

第二条款：CLI 接口强制令

每个库都必须通过命令行接口（CLI）暴露其功能：

所有 CLI 接口必须：
- 接受文本作为输入（通过标准输入、参数或文件）
- 产生文本作为输出（通过标准输出）
- 支持 JSON 格式进行结构化数据交换

这强制了可观察性和可测试性。LLM 不能将功能隐藏在不透明的类内部——一切都必须可以通过基于文本的接口进行访问和验证。

第三条款：测试先行铁律

这是最具变革性的一条——没有测试，就没有代码：

**此条不容商议**：所有实现都必须遵循严格的测试驱动开发（TDD）。
在以下条件满足前，不得编写任何实现代码：
1. 单元测试已编写完成。
2. 测试已由用户验证和批准。
3. 测试已确认为失败状态（红灯阶段）。

这完全颠覆了传统的 AI 代码生成模式。LLM 不再是生成代码然后祈祷它能工作，而是必须首先生成定义行为的全面测试，获得批准，然后才生成实现代码。

第七和第八条款：简洁性与反抽象

这两条相辅相成，旨在对抗过度工程化：

第 7.3 节：最小化项目结构
- 初始实现最多包含 3 个项目。
- 增加项目需要有文档化的理由。

第 8.1 节：信任框架
- 直接使用框架的特性，而不是对其进行封装。

当 LLM 可能本能地创建复杂的抽象层时，这些条款迫使它为每一层复杂性提供正当理由。实现计划模板中的“阶段 -1 门禁”直接强制执行了这些原则。

第九条款：集成测试优先

优先进行真实世界的测试，而非孤立的单元测试：

测试必须使用真实环境：
- 优先使用真实数据库，而非模拟对象（mock）。
- 使用实际的服务实例，而非存根（stub）。
- 契约测试必须在实现之前完成。

这确保了生成的代码在实践中有效，而不仅仅是在理论上。

通过模板强制执行宪法

实现计划模板通过具体的检查点来实施这些条款：

### 阶段 -1：预实现门禁
#### 简洁性门禁 (第七条款)
- [ ] 使用的项目是否 ≤ 3 个？
- [ ] 是否没有进行“未来规划式”的过度设计？

#### 反抽象门禁 (第八条款)
- [ ] 是否直接使用框架特性？
- [ ] 是否是单一的模型表示？

#### 集成测试优先门禁 (第九条款)
- [ ] 契约是否已定义？
- [ ] 契约测试是否已编写？

这些门禁如同架构原则的“编译时检查”。LLM 必须通过这些门禁，或者在“复杂性追踪”部分记录下合理的例外情况，否则无法继续。

不可动摇原则的力量

宪法的力量在于其不可动摇性。虽然实现细节可以演变，但核心原则保持不变。这提供了：

1. 跨越时间的一致性：今天生成的代码与明年生成的代码遵循相同的原则。
2. 跨越模型的一致性：不同的 AI 模型也能产出架构兼容的代码。
3. 架构的完整性：每个新功能都会加固而非破坏系统设计。
4. 质量的保证：测试先行、库优先和简洁性原则确保了代码的可维护性。

宪法的演进

虽然原则不可动摇，但其应用可以演进：

第 4.2 节：修订流程
对本宪法的修改需要：
- 明确记录变更的理由。
- 经过项目维护者的审查和批准。
- 进行向后兼容性评估。

这使得方法论在保持稳定性的同时，能够学习和改进。宪法本身通过带有日期的修订案展示了其演变过程，说明了原则如何根据真实世界的经验进行优化。

超越规则：一种开发哲学

宪法不仅仅是一本规则手册，它更是一种塑造 LLM 如何思考代码生成的哲学：

• 可观察性优于不透明性：一切都必须能通过 CLI 接口进行检视。
• 简洁性优于过度设计：从简单开始，仅在被证明必要时才增加复杂性。
• 集成优于隔离：在真实环境中测试，而非人造环境。
• 模块化优于单体化：每个功能都是一个具有清晰边界的库。

通过将这些原则嵌入到规范和计划流程中，SDD 确保了生成的代码不仅功能正确，而且可维护、可测试，并在架构上是健全的。宪法将 AI 从一个代码生成器，转变为一个尊重并强化系统设计原则的架构伙伴。

最终的变革

这一切，并非要取代开发者或将创造力自动化。

它的目的是通过自动化机械式的翻译工作，来极大地增强人类的能力。它是为了创建一个紧密的反馈闭环，让规范、研究和代码共同演进，每一次迭代都带来更深的理解，以及意图与实现之间更好的对齐。

软件开发需要更好的工具来维持意图与实现之间的一致性。SDD 通过“可执行的规范”——那些能够生成代码而非仅仅指导代码的规范——为实现这种一致性提供了方法论。