MumuSpec与其他Spec工具对比，虽然工具不同，但通过Spec生成稳定可控代码的目标不变

用户5602664

发布于 2026-05-26 19:40:20

930

一、生态全貌

过去两年，SDD（Spec-Driven Development）领域从几乎空白到百花齐放。目前市场上的工具可以归为六类：

类型	代表	核心回答
流程编排型	GitHub Spec Kit、GSD、Ralph Loop	如何走通 Spec→Code 的流程？
变更管理型	OpenSpec	如何在已有项目中增量管理 Spec？
多 Agent 协作型	BMAD	如何用 AI 模拟完整团队分工？
深度集成型	AWS Kiro、Tessl	如何把 Spec 嵌入 IDE 或编译管线？
内容模板型	PRD Engine、Specs-Creator、Anvil、Product Spec Kit、BALDART	Spec 到底该写什么？
混合型	MumuSpec	内容+规范+CLI+IDE 怎么融合？

GitHub Spec Kit

5 阶段顺序流程 —— Constitution → Spec → Plan → Tasks → Implement。constitution.md是最亮眼的创新：项目级统一规则，所有 Spec 继承。短板是 Brownfield 项目难用，小变更太重。适合绿 field 项目。Agent 支持 30+。

OpenSpec

Propose → Apply → Archive 三步循环，只记录变化部分。specs/+ changes/分离，Brownfield 极其友好。适合已有项目改造、单人开发者。Agent 支持 25+。

BMAD

12+ 个 AI 角色模拟完整敏捷团队。产出可作合规审计证据（SOC 2、HIPAA、EU AI Act）。但极其昂贵——800-2,000+/月/人。适合合规行业。

AWS Kiro

SDD 内置 IDE。EARS 格式需求→设计→任务。"Spec Check"数学验证需求一致性。短板是 AWS 生态绑定。

Tessl

追求"Spec-as-Source"，1:1 Spec-to-Code 映射。如果成功，Spec 和代码的漂移问题将被根本消灭。目前仍内测。

GSD（Get Shit Done）

3 阶段漏斗，~700 token。把复杂度藏在系统里。适合 Solo 快速迭代。

Ralph Loop

每次启新 Agent + git 记忆层。67% 回归 bug 自动修。适合 CI/CD 自动化。

PRD Engine（LobeHub）

完整 PRD 方法论 + 0-100 质量评分门禁。Agent 优化格式。

Specs-Creator（SkillsMP）

覆盖 PRD / Tech / Design / API 四类文档的 Agent Skill。

Anvil（GitHub）

Components-Capabilities-Enablers-Requirements 四层模型。内置依赖管理。

Product Spec Kit（SkillsMP）

PRD → Plan → Stories 工作流。Design-Driven Development 原则。

BALDART（npm）

24 个专用 AI Agent，含 PRD / Feature Card / Technical Spec agent。

二、五个维度区分 Spec 工具

Spec 工具的目标只有一个：让 AI 生成符合预期的代码。但不同工具对"怎么做到"的假设不同。

以下五个维度不是打分标准，而是定位坐标——每个工具在每个维度上的选择都反映了它的设计哲学。

维度 1：产出形态

类型	产出	消费者	代表
流程规范	流程定义、阶段划分	开发者按流程执行	Spec Kit、GSD、Ralph Loop
内容模板	文档模板、写作指南	开发者写文档、AI 读文档	PRD Engine、Specs-Creator、Anvil
CLI工具	命令行命令	开发者执行命令	Spec Kit、OpenSpec、BMAD
集成环境	IDE 插件、内建工作流	开箱即用	Kiro、Tessl

维度 2：生命周期管理

方式	做法	代表
嵌入 Prompt	Spec 存在于每次 Prompt 中，用完即弃	GSD、Ralph Loop
Git 同仓	Spec 和代码同仓库，一起 PR/Review/归档	Spec Kit、OpenSpec、MumuSpec、Anvil
独立平台	Spec 在独立平台中管理	Kiro、Tessl
Agent 内建	Spec 存在于 Agent 记忆或配置中	BMAD、BALDART

