03 第一篇 · 先搞懂：为什么、是什么、选什么

SDD 方案全景

上一章给出了 SDD 的共通骨架：写清规格，制定计划，实现，再对照规格验证。真正选工具时，只知道这条骨架还不够。同样叫 SDD，有的只是放进仓库的一组文件和命令，有的会接管流程状态，还有的把规格当成生成代码的主要入口。

这一章不急着给方案排名。先看它以什么形态接入，再看它怎样推动流程。下一章才用统一标准比较它们的把关能力。

3.1 按形态分类

方案可以先按”装在哪里”分。同一个方案可能同时具备多种形态。

仓库内工具把规格、计划和任务文件放进项目，再通过命令或技能操作这些文件。spec-kit 和 OpenSpec 都以这种方式工作，差别在于产物组织和变更流程。spec-kit 目前还提供扩展、预设和自定义工作流，已经不只是”几份模板加几个命令”。

技能、插件和 MCP server 依附于现有的编码 agent。Superpowers 提供一组开发技能；Conductor 以 agent 插件运行；spec-workflow-mcp 则通过 MCP 提供规格流程，并配有看板和编辑器扩展。

独立环境或平台把 SDD 做进产品本身。Kiro 在 IDE、CLI 和 Web 等入口使用同一套 agent 能力；Tessl 把规格放在更靠近源码的位置。这类方案通常整合得更深，迁移时也更依赖产品提供的能力。

3.2 按约束强弱分类

另一个维度是”流程由谁推动”，从靠约定到靠代码强制。

较轻的方案主要靠文件结构和提示词约定。它们容易修改，但 agent 是否遵守流程，仍取决于当次执行。

再往前一步，技能或命令会组织阶段、维护产物，并在实现前后触发检查。这里要区分”流程写在说明里”和”运行时真的会拦住”：名字叫工作流，不代表每一步都由程序强制。

约束更强的方案把路由、状态转换或审批门交给确定性代码。AI-DLC 就采用这种结构：引擎决定下一步和可用路径，agent 负责完成当前阶段的判断与产物。是否需要这种强度，要看任务风险和团队对留痕、审批的要求。

3.3 代表方案一览

下表只选能说明差异的代表，不是完整名录。方案能力变化很快，表中事实以章末官方资料为准。

方案接入形态本章关注的特点
spec-kit仓库内工具，可扩展把规格继续展开为计划、任务、实现与收敛检查；支持扩展、预设和自定义工作流
OpenSpec仓库内工具每次变更有自己的提案、规格、设计和任务；产物可随时修改，没有固定的阶段门
BMAD技能或插件形式的完整方法清楚的小改动可以直接进入实现，较大的工作再增加产品、架构和测试环节
AI-DLC方法论、引擎和 harness确定性引擎管理阶段路由、状态和审批；不同任务可以选择不同流程范围
Kiro集成式开发环境规格流程生成需求、设计和任务；同一套 agent 能力覆盖多个使用入口
Tessl规格平台归为 spec-as-source：人主要修改规格，由系统生成代码
Superpowers技能库和开发方法从需求讨论进入计划、测试驱动实现与评审；既能派发新子 agent，也能在当前会话执行
spec-workflow-mcpMCP server通过 MCP 暴露规格工作流，并提供实时看板和编辑器扩展
Conductoragent 插件在仓库中维护上下文、规格和计划，并提供实现、评审与回退流程

这张表只回答”它是什么”。一个方案是否值得采用，不取决于功能多少，还要看它能否防住前文所说的翻车。

3.4 完整框架的适用边界

在一则公开社区讨论中，有参与者认为，个人项目不值得引入完整框架，自己保留简短的规格和执行命令已经够用；也有人认为，多人项目使用 SDD 能减少反复解释和返工。这些是使用者意见，不是效果研究。

BMAD 经常出现在”流程太重”的讨论里，但当前官方方法也为清楚的小改动提供了直接实现路径。把一个方案固定地称为”重”并不准确，还要看实际启用了哪些步骤、审批和附加模块。

沿用上一章的判断：意图清楚、容易回退、影响范围小的任务，可以不用完整框架；不确定性、改动风险或协作成本上升时，再增加规格、计划和验证。需要审计留痕或强制审批时，才进一步考虑带运行时约束的方案。

本章小结

SDD 方案共享大致相同的开发骨架，接入位置和约束方式却不一样。先弄清工具装在哪里、流程由谁推动，再谈轻重和选型。功能列表只能帮助定位，不能代替能力验证。

参考与出处