【工具】Spec 驱动开发解析
内容提要
SDD是一种以规范为核心的开发方法，先定义需求和验收标准，再让AI和人类严格按规范实现。它分为规范先行、规范锚定和规范即源三个层次，强调接口优先、验收前置和可追溯性。工具如BMAD、OpenSpec和Spec-Kit各有适用场景，适合大型系统，但小项目可简化。SDD能提升代码一致性，减少返工。
延伸解读
SDD 的三个层次：从指导到替代
文章将 SDD 实践分为三个层次：规范先行（Spec-first）、规范锚定（Spec-anchored）和规范即源（Spec-as-source）。层次越高，AI 参与度和自动化程度越高，规范的角色也从指导实现逐步演变为替代源代码。理解这些层次有助于团队根据自身需求选择合适的工作方式，避免盲目追求最激进的形式。
工具选择：按场景匹配，避免堆叠
BMAD、OpenSpec 和 Spec-Kit 各有侧重：BMAD 适合大版本规划和架构升级，OpenSpec 适合小步快跑的迭代和接口新增，Spec-Kit 适合新项目或大功能的结构化设计。文章建议按阶段选择 1-2 个核心工具，并明确交接点，避免同时使用多个工具导致流程过重和团队疲劳。
落地误区与纠正：规范要可验证、可同步
文章列举了常见误区，如规范写成备忘录、粒度失衡、规范与代码不同步、只写需求不写约束等。纠正方法包括：每条需求至少列一个 WHEN/THEN 场景，以可独立验收的接口或用户旅程为粒度，将归档/更新 spec 作为发布前必做检查，显式写出非目标和约束。这些建议有助于提升 SDD 的实际效果。
Q&A
什么是规范驱动开发（SDD）？
规范驱动开发（Specification-Driven Development，SDD）是一种以规范为核心的开发方法，要求先写清楚要做什么和验收标准，再让人和AI严格按规范实现，将文档提升为一等公民。它强调规范是唯一事实源，接口优先，验收前置，并确保可追溯性。
SDD的三个层次是什么？
SDD的三个层次是：Spec-first（规范先行）、Spec-anchored（规范锚定）和Spec-as-source（规范即源）。规范先行以撰写规范为起点，指导实现；规范锚定在后续维护中持续保持代码与规范的双向关联；规范即源则直接编辑规范，由AI自动生成代码，规范取代源代码成为开发核心。
SDD与TDD、BDD有什么关系？
SDD与TDD、BDD可以组合使用。TDD用代码层测试断言描述行为，SDD在更高层写文档和接口定义；BDD偏用户视角场景，SDD可嵌入BDD场景格式，但更全面覆盖从需求到实现。
SDD适合哪些场景？
SDD适合多团队并行协作、大型系统、跨模块改造、大功能开发、API/平台型项目（需提前Mock/定义）、从零构建时需要骨架/共识的场景，以及需要审计/知识沉淀/可回溯过程的系统。
SDD有哪些局限性？
SDD不适用于脚本、小改动、快速验证原型和模糊探索期（只记录关键约束即可）。此外，SDD面临术语不统一、AI服从性不足等挑战，需要解决规范语义统一、AI规范服从性和自动一致性验证等问题。
BMAD、OpenSpec和Spec-Kit这三种工具分别适合什么场景？
BMAD适合0→1、重构、架构升级等大版本，流程重、全周期；OpenSpec适合维护、接口新增等小步快跑的增量迭代，流程轻、线性；Spec-Kit适合新项目规划、大功能设计，提供结构化七步流程，强调一致性。
如何组合使用BMAD、OpenSpec和Spec-Kit？
建议组合方式：Spec-Kit立骨架+OpenSpec管迭代，前期用Spec-Kit输出规范，后续用OpenSpec管理变更；BMAD做大版本+OpenSpec做小步，大版本用BMAD规划，日常维护用OpenSpec。也可借鉴而不堆叠，如用BMAD时吸收Spec-Kit的Clarify/Analyze，用Spec-Kit时用OpenSpec的归档保持同步。
SDD落地时有哪些常见误区？
常见误区包括：规范写成备忘录缺少验收场景；粒度失衡（太大或太碎）；规范与代码不同步；只写需求不写约束/非目标；工具堆叠、流程过重。纠正方法：每条需求至少列一个WHEN/THEN场景；以可独立验收的接口/用户旅程为粒度；将归档/更新spec作为发布前必做检查；显式写非目标和约束；按阶段选1-2个核心工具。
SDD的快速流程是怎样的？
SDD的快速流程（30分钟上手）包括：写目标与接口草稿、边界/约束；补疑点与非目标；拆出任务，附验收条件；实施与对齐；回写规范，归档成正式文档。
