告别盲目 AI 编程：5 款主流开源 SDD 框架深度体验与 PK 。- 大数跨境

首页

告别盲目 AI 编程：5 款主流开源 SDD 框架深度体验与 PK 。

AI大模型应用实践

2026-04-07

导读：详细对比 5 款主流的开源 SDD 框架。

点击上方蓝字关注我们

强大的 AI Coding 似乎无时无刻不在制造新的焦虑：程序员、IDE、甚至软件工程都不再被需要，“会说话就会开发软件”。这是极端且不负责任的。毕竟，还有更多需要逻辑严密的商业软件系统。

强如 OpenAI，在使用Codex开发内部系统时依然耗时五个月。这再次证明：再强大的 Agent，也离不开 Harness 的驾驭。SDD（规范驱动开发），正是与 Harness 完美契合的核心流程约束机制。它通过规范的工作流、分阶段的校验、结构化的产物，确保 Agent 在复杂的软件工程中不至于“脱缰”。

本文为您深度解析社区最受关注的 5 种主流开源 SDD 框架：

SpecKit
BMAD
OpenSpec
Superpowers
GSD (Get-Shit-Done)
综合对比与建议

快速回顾：为什么需要 SDD ？

在探讨框架前，我们先简单对齐下对 SDD（规范驱动开发） 的认知。这并非新概念，但在 AI Coding 时代，它被赋予了关键的工程学意义。

核心理念：从写代码到写契约

传统开发以代码为核心产出。而 SDD 提倡“规范即代码”：开发最重要的环节是定义严谨、结构化、人机均无歧义的规范。这不只是需求文档，更是你与 Agent 之间的“契约”，明确界定了系统的行为、接口与边界。

核心价值：为什么需要 SDD？

如果我们用一句话来形容 SDD 在 AI Coding 的价值：

用多步完成的确定性规范，去收敛大模型生成代码时的不确定性。

消除歧义：AI 最怕模棱两可。SDD 将模糊的需求转化为结构化、可被 Agent 清晰理解的规范。
细化任务：复杂系统难以一次性生成。SDD 通过工作流将目标逐步拆解，让 Agent 拥有清晰的阶段性任务与约束。
自校验+可验证：优秀的规范自带验收标准，便于 AI 依据规范进行自动化测试与修复，形成闭环。

你可能会问：我没用 SDD，AI Coding 也工作的好好的，甚至经常有“惊喜”。一方面，这取决于你的需求复杂度与验收标准；另一方面，你可能在无意中践行了类似 SDD 的逻辑（比如非常精细化的 Context 工程）。

Spec Kit：

来自 GitHub 团队的 SDD 工具

项目简介

GitHub 仓库：github/spec-kit，GitHub 团队官方出品。

截至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 也不具有代码与规范的“双向同步”能力。

BMAD：

AI 驱动的企业级敏捷开发

项目简介

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 install

BMAD 内置一个基于敏捷开发方法论的完整工作流（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 的支持还不够全面。

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/openspec@latest

完成后在工程目录下进行项目初始化:

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的最大特点是其设计初衷 — 为处理在现有项目/代码库上迭代更新的复杂情况。其他特点有：

相对于强制执行严格的阶段性流程（如Speckit），OpenSpec 则允许随时更新任何组件。
增量的Specs更新：在修改现有功能时，不会重新编写 Spec，会使用如ADDED 这样的标记来描述。且每个Change会有独立空间，不会相互干扰，这对于频繁的需求变更场景非常适合。

得益于轻量化与增量修改的设计，OpenSpec 一次变更的输出与 Token 消耗，相对于其他工具而言更小。
几乎支持所有的 Coding Agent，具有极佳的兼容性与可移植性。

不足/风险点

OpenSpec的不足主要表现在：

OpenSpec 也不支持 Spec 与代码的自动同步。

相比 BMAD，其生成的规范文档在广度与深度上略显单薄，需要通过自定义模板与指令来弥补。

OpenSpec 也不支持多 Agent 的编排与协作，所以默认也不支持并行执行与上下文隔离，需自行考虑变通方法来实现。

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 superpowers@superpowers-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等），对一些工具还不适配，迁移成本高。

另外由于其高度的自动化，手工干预流程较难，对于一些需要较多扩展与定制的场景可能不太适合。

GSD（Get 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 更像是一个极度丰富的命令行工具集。

典型工作流程

使用如下命令快速安装 GSD：

npx get-shit-done-cc@latest

GSD 将开发工作组织成清晰的层级： Project > Milestone > Phase 。对于每个阶段（Phase），GSD 强制执行一个固定的多步循环：初始化->讨论-> 计划 -> 执行-> 验证。

你可以通过专属的命令唤起对应阶段的 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 环境下可能有兼容问题。

综合对比与建议

将以上五个框架进行综合比较：

团队/项目建议

小型创业团队：优先考虑 Superpowers 和 OpenSpec。它们可快速上手，最大程度减少流程管理，利于快速迭代和原型开发。

中型产品团队：Spec-kit 可作为首选，因其平衡了流程规范与灵活性；GSD 适用于已经准备好系统化流程的团队；若项目偏实验性、对自动化要求高可选 Superpowers。OpenSpec 可作为辅助使用。

大型企业级项目：建议 Spec-kit 和 BMAD 放在首位，它们支持复杂需求、审计和合规性要求。GSD 也可用于编排具体迭代。Superpowers 可作为生产力工具嵌入开发流程，但不应用作唯一流程。
新项目启动时，Spec-kit 和 Superpowers 可帮助快速搭建规范；遗留系统改造时，OpenSpec 和 GSD更合适；需高合规性项目建议采用 Spec-kit/BMAD，配合额外审计。