5 款主流开源 SDD 框架深度体验与 PK

强大的 AI Coding 似乎无时无刻不在制造新的焦虑程序员、IDE、甚至软件工程都不再被需要“会说话就会开发软件”。这是极端且不负责任的。毕竟还有更多需要逻辑严密的商业软件系统。强如 OpenAI在使用Codex开发内部系统时依然耗时五个月。这再次证明再强大的 Agent也离不开Harness的驾驭。SDD规范驱动开发正是与 Harness 完美契合的核心流程约束机制。它通过规范的工作流、分阶段的校验、结构化的产物确保 Agent 在复杂的软件工程中不至于“脱缰”。本文为您深度解析社区最受关注的 5种主流开源 SDD 框架SpecKitBMADOpenSpecSuperpowersGSD (Get-Shit-Done)综合对比与建议01 快速回顾为什么需要 SDD 在探讨框架前我们先简单对齐下对SDD规范驱动开发的认知。这并非新概念但在 AI Coding 时代它被赋予了关键的工程学意义。核心理念从写代码到写契约传统开发以代码为核心产出。而 SDD 提倡“规范即代码”开发最重要的环节是定义严谨、结构化、人机均无歧义的规范。这不只是需求文档更是你与 Agent 之间的“契约”明确界定了系统的行为、接口与边界。核心价值为什么需要 SDD如果我们用一句话来形容 SDD 在 AI Coding 的价值用多步完成的确定性规范去收敛大模型生成代码时的不确定性。消除歧义AI 最怕模棱两可。SDD 将模糊的需求转化为结构化、可被 Agent 清晰理解的规范。细化任务复杂系统难以一次性生成。SDD 通过工作流将目标逐步拆解让 Agent 拥有清晰的阶段性任务与约束。自校验可验证优秀的规范自带验收标准便于 AI 依据规范进行自动化测试与修复形成闭环。你可能会问我没用 SDDAI Coding 也工作的好好的甚至经常有“惊喜”。一方面这取决于你的需求复杂度与验收标准另一方面你可能在无意中践行了类似 SDD 的逻辑比如非常精细化的 Context 工程。02 Spec Kit来自 GitHub 团队的 SDD 工具项目简介GitHub 仓库github/spec-kitGitHub 团队官方出品。截至2026年4月最新版本为0.5.0 。Stars 85k 社区活跃贡献者众多。Spec Kit 提供了一个端到端的 SDD 流程工具集。其主张的思想是在编码前先明确需求Specs和设计Plan、DataModels、API契约等然后再交给 AI 实现代码与测试而非一次性生成代码。典型工作流程Spec Kit 包括一系列 CLI 命令行工具以及 Coding Agent 的扩展技能/模板等支持几乎所有的 AI 编程工具。使用 uv 命令安装 Spec Kit 后在项目根目录下运行 specify init .该命令会启动向导在项目目录下安装 Spec Kit 工具集自定义的 Agent、技能、脚本、模板等供 Coding Agent 调用以 GitHub Copilot 为例不同版本会有区别你会在项目下看到安装内容接着在 Agent 对话窗口你可以通过/speckit.{command}启动开发。典型流程如下流程执行产出会放在特定目录下并会自动创建分支。比如此外它还提供/speckit.clarify澄清模糊需求、/speckit.analyze检查一致性等辅助指令确保每一步产出都严谨对齐。在标准流程之外Spec Kit 具有良好的扩展性与定制能力扩展Extensions支持通过社区扩展引入新功能如深度代码审查、与 DevOps 平台集成或 Ralph Loop 迭代范式。预设Presets允许企业自定义工作流和模板以强制执行特定组织标准或领域驱动设计DDD规范。优势/适用场景Spec Kit 是笔者使用的第一个 SDD 工具它的功能非常完善在官方文档中也有较为详细的 SDD 方法论它比较适合中大型开发团队与高合规性项目特别是对于开发过程、资产沉淀、代码测试都有较高QA要求的组织。可以确保开发过程可审计、可重现。Spec Kit 的社区活跃度高、文档与各种示例各种类型的前后端应用也较为丰富对开发者非常友好。不足/风险点对于小型创业团队、OPC一人公司或者流程要求较宽松的项目Spec Kit 流程稍显重量级引入了管理负担。另外Spec Kit 也不具有代码与规范的“双向同步”能力。03 BMADAI 驱动的企业级敏捷开发项目简介GitHub仓库bmad-code-org/BMAD-METHOD。BMAD 目前已迭代到6.2.x 版本截止2026年4月。Stars 43k 提交活跃Issue/PR数量适中。BMAD 是一个全生命周期的、多 Agent 的 AI 驱动敏捷开发框架着重模拟完整的敏捷开发流程强调结构化工作流与多角色协作从需求挖掘、规格定义、架构决策到实现与发布都有专门的 AI Agent 引导完成。典型工作流程BMAD 核心采用 TS 实现运行如下命令快速安装到工程目录下npx bmad-method installBMAD 内置一个基于敏捷开发方法论的完整工作流BMAD-Method。它通过四个不同的核心阶段 每个阶段的多条工作流来逐步细化规范从最开始捕获灵感到形成PRD再到用户故事与架构设计等 — 每个阶段会产生一个或多个产出物并为下个阶段提供信息输入。下图是 BMad Method 的工作流框架其中Mary是BMAD中不同角色默认名字框架中的每个动作会有对应的技能你可以通过斜杠命令来调用。当然这里的每个动作并非都是必须的你可以根据需要裁剪按需启用。比如如果你对产品的想法还不够清晰只有大概的灵感可以先来一轮头脑风暴bmad-brainstorming让 AI 来引导你激发创意捕获想法反之你可以直接从 product-brief 开始。BMAD 也提供了一种极简的开发流程以满足简单场景的需要借助 /bmad-quick-dev 工作流的三步走来快速完成系统开发。BMAD 工作流的主要特点有【交互式引导与 Bmad-help 】AI 不只是执行命令而是通过不断提问、建议与总结引导你发现设计遗漏。例如在头脑风暴后它能自动生成包含数十项核心决策的 Markdown 文档。笔者对一个模拟项目开启的头脑风暴结果在每个阶段结束后工作流会引导你下一步的动作你可以随时使用 /bmad-help 来让 AI 给你提示和引导。【Party Mode多 Agent 模式】通过/bmad-party-mode组织架构师、开发、UX 等多个角色进行“圆桌讨论”由 Master 协调达成共识从多元视角解决复杂问题。【Bmad-builder自定义模块】类似于 Spec Kit 的扩展插件允许用户构建专属的开发助手、文档专家或特定领域的创意设计师扩展 SDD 的能力边界。比如特殊的个人开发助手。比如开发日记、学习导师。具有特定职责的专业 Agent。比如代码审查、文档专家。创意助手。比如擅长某类应用如游戏的创意设计师。BMAD 提供了一些预置的扩展模块包括游戏开发工作室Game Dev Studio针对游戏开发领域模块与测试架构模块Test Architecture专注测试自动化与质量控制的模块。优势/适用场景BMAD 是一个企业级 SDD 敏捷开发的重量级框架提供了丰富的核心功能和周边生态。非常适合大型企业级项目与需要多角色协作、有清晰分工和严格流程的团队尤其是对过程规范和输出审查有高要求的团队如航天、金融等且具有较强的可扩展性。不足/风险点尽管BMAD功能强大使用体验非常友好但需要注意框架庞大且复杂且执行耗时较长。BMAD 的流程步骤多、命令繁琐对于小型项目会显得“杀鸡用牛刀”。BMAD 的使用门槛较高 否则可能无法最大化其威力 — 它会与你做很多细致的专业技术探讨以尽可能的细化规范。对企业而言迁移 BMAD 后会涉及大量的流程和文档会引入额外的人工成本需要谨慎规划。BMAD 目前对 AI Coding Agent 的支持还不够全面。04 OpenSpec适合快速迭代开发的轻量级工具项目简介GitHub 仓库Fission-AI/OpenSpec 网站openspec.dev。截至2026年4月OpenSpec 最新版本 1.2.x。项目活跃主分支有数百次提交提交频率高。目前约 37K Star 。OpenSpec 是一款轻量级 SDD 框架强调快速反馈与迭代式设计。它不强制要求从零开始构建而是主张在现有项目中引入 AI 辅助规范非常适合中小型企业项目或个人开发者。典型工作流程OpenSpec基于 NodeJS 构建使用如下命令完成 CLI 安装npm install -g fission-ai/openspeclatest完成后在工程目录下进行项目初始化:openspec init .该命令将会引导你选择开发工具几乎支持所有的 Coding Agent 和 IDE 并在项目中创建必要的技能与产出目录使用时开发者通过 Agent 对话发出类似 /opsx:propose 的斜杠命令OpenSpec 会自动判断当前所处的 Change 及状态开启后续任务。OpenSpec 框架支持两种工作流程经典工作流程或OPSX 流程。【经典工作流程】这是OpenSpec早期内置的工作流程不可自己定制硬编码特点是简单你只需要记住三个命令就可以完成整个工作这种 proposal - apply - archive 的线性工作流程在一些场景下灵活度略显不足。比如在 apply 前发现设计问题此时你需要重新从 proposal 开始。【OPSX 工作流程】这是 OpenSpec 当前主推的标准流程支持更细致的工作环节和辅助技能。但首先需要开启扩展工作流openspec config profile成功配置后将会出现/opsx:new,/opsx:ff 等更多的命令。OPSX 工作流程主要环节如下与经典流程不一样的是这不是一个线性的顺序流程可以随时重新执行任何环节。你可以随时修改产出物模板立即测试而不用从头开始。通常一次执行只会有一个产出物适合精细化的流程控制。可以自定义工作流比如定义你的产出模板及其依赖关系。简单的说OPSX 工作流具有更大的灵活性、适用场景以及定制能力。优势/适用场景OpenSpec的最大特点是其设计初衷 — 为处理在现有项目/代码库上迭代更新的复杂情况。其他特点有相对于强制执行严格的阶段性流程如SpeckitOpenSpec 则允许随时更新任何组件。增量的Specs更新在修改现有功能时不会重新编写 Spec会使用如ADDED 这样的标记来描述。且每个Change会有独立空间不会相互干扰这对于频繁的需求变更场景非常适合。得益于轻量化与增量修改的设计OpenSpec 一次变更的输出与 Token 消耗相对于其他工具而言更小。几乎支持所有的 Coding Agent具有极佳的兼容性与可移植性。不足/风险点OpenSpec的不足主要表现在OpenSpec 也不支持 Spec 与代码的自动同步。相比 BMAD其生成的规范文档在广度与深度上略显单薄需要通过自定义模板与指令来弥补。OpenSpec 也不支持多 Agent 的编排与协作所以默认也不支持并行执行与上下文隔离需自行考虑变通方法来实现。05 Superpowers严格的自动化 SDD 工作流项目简介GitHub仓库 obra/superpowers 。Superpowers 目前版本5.x。GitHub Stars 高达 130k 2026年4月是最受欢迎的 SDD 工具之一Issues 较少PR活跃度很高。Superpowers 目标是提供一个高度自动化、零配置的 SDD 开发工作流。它可以在启动 AI Coding 时自动介入无需手动运行诸如 init 的命令并引导用户从澄清需求开始到制定实现计划最后通过子 Agent 来执行每个任务并测试。典型工作流程Superpowers 最初是针对 Claude Code 而设计的插件现在扩展到对Codex、OpenCode、Gemini CLI、Github Copilot CLI的支持所以安装主要是通过开发工具的 Plugin 机制进行以Copilot CLI为例copilot plugin marketplace add obra/superpowers-marketplacecopilot plugin install superpowerssuperpowers-marketplace安装后可以通过 /plugin list 可以查看到superpowers的存在Superpowers 插件会带来14个 Skills通过 /skills 查看。现在你可以启动AI 开发流程。基础的 Superpowers开发流程是Superpowers 也提供了一些辅助技能比如启动并行编程创建git worktree创建 Skill 等。实际应用中Superpowers 的技能可以显式调用更可以自动唤起。比如将会唤起 brainstorming 技能并启动一个工作流 - 通过对话与你探讨需求与设计这里你可以看到 Superpowers 对于 Claude Code 这类高度自动化 AI Coding工具的最大意义它不允许 Agent “蒙头就干”最后再返工而是尝试把需求、设计、技术等各方面的规范尽可能细化后再让 Agent 来实现。表面上这似乎减慢了开发速度但却可以极大的提高一次性成功的概率。优势/适用场景相比于其他框架而言Superpowers 就像是一个严格的开发纪律监督者 — 会在适当的时候自动介入并强制遵循严格的工作流程以确保交付质量。基于上下文的自动触发。Superpowers 可以在不同的开发阶段自动触发。更严格的纪律性。要求开发者与 Agent 之间必须通过结构化的对话来明确需求与设计方案否则无法进入编码。测试驱动开发TDD。尽管其他框架也可以要求 TDD但 Superpowers有着更严格的执行措施。子 Agent 调度机制。默认采用子 Agent 执行任务来避免“上下文污染”。不足/风险点由于 Superpower 的“严格性”所以它可以帮助 Agent 产出非常稳定与高质量的代码。但带来的代价是其产出时间相对较长所以你需要决策如果采用传统流程后期的 Bug 修复、需求调整、设计偏差等问题导致的返工时间是否超过采用 Superpowers 前期把关所增加的时间此外Superpowers目前仍然依赖于特定的Coding Agent生态Claude Code、Cursor等对一些工具还不适配迁移成本高。另外由于其高度的自动化手工干预流程较难对于一些需要较多扩展与定制的场景可能不太适合。06 GSDGet Shit Done专注“上下文工程“的 SDD 工具集项目简介GitHub仓库gsd-build/get-shit-done。GSD 是新崛起的 SDD 框架。截至 2026 年4月GitHub Stars 达到48k。它在很多大型研发团队中颇受青睐被 Amazon、Google、Shopify 等企业工程师信任和使用社区演进十分活跃。GSD 的核心理念是用简洁高效的方式重点解决“上下文腐烂”问题随着会话变长 AI Agent 表现下降。它提供了一整套命令涵盖从项目启动到多阶段迭代的开发流程但又规避了BMAD、Speckit的很多繁琐的细节。相对来说GSD 更像是一个极度丰富的命令行工具集。典型工作流程使用如下命令快速安装 GSDnpx get-shit-done-cclatestGSD 将开发工作组织成清晰的层级 Project Milestone Phase 。对于每个阶段PhaseGSD 强制执行一个固定的多步循环初始化-讨论- 计划 - 执行- 验证。你可以通过专属的命令唤起对应阶段的 Agent 工作流/gsd:new-project/gsd:discuss-phase # 唤起讨论提炼需求并形成明确的 Spec/gsd:plan-phase # 制定技术计划与细粒度任务拆解/gsd:execute-phase # 并发执行子任务/gsd:verify-work # 验证、除错与测试产出如果是在现有的代码库上做增量开发可以先使用 /gsd-map-codebase 命令拉起多个 Agent 并行分析你的代码调查代码的技术栈、功能、架构等这样Agent 就可以在理解现有代码的基础上开始后续工作流程。优势/适用场景GSD的最大特点是基于“wave”的并行任务实现与对抗“上下文腐烂”的设计。高效并行执行GSD 将任务按依赖关系分组为不同的 Wave。同一 Wave 内的无依赖任务由子 Agent 并行处理Wave 之间则按序推进。这种机制使多文件、复杂模块的生成速度远超传统单 Agent 系统。对抗上下文腐烂GSD 为每个执行单元生成独立的子 Agent 上下文。这种“上下文隔离”确保每个任务都在干净、只加载相关产出的窗口中运行有效避免了长时开发中常见的代码质量下滑问题。不足/风险点上手门槛高尽管定位轻量但其实际命令多达数百条学习曲线较陡对小型团队可能存在功能过剩。Token 消耗较大由于为每个任务创建独立上下文部分通用背景信息需要反复传输导致 Token 成本上升。规划深度略显不足GSD 的优势集中在执行阶段其前期规划与规范定义的深度不及 BMAD可能引入一定的返工风险。环境兼容性差异优先适配 Claude Code 、Open Code 等主流工具部分高级命令在其他 AI Coding 环境下可能有兼容问题。07 综合对比与建议将以上五个框架进行综合比较团队/项目建议小型创业团队优先考虑 Superpowers 和 OpenSpec。它们可快速上手最大程度减少流程管理利于快速迭代和原型开发。中型产品团队Spec-kit 可作为首选因其平衡了流程规范与灵活性GSD 适用于已经准备好系统化流程的团队若项目偏实验性、对自动化要求高可选 Superpowers。OpenSpec 可作为辅助使用。大型企业级项目建议 Spec-kit 和 BMAD 放在首位它们支持复杂需求、审计和合规性要求。GSD 也可用于编排具体迭代。Superpowers 可作为生产力工具嵌入开发流程但不应用作唯一流程。新项目启动时Spec-kit 和 Superpowers 可帮助快速搭建规范遗留系统改造时OpenSpec 和 GSD更合适需高合规性项目建议采用 Spec-kit/BMAD配合额外审计