维度 3：覆盖范围

阶段	内容
需求	用户故事、PRD、验收标准
设计	API 契约、数据模型、架构
实现	AI 读 Spec 生成代码
验证	测试、门禁

工具	需求	设计	实现	验证
Spec Kit	✓	✓	✓	✗
OpenSpec	✓	✓	✗	✗
BMAD	✓	✓	✓	✓
Kiro	✓	✓	✓	✓
Tessl	✗	✓	✓	✓
GSD	✓	✗	✓	✗
Ralph Loop	✗	✗	✓	✓
PRD Engine	✓	✗	✗	✓
Specs-Creator	✓	✓	✗	✗
Anvil	✓	✓	✗	✗
Product Spec Kit	✓	✗	✗	✗
BALDART	✓	✓	✓	✗
MumuSpec	✓	✓	✓	✓

✓ 表示"覆盖了这个阶段的规范定义"，不表示质量高低。

维度 4：验证方式

验证方式	逻辑	代表
信任流程	流程走对，结果自然对	Spec Kit
信任模型	模型足够聪明	GSD
信任测试	测试覆盖验证	BMAD、Ralph Loop
信任检查	专门机制验证代码是否符合 Spec	Kiro（Spec Check）、Tessl（编译级）、MumuSpec（validate）
信任人工	Code Review 把关	OpenSpec、Anvil
设计未实现	写了怎么验，但没实现	PRD Engine（评分）

维度 5：AI 集成方式

方式	说明	代表
Prompt 模板	给 Prompt 结构，开发者自喂 AI	GSD
Agent Skill	封装为 Skill 直接调用	PRD Engine、Specs-Creator
CLI编排	CLI 管理 AI 工作流	Spec Kit、OpenSpec、BMAD、MumuSpec
原生 IDE	AI 内置在 IDE	Kiro
多 Agent 系统	多个 AI Agent 自动协作	BMAD、BALDART、Ralph Loop

综合矩阵

工具	产出形态	生命周期	覆盖范围	验证方式	AI 集成
SpecKit	流程+CLI	Git 同仓	需求+设计+实现	信任流程	CLI 编排
OpenSpec	CLI	Git 同仓	需求+设计	信任人工	CLI 编排
BMAD	流程+CLI	Agent 内建	全链路	信任测试	多 Agent
Kiro	集成环境	独立平台	全链路	信任检查	原生 IDE
Tessl	集成环境	独立平台	设计+实现+验证	编译级检查	原生
GSD	流程规范	嵌入 Prompt	需求+实现	信任模型	Prompt 模板
Ralph Loop	流程规范	嵌入 Prompt	实现+验证	信任测试	多 Agent
PRDEngine	内容模板	嵌入 Prompt	需求+验证	设计未实现	Agent Skill
Specs-Creator	内容模板	嵌入 Prompt	需求+设计	—	Agent Skill
Anvil	内容模板+CLI	Git 同仓	需求+设计	信任人工	—
Product SpecKit	内容模板	嵌入 Prompt	需求	—	Agent Skill
BALDART	内容模板+CLI	Agent 内建	需求+设计+实现	—	多 Agent
MumuSpec	内容模板+规范+CLI+IDE	Git 同仓	需求+设计+验证	信任检查	CLI 编排 + IDE

读这个表格看什么

关键不在于"哪个维度更好"，而在于观察模式：

GSD和 Kiro 几乎在所有维度上都相反——GSD 轻到极致（Prompt 嵌入 / 信任模型），Kiro 重到极致（独立平台 / 信任检查）。它们对"Spec 到底做多深"的回答完全不同，但各自都在自己的场景里有效。
内容类工具在生命周期管理上普遍是空白——它们专注"写什么"，不关心"写了之后怎么管"。
验证方式是最两极分化的维度——从完全依赖流程/人工到自动检查到未实现，反映了行业对"怎么验证 Spec 和代码一致"还没有共识。
所有工具的"指纹"都不一样——没有两个工具在五个维度上完全一致，说明这个分类粒度是合适的。

