SpecScore 与 BMAD Method
BMAD Method（面向敏捷、由人工智能驱动的突破性开发方法，Breakthrough Method for Agile AI-Driven Development）是一种开源做法，用 AI 代理来做敏捷交付：把工作澄清、排成计划、做出来、再检查，并把决定写下来。产品需求文档（PRD）是用散文说明要构建什么、做给谁；这个方法的工作流地图会先产出一份，然后才是架构和故事。规范驱动开发（SDD）是两边共同所处的更大想法——行为在代码之前被写明。SpecScore 是这种规格的一种开源格式，外加命令行界面（CLI）。持续集成（CI）——每一次提议的变更都会自动查一遍——可以在 SpecScore 文件结构不对时失败。
两者的共同点。
BMAD Method 做得好的地方。
2026年10月30日读过的项目 README 把 v6.12 称为稳定版，把 main 分支上的 v7 称为预览。那份 README 里写的 v7 日期，当时已经过了。这些版本线的名字，只当作那一刻的快照。
方法会自己看工作有多大
README 说，小改动直接去做，较大的工作才进入规划。main 上的工作流地图把阶段写明了：一份 PRD（PRD.md）、可选的 UX 规格、带决策记录的 architecture.md、史诗文件和故事文件，然后是一次冲刺。这是一整圈敏捷循环，不是一条提示词。
实现之前有一道关卡
同一张地图列出了 bmad-check-implementation-readiness，它在实现之前返回 PASS、CONCERNS 或 FAIL。v6 的产品经理代理还有一步 validate-PRD。这些是代理自己跑的工作流关卡。它们不是一个你可以拿去指向任意 Markdown 目录树的独立格式检查器。
它确实公开了
这个方法在公开仓库里以MIT 许可发布。README 里的稳定安装命令是 npx bmad-method install，并要求 Node.js 20.12 或更新版本，以及 Python 3.10 或更新版本。网站bmadcode.com说这个方法免费。
功能对比。
BMAD 是过程。SpecScore 是过程可以去对准的产物格式。下表比较的是这两种角色。
| 能力 | BMAD Method | SpecScore |
|---|---|---|
| 主要角色 | 敏捷方法：代理、技能和工作流，从想法一直做到经过验证的代码 | 开放的规格格式 + CLI |
| 规划产物 | PRD、UX 规格、架构、史诗和故事、冲刺状态——依据 2026年10月30日读到的工作流地图 | 想法、功能、计划、任务，放在 spec/ 目录树里，并带有需求标识 |
| 如何检查工作 | 就绪关卡（PASS / CONCERNS / FAIL），以及由代理运行的 validate-PRD 工作流 | specscore spec lint 跑在 CI 里，结果是确定的。/score 是手动的 AI 评分。 |
| 需求标识 | 故事和功能需求写在 PRD 与史诗文件里。不是 SpecScore 的 REQ: slug。 | REQ: slug，以及验收标准的标识 |
| 运行环境 | README 所写的 v6.12 安装器需要 Node.js 和 Python | 没有别的，只要一支 Go 二进制文件 |
| 许可证 | MIT，bmad-code-org/BMAD-METHOD | CC BY 4.0 格式 · Apache-2.0 CLI |
SpecScore 增添了什么。
检查是一条命令，不是方法里的一步
BMAD 的就绪结果，是它工作流内部的一个决定。SpecScore 的结果是进程退出码。dogfood.yml 在每一个拉取请求上运行 specscore spec lint。/score 用仓库里配置好的评审者给产物打分；要你自己去调用。CI 不会去调。
$ specscore spec lint features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds features/apply-discount/refunds:0 [error] readme-exists: README.md not found 3 violations found (3 errors)
换一种方法，格式还在
BMAD 的文档，形状是它的工作流定下来的。你若停止运行 BMAD，Markdown 还在，但方法之外没有东西再去强制这个形状。一棵 SpecScore 目录树就是契约。别的工作流——包括 BMAD——也可以去写它，检查器照样适用。
故事和需求靠标识连在一起
BMAD 的故事把上下文往后带，免得代理把产品重新决定一遍。SpecScore 把这条关联做成机械的：计划里的任务引用 REQ: slug，specscore: 注解再加上 Verifies: 提交尾注，把代码指回那条标准。
何时使用哪个。
更适合用 BMAD Method 的时候……
- 你要一整圈敏捷循环——PRD、架构、故事、冲刺——由带着角色化工作流的代理来执行。
- 你要那道就绪关卡，以及这个方法自带的产品、架构和测试这几方视角。
- 你在统一团队怎么写提示词，而这个方法的技能就是那套标准。
以下场景适合使用 SpecScore……
- 标题、链接或状态错了，规格就要让 CI 失败，哪怕那天没有人跑 BMAD 工作流。
- 你需要跨工具都稳定的需求标识，而不是只活在某一种方法的故事文件里。
- 你希望有一种开源格式，让另一种过程也可以对准它。
方法可以去写这种格式。
BMAD 回答的是“我们怎么把工作跑起来”。SpecScore 回答的是“哪一份文件才是契约，CI 又怎么知道它还完好”。团队可以留着 BMAD 的 PRD 和故事来谈话，再留一份 SpecScore 功能，放那些必须通过检查的需求。
循环用 BMAD Method。拉取请求要检查的那份产物，用 SpecScore。
来源。
下方公开页面阅读于 2026 年 10 月 30 日。价格、方案名称和发布线会变化。
反馈
本对比基于公开可用的文档和源代码。发现不准确或过时的信息？请 提交勘误 issue. 希望我们将 SpecScore 与其他工具进行对比？请 提交请求.