Spec-driven development & adjacent methods

SDD 技术
研究地图

系统记录规格驱动开发及其相邻的结构化 Agent 开发方法。第一版先建立统一研究骨架:说明它们分别在管什么、留下什么资产、怎样运行,以及哪些结论仍需真实项目验证。

第一版 · 初步记录 5 个研究对象 仅使用官方一手资料 核对日期 · 2026-08-21

01 · Working definition

本站如何理解 SDD

这是一条研究用的操作性定义,不是试图替所有项目给出唯一标准。

先将意图、约束和预期行为形成可审阅的规格或结构化产物,再让计划、实现与验证围绕这些产物推进。
研究重点不是“有没有 Markdown”,而是规格在流程中承担什么责任。
官方事实

可由项目官方仓库或官方文档直接支持。

初步观察

基于官方结构做出的有限归纳,不作为最终选型结论。

后续验证

需要运行工具、观察产物或完成同题实验后再回答。

02 · Research dimensions

用同一把尺子持续研究

每个详情页都沿用这些维度,未来补充内容时不改变基本结构。

01

官方定位

项目自己如何定义它。

02

核心问题

它试图减少哪类失败。

03

核心资产

规格、计划、任务或记忆。

04

生命周期

从意图到完成如何推进。

05

安装形态

插件、skills、CLI 或脚手架。

06

CLI 依赖

是否需要独立执行引擎。

07

宿主依赖

依靠哪些 coding agents。

08

规格演进

事实如何更新与保留历史。

09

质量保障

如何连接测试、审查与证据。

10

场景与边界

什么条件下更可能有价值。

03 · Tool index

五个研究对象

卡片按研究列表排列,不代表成熟度、能力或推荐顺序。GitHub Star 为 2026-08-21 查询快照,会随时间变化。

obra/superpowers初步记录

Superpowers

更偏向 coding agent 的开发方法与过程纪律:先澄清、再计划,以测试、调试、审查和完成前验证约束实现。

宿主插件 / skills无独立领域 CLI
查看研究档案
Fission-AI/OpenSpec初步记录

OpenSpec

更偏向规格共识和长期事实演进:用 active changes 描述候选变化,完成后再把 delta 合入主 specs。

Skills + CLIChange lifecycle
查看研究档案
bmad-code-org/BMAD-METHOD初步记录

BMad Method

更偏向角色化、阶段化的上下文工程与敏捷开发流程,通过不同工作流逐步形成分析、规划、方案和实施上下文。

npx 安装器模块与角色
打开 BMad GitHub ★ 52.1k
查看研究档案
github/spec-kit初步记录

GitHub Spec Kit

明确以 specification-driven development 为核心,通过模板、项目脚手架、CLI 和 agentic commands 推进结构化阶段。

specify CLISpec → Plan → Tasks
查看研究档案
mindfold-ai/Trellis初步记录

Trellis

更偏向团队级 agent harness:把工程规范、任务上下文、验证流程和项目记忆持久化到仓库,并适配多个 coding agents。

trellis CLISpecs + Tasks + Memory
查看研究档案

04 · Early comparison

只比较结构,不进行评分

下面是第一轮官方资料阅读后的定位,后续会由同题实测修正。

初步观察 · 核对日期 2026-08-21
工具主要关注层代表性资产独立 CLI 情况宿主 Agent
Superpowers开发过程与实现纪律设计、计划、技能化门禁无额外领域 CLI需要
OpenSpec规格共识与变更演进主 specs、change artifacts、archive完整工作流需要 CLI;不强制全局安装需要
BMad Method角色、阶段与上下文工程分析、规划、方案、实施文档npx bmad-method 负责安装;工作流主要在宿主执行需要
Spec Kit规格阶段与项目脚手架constitution、spec、plan、tasks使用 specify CLI需要
Trellis团队规范、任务与项目记忆.trellis/spec/、tasks、workspace使用 trellis CLI需要

05 · Research roadmap

后续怎样逐个补充

先确认机制,再观察真实产物,最后才讨论选型。

最小工作流

核对安装、初始化和第一条完整路径。

同题实验

用同一个小需求完成端到端开发。

产物对照

比较规格、计划、任务、记忆与验证证据。

棕地与团队

观察旧项目接入、协作和冲突恢复。

形成建议

只有获得实测证据后再提出条件式选型建议。