什么是规范驱动开发 (Spec-Driven Development, SDD)

规范驱动开发（SDD）是一种专门为 AI 辅助编程（AI-Native Engineering） 打造的软件开发方法论。在传统的开发中，人类开发者直接编写代码；而在 SDD 模式下，人类的角色转变为“系统架构师”和“产品经理”，主要负责编写和维护结构化的需求规范（Spec），然后由 AI 智能体（如 Claude Code）根据规范自动生成执行计划、拆解任务并最终编写和测试代码。

SDD 的核心理念是：规范（Spec）即唯一的真实数据源（Single Source of Truth）。 只要规范定义得足够清晰、边界足够明确，AI 就能高效、准确地交付高质量的代码，从而大幅减少 AI 的“幻觉”和代码返工。

beijing-dusk-in-north-garden

为什么需要 SDD？

随着 AI 编程能力的大幅提升，开发者发现让 AI 写几十行代码很容易，但让 AI 独立完成一个包含多文件的复杂需求却很容易“翻车”。SDD 主要解决以下痛点：

  1. 打破 AI 的上下文限制：通过结构化的文档（需求文档、架构文档、任务列表），让 AI 随时能找回上下文，避免“边写边忘”。
  2. 减少幻觉与返工：在写代码之前强制进行澄清（Clarify）、计划（Plan）和设计，确保 AI 完全理解需求。
  3. 流程可控与可追溯：每个阶段都有产出物（Artifacts），人类可以在关键节点（如确认计划、验收任务）进行介入和审查（Quality Gates）。

两大核心框架：Spec-Kit 与 OpenSpec

在 FORCE Lab 等先进的 AI 编程实践中，SDD 衍生出了两种主流的落地框架/工作流：Spec-Kit 和 OpenSpec。它们侧重点不同，适用于不同的开发场景。

1. Spec-Kit 工作流：聚焦于完整的特性开发

Spec-Kit 是一套标准化的规范驱动开发工具包，适合从零到一的复杂功能（Feature）开发。它像一个严格的项目经理，通过多道质量门禁（Quality Gates）确保开发质量。

Spec-Kit 的标准执行流：

  1. Constitution（项目宪章）：确认项目的全局原则（九大黄金原则、禁忌列表），确保 AI 不会破坏原有架构。
  2. Specify（需求定义）：将人类的自然语言描述转化为结构化的功能规范（spec.md）。
  3. Clarify（需求澄清）：AI 针对模糊点主动向人类提问，并将确认后的结果反写回规范中。
  4. Checklist（质量检查清单）：基于规范生成当前特性的专属质量检查清单。
  5. Plan（实现计划）：AI 探索代码库，生成系统设计和架构实现方案（plan.md）。
  6. Tasks（任务拆解）：将计划拆解为依赖关系明确、可独立执行的任务列表（tasks.md）。
  7. Analyze（一致性分析）：非破坏性地检查 spec.md、plan.md 和 tasks.md 之间的一致性，防止需求遗漏。
  8. Implement（代码实现）：自动按照 tasks.md 逐项推进，完成代码编写和测试。

适用场景：大型重构、开发一个完整的业务模块、前后端联调的复杂特性。

2. OpenSpec 工作流：聚焦于变更追溯与开源协作

OpenSpec 是一种受开源社区 RFC（请求意见稿）启发的 SDD 变体，适合增量修改、Bug 修复或需要高度审计追溯的变更。它的核心是让每一次代码改动都有迹可循。

OpenSpec 的标准执行流：

  1. Project-Init（项目初始化）：扫描代码库，生成或更新全局的架构和 AI 导航文档（如 AGENTS.md, ARCHITECTURE.md）。
  2. Proposal（变更提案）：针对某个 Bug 或小需求，编写变更提案（包含变更动机和影响范围）。
  3. Design（技术设计）：基于提案生成具体的技术修改设计。
  4. Review（质量审查）：对提案和设计进行技术和安全审查。
  5. Implement（执行变更）：AI 根据通过审查的设计，精细地修改代码。
  6. Archive（归档）：将完成的提案和变更日志归档，作为后续开发的上下文库。

适用场景：日常迭代、Bug 修复、开源项目的 PR 贡献、需要严格变更控制（Change Tracking）的工程环境。

3. Spec-Kit 与 OpenSpec 的深度对比

为了更直观地理解两者的区别，下面从几个核心维度对 Spec-Kit 和 OpenSpec 进行了对比：

对比维度 Spec-Kit OpenSpec
核心定位 自顶向下的系统工程（从需求到代码的完整拆解） 聚焦变更管理的审计流（RFC/工单驱动的增量修改）
驱动源头 需求规范文档 (spec.md + plan.md) 变更提案文档 (proposal.md -> design.md)
生命周期 长周期：从零开始构建、涉及大量探索、架构设计、多轮交互和验证 短周期：针对特定问题的修补、在现有框架上的局部增加
主要产出物 规范文档、测试清单、架构设计、任务列表 变更提案、修改设计图、代码补丁 (Patch/PR)、归档日志
控制侧重点 防偏离：防止 AI“放飞自我”，确保任务清单 100% 覆盖业务需求 防破坏：防止 AI 修改破坏存量代码，强调影响范围的限定和严格审查
适用场景举例 开发全新的“用户鉴权模块”或“支付流引擎”；重构底层框架 修复“登录页面的跨站脚本漏洞”；优化某个特定 API 的耗时；向开源库提交 PR

总结：如何选择？

  • 如果你要 “造一栋新房子” 或 “扩建一层楼”，请使用 Spec-Kit，它能帮你稳扎稳打地拆解工程、规避风险。
  • 如果你要 “给房子换个门锁” 或 “修补漏水的管道”，请使用 OpenSpec，它能帮你精准定位、安全修改并留下完整的维修记录。

无论是哪种框架，SDD 的终极目标都是一致的：用人类的系统性思维来驾驭 AI 的执行力，实现 开发效率提升。