一、开源解读（2）AI 编程进入规格时代：Spec Kit、OpenSpec、BMAD、Superpowers、gstack 到底怎么选？
过去一年，AI 编程最大的变化，并不是模型又多写了几行代码，而是开发者开始意识到一个更现实的问题：让 AI 写代码很容易，让 AI 稳定交付很难。
早期的 AI 编程更接近 Vibe Coding。开发者给出一个模糊意图，模型根据上下文直接生成代码。这种方式非常适合原型验证，也非常适合个人开发者快速探索想法。但当项目进入真实生产环境后，Vibe Coding 的问题会迅速暴露：需求容易被模型误解，技术方案缺乏追踪，代码实现经常偏离原始目标，测试和验收也容易被跳过。
于是，Spec-Driven Development，简称 SDD，重新变得重要。
这里需要先澄清一个误解：SDD 不是传统瀑布式文档的复活，而是 AI 编程时代的一种工程约束机制。 规格不再只是代码之前的辅助材料，而是驱动需求澄清、计划拆解、任务执行、代码生成和质量验证的核心资产。
过去是“代码作为事实来源”，现在开始变成“规格作为事实来源”。
二、技术选型对比表
| 工具 | 核心定位 | 最适合场景 | 主要产物 | 流程重量 | 关键优势 | 主要限制 |
|---|---|---|---|---|---|---|
| Spec Kit | 正统 SDD 工程框架 | 新项目、复杂功能、团队统一规范 | constitution、spec、plan、tasks | 较重 | 规格、计划、任务链路完整，适合形成组织级标准 | 小需求会显得有仪式感 |
| OpenSpec | 轻量规格变更层 | 已有项目、渐进式改造、单次变更管理 | proposal、delta specs、design、tasks | 中轻 | 适合 brownfield，强调变更归档与上下文连续性 | 强治理能力弱于 Spec Kit |
| BMAD | AI 敏捷团队框架 | 从 0 到 1 产品规划、复杂系统设计 | PRD、架构、UX、任务流、角色协作产物 | 较重 | 多角色协作，覆盖完整生命周期 | 日常小修小改成本偏高 |
| Superpowers | Agent 工程纪律系统 | 约束 Claude Code、Codex 等编码 Agent | design doc、plan、TDD、review、verification | 中等 | 把好工程习惯变成强制流程 | 更偏方法论，不是单一规格仓库 |
| gstack | 角色化 AI 工程组织 | 创始人、技术负责人、独立开发者高强度交付 | office-hours、review、QA、ship、retro 等角色化输出 | 中重 | 把 AI 编程拆成虚拟工程团队 | 风格强，适合认同其工作流的人 |
这张表可以先给结论：如果你要建立组织级 SDD，优先看 Spec Kit；如果你在旧项目里渐进引入规格管理，优先看 OpenSpec；如果你需要产品、架构、体验一起推演，BMAD 更合适；如果你主要想约束 Agent 的工程习惯，Superpowers 更关键；如果你希望把 AI 当作一个虚拟研发团队来使用，gstack 更接近这个方向。
三、Spec Kit：把规格变成工程主线
GitHub 的 Spec Kit 是这轮 SDD 工具里最接近“标准工程流程”的一个。
它的核心观点非常明确：规格不是临时文档，而是可执行资产。过去，PRD、设计文档、测试计划往往只是辅助开发者理解需求；而在 Spec Kit 的模型里，规格本身应该能够驱动后续的计划、任务和实现。
Spec Kit 的基本流程包括 constitution、specify、clarify、plan、tasks、analyze、implement 等阶段。constitution 用来定义项目原则，specify 用来描述需求，clarify 用来消除模糊点，plan 将需求转化为技术方案，tasks 再把方案拆成可执行任务，最后进入实现。
它的价值不在于“多写 Markdown”，而在于把 AI 编程从一句提示词推进到一条可追踪的工程链路。每个技术决策都能回到规格，每个实现任务都能回到计划，每次验收也能回到最初的需求。
重点判断：Spec Kit 适合把 SDD 变成团队制度，而不是只当作个人提示词技巧。
因此，Spec Kit 最适合用于新项目、复杂功能和团队协作。它能够帮助团队建立统一的 AI 开发语言，也能避免 Agent 在实现阶段自由发挥过度。它的代价是流程相对完整，对小需求来说会显得偏重。
四、OpenSpec：给已有项目补上变更记忆
OpenSpec 的定位更轻。它强调的不是一次性建立完整规格体系，而是在每一次变更中留下清晰、可归档、可审查的上下文。
OpenSpec 的核心模型可以概括为：specs 表示系统当前事实，changes 表示即将发生的变更。每次新增功能或修改行为，都会创建一个 change 文件夹，其中包含 proposal、specs、design 和 tasks。实现完成后，再通过 archive 将这次变更合并回主规格。
这套设计非常适合已有项目。
真实工程中，大多数团队并不是从零开始开发一个干净系统，而是在历史代码、遗留架构和不断变化的业务需求上继续迭代。此时，如果要求团队先把整个系统完整规格化，成本会非常高。OpenSpec 的思路更务实：不要求你描述整个世界，只要求你把这一次变更描述清楚。
重点判断：OpenSpec 的价值不是建立宏大蓝图，而是让每一次变更都有可追踪的理由。
它的优势是轻、灵活、容易落地，尤其适合个人项目、小团队和 brownfield 项目。它的限制也很明确：如果企业希望建立强标准、强流程、强一致性的规格体系，OpenSpec 的约束力不如 Spec Kit。
五、BMAD：把 AI 变成敏捷产品团队
BMAD Method 与 Spec Kit、OpenSpec 的差异更大。它不是一个单纯的规格工具，而是一个 AI 驱动的敏捷开发框架。
BMAD 的重点在于角色化协作。它提供 PM、Architect、Developer、UX 等多个专业角色，并试图覆盖从 brainstorming、产品定义、架构设计到实现交付的完整生命周期。
这类框架解决的是另一个问题：很多时候，用户并不是缺少代码生成能力，而是还没有想清楚产品到底应该怎么做。需求边界、用户价值、系统架构、交互路径、技术取舍都处于模糊状态。如果此时直接让 AI 写代码，模型会很快给出一个“看起来能跑”的版本，但这个版本未必解决了真正的问题。
BMAD 的价值在于把前期思考结构化。它让不同 AI 角色从产品、架构、体验、实现等角度参与讨论，帮助用户把模糊想法逐步变成可执行方案。
重点判断：BMAD 更适合“问题还没想透”的阶段，而不是只用来执行已经确定的任务。
因此，BMAD 更适合复杂产品、从 0 到 1 项目、业务和技术都尚未完全定型的场景。它不适合所有日常开发任务，因为它的流程较重。如果只是修复一个小 bug 或调整一个字段，使用 BMAD 反而可能造成过度设计。
六、Superpowers：把工程纪律写进 Agent 行为
Superpowers 的重点不是单一规格仓库，而是一套面向编码 Agent 的工程方法论。上面这张图来自本地已有的 Superpowers 深度解读文档，它把 Superpowers 的会话注入、技能路由、技能文件模型、核心技能库、Agent 编排和典型工作流放在同一张架构图里，比单纯看 README 更容易理解它在 SDD 体系里的位置。
它最重要的价值，是把高级工程师的工作习惯转化为 Agent 必须遵守的流程。
在 Superpowers 的基本工作流中，Agent 不应该在收到需求后立刻写代码，而应该先通过需求澄清理解目标和约束；在设计获得确认后，再生成实现计划；进入开发阶段后，按照测试驱动开发、系统化调试、代码审查和完成前验证等流程推进。也就是说，它并不只是提醒 Agent “要小心”，而是通过技能触发机制，把这些动作变成默认行为。
这点非常关键。
AI 编程的问题往往不在于模型不会写代码，而在于它太容易跳过工程纪律。它可能没有复现问题就直接修复，没有写测试就声称完成，没有验证结果就给出结论，也可能在上下文不足时自行脑补需求。
Superpowers 试图解决的正是这些问题。它不直接定义某个项目的规格结构，而是规定 Agent 如何工作：什么时候应该澄清需求，什么时候应该写计划，什么时候必须测试，什么时候必须 review，什么时候才能宣布完成。
重点判断：Superpowers 更像是 SDD 的执行纪律层。Spec Kit 和 OpenSpec 解决“规格如何组织”，Superpowers 解决“Agent 如何按照规格可靠执行”。
七、gstack：把 Claude Code 组织成虚拟工程团队
gstack 的路线更加个人化，也更具有创业公司气质。
它的核心观点是：不要把 AI 当成一个万能助手，而要把它拆成一个虚拟工程团队。这个团队中有 CEO、工程负责人、设计师、代码审查者、QA、SRE、安全负责人和发布工程师。每个角色通过 slash command 介入不同阶段，分别负责产品判断、架构审查、设计把关、代码 review、浏览器测试、安全审计和发布交付。
gstack 的工作流不是传统意义上的规格工具，但它与 SDD 的关系非常紧密。因为它同样强调在写代码之前先定义目标，在实现过程中不断审查，在交付之前完成 QA 和发布验证。
它适合的用户也很明确：创始人、技术负责人、独立开发者，以及希望用一个人完成小团队产能的人。
重点判断：gstack 的本质不是“更多命令”，而是把 AI 编程拆成一个有角色、有审查、有发布纪律的工程组织。
gstack 的优势是实战性强，角色边界清楚，覆盖从想法到发布的全过程。它的限制是风格很强，带有 Garry Tan 本人的工作方法烙印。对于喜欢强流程、强角色化、强审查的人来说，它可能非常顺手；对于只想要轻量规格管理的人来说，它可能显得过于完整。
八、这些工具真正解决的，是 AI 编程的不确定性
把这些工具放在一起看，会发现它们并不是同一种产品。
Spec Kit 关注规格治理，OpenSpec 关注变更连续性，BMAD 关注多角色产品与工程协作，Superpowers 关注 Agent 执行纪律，gstack 关注角色化工程组织。
但它们背后有一个共同前提：
AI 编程越强，工程约束越重要。
当模型能力较弱时，问题主要是“它写不出来”。当模型能力变强后，问题就变成“它会写很多，但不一定写对”。它会根据不完整需求做假设，会在上下文中丢失关键约束，会为了完成任务而引入不必要复杂度，也会在没有验证的情况下给出自信结论。
SDD 的意义，就是用规格、计划、任务、测试、审查和归档来降低这种不确定性。
这不是回到低效文档时代，而是让文档重新变成可执行的工程资产。过去的文档经常写完就过期；今天的规格必须参与开发过程，持续驱动实现，并在变更完成后更新为新的系统事实。
九、企业应该怎么选
如果团队正在启动新项目，并且希望建立统一的 AI 开发规范，Spec Kit 是更合适的起点。它的流程完整、结构稳定，适合把 SDD 变成团队共识。
如果团队面对的是已有系统，尤其是历史代码较多、需求持续变化的项目，OpenSpec 更容易落地。它不要求一次性重建所有规格，而是围绕每一次变更建立上下文。
如果项目还处于产品定义阶段，需求、用户价值和架构方案都没有完全想清楚，BMAD 会更有帮助。它的多角色机制可以在写代码之前逼出更多关键问题。
如果团队已经在使用 Claude Code、Codex、Cursor 等编码 Agent，但经常遇到“没测试就说完成”“没复现就修 bug”“上下文一长就乱来”的问题，Superpowers 的优先级会很高。它解决的是 Agent 的工程纪律问题。
如果你是创始人、技术负责人或独立开发者，希望把 AI 当成一个小型研发组织来使用，gstack 会更贴近这个需求。它不是最轻的方案，但它的角色化流程非常适合高强度交付。
最终选择不应该看哪个工具更火，而应该看你的主要痛点是什么：是缺规格、缺变更记忆、缺产品推演、缺执行纪律，还是缺一个完整的 AI 工程团队。
十、结语：未来的 AI 编程会越来越像规格工程
AI 编程早期，大家追求的是速度：谁能更快生成页面，谁能更快搭出 MVP，谁能更快完成一个 Demo。
但真正进入生产环境后，速度不是唯一问题。更重要的问题是：系统是否可维护，需求是否可追踪，代码是否可验证，团队是否能在多轮 AI 协作后仍然保持一致。
这就是 SDD 重新重要的原因。
Vibe Coding 解决的是从想法到 Demo 的速度问题。Spec-Driven Development 解决的是从 Demo 到生产的工程问题。
Spec Kit、OpenSpec、BMAD、Superpowers 和 gstack 的出现，说明行业正在从“让 AI 写代码”进入“让 AI 按工程秩序交付”的阶段。
AI 不缺生成能力，真正稀缺的是约束、上下文和验证。
而这，正是规格驱动开发重新登场的原因。