三、不同设计哲学的取舍

每种工具背后的设计决策都是一组权衡，没有银弹。

流程的重量

工具	设计哲学	优点	代价
Spec Kit	标准化流程确保质量	团队产出一致	小变更摩擦大
GSD	极致精简	上手零成本	依赖个人能力
BMAD	AI 模拟团队分工	审计证据完整	贵、慢、重
OpenSpec	像 git 一样管 Spec	Brownfield 友好	不做内容不做门禁

内容的深度

工具	设计哲学	优点	代价
PRD Engine	结构化 PRD + 质量评分	质量可量化	仅限 PRD
Anvil	四层模型驱动	结构严谨	学习成本高
MumuSpec	114份文档分层覆盖	覆盖面广	维护成本高

四、到底怎么选？

场景	推荐组合	思路
Solo + Claude Code	MumuSpec（内容）+ GSD（流程）	内容定标准，流程用最轻的
前端团队统一标准	Spec Kit（流程）+ MumuSpec 06 模板	流程靠 Spec Kit，内容借模板
已有项目改造	OpenSpec（CLI）+ MumuSpec（内容）	CLI 用 OpenSpec，模板借鉴 MumuSpec
合规行业	BMAD	审计证据是刚需
AWS 全栈	Kiro	开箱即用
要最轻的	GSD	700 token 开干
只要内容模板	PRD Engine / MumuSpec	看风格匹配
无人值守自动化	Ralph Loop	DevOps 场景

Reenbit 的结论值得反复读："交付最好的团队不是选对了框架的团队，而是为项目选了合适框架并在项目变化时及时调整的团队。"

不存在万能方案。每个工具在自己的设计目标下都是最优解。

五、MumuSpec 详细介绍

为什么做 MumuSpec

每次写 Prompt 都要重复说同样的事情，Agent 产出的质量全靠运气。市面上要么只有流程（Spec Kit、OpenSpec），要么只有模板（PRD Engine），想把"内容标准 + 变更管理 + 自动门禁"串起来，当时没有现成的选择。

设计原则

原则	说明
分级使用	S/A/B/C 四级对应不同规模，不强制全流程
变更驱动	只记变化（Delta），不重写全文
按需拉取	Agent 按阶段注入 2-4 份文档，避免 Context 浪费
可自动化则自动化	能写成测试的约束不写进纯文本
铁律不变	PRD 不写 SQL、API 不写像素、契约真源

# 文档体系
Core（B/C 级至少）
├── 04 产品需求说明
├── 05 用户故事与验收标准
└── 13 测试策略与质量门禁
Extended（A 级 +）
├── 06 功能规格说明
├── 07 系统约束（非功能+安全）
├── 09 API 接口规格（契约真源）
└── 10 数据模型与存储规格（存储真源）
Full（S 级）
├── 03 立项提案与范围说明
├── 08 系统架构与技术选型
└── 14 需求追踪矩阵

# 目录结构
MumuSpec/
├── library/     完整知识库（只读，归档时更新）
├── changes/     当前活跃变更（写 Delta）
├── archive/     已完成变更历史
└── ops/         Fitness Functions（设计）

在五个维度上的位置

维度	MumuSpec 的选择
产出形态	内容模板 + 规范 + CLI + IDE（11 份文档模板 + gluekit validate/context 命令 + VS Code 扩展）
生命周期	Git 同仓（library + changes + archive 目录结构）
覆盖范围	需求 + 设计 + 验证（validate 实现结构性验证，不覆盖代码级验证）
验证方式	信任检查（FF-SPEC-001~008 自动检查文档和目录合规）
AI 集成	CLI 编排 + IDE 集成（gluekit context --stage 管理注入，vscode 扩展）