可由项目官方仓库或官方文档直接支持。
Spec-driven development & adjacent methods
SDD 技术
研究地图
系统记录规格驱动开发及其相邻的结构化 Agent 开发方法。第一版先建立统一研究骨架:说明它们分别在管什么、留下什么资产、怎样运行,以及哪些结论仍需真实项目验证。
01 · Working definition
本站如何理解 SDD
这是一条研究用的操作性定义,不是试图替所有项目给出唯一标准。
先将意图、约束和预期行为形成可审阅的规格或结构化产物,再让计划、实现与验证围绕这些产物推进。
基于官方结构做出的有限归纳,不作为最终选型结论。
需要运行工具、观察产物或完成同题实验后再回答。
02 · Research dimensions
用同一把尺子持续研究
每个详情页都沿用这些维度,未来补充内容时不改变基本结构。
官方定位
项目自己如何定义它。
核心问题
它试图减少哪类失败。
核心资产
规格、计划、任务或记忆。
生命周期
从意图到完成如何推进。
安装形态
插件、skills、CLI 或脚手架。
CLI 依赖
是否需要独立执行引擎。
宿主依赖
依靠哪些 coding agents。
规格演进
事实如何更新与保留历史。
质量保障
如何连接测试、审查与证据。
场景与边界
什么条件下更可能有价值。
03 · Tool index
五个研究对象
卡片按研究列表排列,不代表成熟度、能力或推荐顺序。GitHub Star 为 2026-08-21 查询快照,会随时间变化。
Superpowers
更偏向 coding agent 的开发方法与过程纪律:先澄清、再计划,以测试、调试、审查和完成前验证约束实现。
OpenSpec
更偏向规格共识和长期事实演进:用 active changes 描述候选变化,完成后再把 delta 合入主 specs。
BMad Method
更偏向角色化、阶段化的上下文工程与敏捷开发流程,通过不同工作流逐步形成分析、规划、方案和实施上下文。
GitHub Spec Kit
明确以 specification-driven development 为核心,通过模板、项目脚手架、CLI 和 agentic commands 推进结构化阶段。
Trellis
更偏向团队级 agent harness:把工程规范、任务上下文、验证流程和项目记忆持久化到仓库,并适配多个 coding agents。
04 · Early comparison
只比较结构,不进行评分
下面是第一轮官方资料阅读后的定位,后续会由同题实测修正。
| 工具 | 主要关注层 | 代表性资产 | 独立 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
后续怎样逐个补充
先确认机制,再观察真实产物,最后才讨论选型。
最小工作流
核对安装、初始化和第一条完整路径。
同题实验
用同一个小需求完成端到端开发。
产物对照
比较规格、计划、任务、记忆与验证证据。
棕地与团队
观察旧项目接入、协作和冲突恢复。
形成建议
只有获得实测证据后再提出条件式选型建议。