# 2026 年最好的规范驱动开发工具

Canonical: https://specscore.md/zh-cn/spec-driven-development/tools/

SpecScore 是一种用于规格说明的开放、可 lint 的文件格式，用 Markdown 和 YAML（YAML Ain't Markup Language）写成。[规范驱动开发](https://specscore.md/zh-cn/spec-driven-development/)（SDD）是一种做法：书面规格是事实来源，代码照着它来构建，也照着它来核对。规范驱动开发工具是用来撰写、存放、有时也用来检查这些规格的格式、工作流和产品。产品需求文档（PRD）是一篇散文，在任何人把工作拆成任务之前，写明问题和范围。[简易需求语法](https://kiro.dev/docs/specs/feature-specs/)（EARS）是一种需求句子，形式为“WHEN 某事发生，THE SYSTEM SHALL 做某事”。[命令行界面](https://specscore.md/zh-cn/cli/)（CLI）是在终端里运行的程序。[持续集成](https://specscore.md/zh-cn/validators/)（CI）是对每一次提议的变更所做的自动检查。

这篇规范驱动开发工具对照涵盖 [GitHub Spec Kit](https://github.com/github/spec-kit)、[OpenSpec](https://github.com/Fission-AI/OpenSpec)、[Kiro](https://kiro.dev/)、[Tessl](https://docs.tessl.io/)、[BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD)、[Task Master AI](https://github.com/eyaltoledano/claude-task-master)、[CodeSpeak](https://codespeak.dev/)、[Datarim](https://github.com/Arcanada-one/datarim)、纯 Markdown，以及 [SpecScore](https://specscore.md/zh-cn/)。公开页面和仓库读于 2026年10月30日。命令、文件怎么摆，以及产品实际检查什么，之后都可能变；页底的来源写明每一条说法出自哪一页。

对一个仓库来说，要紧的分界是：规格能不能单靠自己让 CI 失败。在 SpecScore 网站这个仓库里，[dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) 会安装 SpecScore CLI，并在拉取请求上、以及向 main 的推送上运行 `specscore spec lint`。specstudio-skills 里的 [/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) 技能，是对一份产物做的手动 AI 评分。你去调用它。那条工作流不会。

## 规范驱动开发工具，并排一看。

每一行是一种角色，不是一项分数。点名称去看 SpecScore 的对比；这一格背后的依据，见下方标题。

| 工具 | 它是什么 | 规格怎么写、放在哪里 | 规格的自动检查 | 许可证 | 适合谁 |
| --- | --- | --- | --- | --- | --- |
| [GitHub Spec Kit](https://specscore.md/zh-cn/vs/spec-kit/) | 交给编码代理的一套流程，产出的是 Markdown 产物 | 功能目录位于 `specs/` 之下：`spec.md`、`plan.md`、`tasks.md` | `/speckit.analyze` 在代理会话里报告跨产物的缺口。社区扩展可以再加门禁。 | [MIT](https://github.com/github/spec-kit/blob/main/LICENSE)，公开仓库为 [github/spec-kit](https://github.com/github/spec-kit) | 想让代理走同一套共享流程的团队 |
| [OpenSpec](https://specscore.md/zh-cn/vs/openspec/) | 用变更文件夹和代理命令，在写代码之前先对齐 | 纯 Markdown，放在 `openspec/changes/` 下：proposal、specs、design、tasks | `openspec validate` 检查变更和规格的结构，可以以非零状态退出，从 CI 脚本里也一样。 | [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)，公开仓库为 [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec) | 想要一个轻量变更文件夹，再加一道结构检查的团队 |
| [Kiro](https://specscore.md/zh-cn/vs/kiro/) | AWS 的智能体 IDE、CLI 和网页应用，用来起草规格 | `requirements.md` 使用 EARS，旁边还有 `design.md` 和 `tasks.md` | 设计之前，在 Kiro 里面做需求分析（Analyze Requirements）。功能规格页描述的就是这项产品内检查。 | IDE 和 CLI 是 AWS 内容（AWS Content），依据 [Kiro 许可证](https://kiro.dev/license/)（AWS 客户协议，AWS Customer Agreement）。 | 希望由 Kiro 来起草需求、设计和任务的人 |
| [Tessl](https://specscore.md/zh-cn/vs/tessl/) | 智能体技能的平台，外加一块规范驱动开发 tile | 技能是仓库里的文件。这块 tile 会写出 `.spec.md`，放在 `specs/` 下。 | 这块 tile 自带 `scripts/validate-specs.sh` 和 `scripts/check-spec-links.sh`。它的 GitHub Actions 用来 lint 这块 tile。 | tile 是 [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE)，位于 [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)。平台则是 Tessl 的产品。 | 想把代理技能做成团队标准，或想用这块 tile 先写规格再写代码的团队 |
| [BMAD Method](https://specscore.md/zh-cn/vs/bmad-method/) | 面向 AI 驱动开发的敏捷方法 | 简报、规格和架构，可以带进另一套工作流 | README 描述的是这套方法的产物和代理工作流。它没有写一种给 CI 用的格式检查器。 | [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE)，位于 [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)，该文件里另有一份商标声明。 | 想要一套按变更大小来用的敏捷代理方法的团队 |
| [Task Master AI](https://specscore.md/zh-cn/vs/task-master-ai/) | 给编码代理用的任务列表，从一份 PRD 解析而来 | PRD 散文，常见路径是 `.taskmaster/docs/prd.txt`，然后再生成任务 | README 描述的是把 PRD 解析成任务。它没有描述一种检查 PRD 的检查器。 | [MIT 再加一条 Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE)，位于 [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master) | 已经有一份 PRD、并想把它拆成任务的团队 |
| [CodeSpeak](https://specscore.md/zh-cn/vs/codespeak/) | 智能体工具包：把聊天里的意图变成映射到代码的需求 | 结构化需求放在产品里面，并映射到代码 | 网站说，每一次变更都会在产品里面强制这些需求。 | [服务条款](https://codespeak.dev/terms-of-service)（2026年3月3日生效）：CodeSpeak Ltd 保留该服务（Service），包括其源代码。产品网站没有公布工具包的源码仓库。 | 想从聊天里捕获意图，并让它一直映射到代码的团队 |
| [Datarim](https://specscore.md/zh-cn/vs/datarim/) | 给 Claude Code、Codex CLI、Cursor 和 Antigravity 用的迭代工作流 | `/dr-prd` 会写出一份 PRD。进行中的任务放在 `backlog.md`。 | `/dr-compliance` 和 `/dr-dream lint` 在你调用这些命令时运行。 | [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE)，位于 [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim) | 想要分阶段的命令，并在仓库里放一份待办的团队 |
| [Plain Markdown](https://specscore.md/zh-cn/vs/plain-markdown/) | 你自己撰写并提交的一份普通 Markdown 文件 | 任意 `.md` 文件，目录随你选 | 在你自己加上检查器之前，审查就是读一遍 | 没有产品，也没有许可证文件。这份文件的条款就是仓库的条款。 | 一则短注、一次短程试验，或你打算靠阅读来做的审查 |
| [SpecScore](https://specscore.md/zh-cn/) | 开放的规格格式，外加一支检查这些文件的 CLI | Markdown 加 YAML，放在一棵 `spec/` 目录树里 | [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) 在拉取请求上、以及向 main 的推送上运行 `specscore spec lint`。[/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) 是一次手动的 AI 评分，那条工作流不会跑它。 | 格式为 [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)，位于 [specscore/specscore](https://github.com/specscore/specscore)。CLI 为 [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)，位于 [specscore/specscore-cli](https://github.com/specscore/specscore-cli)。 | 需要规格文件在格式破掉时让 CI 失败的团队 |

## GitHub Spec Kit

[GitHub Spec Kit](https://github.github.io/spec-kit/) 是一套开放的工具包，把一条流程交给编码代理：Specify、Plan、Tasks、Implement、Converge。Spec Kit 文档首页标注的日期是 2026年9月28日，上面说每个阶段都会产出一份 Markdown 产物，下一阶段再去读它。

这些文件放在 `specs/` 下的功能目录里。[升级指南](https://github.github.io/spec-kit/upgrade.html) 读于 2026年10月30日，给出的路径例如 `specs/001-my-feature/spec.md`，旁边还有 `plan.md` 和 `tasks.md`。[智能体 SDD 参考](https://github.github.io/spec-kit/reference/agentic-sdd.html) 把 `/speckit.analyze` 写成一份报告：对照规格、计划和任务里的不一致，但不会改那些文件。`/speckit.clarify` 和 `/speckit.checklist` 是你在代理里另外运行的命令。文档首页还点出社区扩展，其中一个叫 CI Guard，用来添加合规门禁。

许可证是 [MIT](https://github.com/github/spec-kit/blob/main/LICENSE)，公开仓库为 [github/spec-kit](https://github.com/github/spec-kit)。Spec Kit 适合想要这套流程、也愿意把规格继续留成代理写下的那份 Markdown 的团队。与 SpecScore 的并排对比见 [SpecScore 与 Spec Kit](https://specscore.md/zh-cn/vs/spec-kit/)。

## OpenSpec

[OpenSpec](https://github.com/Fission-AI/OpenSpec) 来自 Fission-AI。每一次变更各自放在一个文件夹里，人和代理可以在写代码之前先对齐。[README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md) 读于 2026年10月30日，展示了 `openspec/changes/add-dark-mode/`，其中有 `proposal.md`、一个 `specs/` 目录、`design.md` 和 `tasks.md`。需求是纯 Markdown：一句 SHALL 陈述，再加一个 WHEN / THEN 场景。同一份 README 说它支持 30 种以上的 AI 助手。

`openspec validate` 检查变更和规格里的结构问题。[CLI 参考](https://openspec.dev/docs/cli) 读于 2026年10月30日，写明验证失败时以非零状态退出，并给出一段可供 CI 作业运行的 shell。这项检查查的是 OpenSpec 自己的变更和规格结构。

许可证是 [MIT](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)，公开仓库为 [Fission-AI/OpenSpec](https://github.com/Fission-AI/OpenSpec)。OpenSpec 适合想要那个变更文件夹、也想要那道结构检查的团队。见 [SpecScore 与 OpenSpec](https://specscore.md/zh-cn/vs/openspec/)。

## Kiro

[Kiro](https://kiro.dev/) 来自亚马逊云服务（AWS），是一套智能体开发环境：编辑器、CLI 和网页应用。[功能规格页](https://kiro.dev/docs/specs/feature-specs/) 更新于 2026年8月4日，带着一项功能走过需求、设计和任务。`requirements.md` 使用 EARS。`design.md` 和 `tasks.md` 放在旁边。快速规格（Quick Spec）可以把三步一次跑完，中间没有审批停点。

需求分析（Analyze Requirements）会在设计之前查找不一致、歧义、互相冲突的约束和缺口。这项分析跑在 Kiro 里面。功能规格页描述的就是这项产品内检查。

[Kiro 许可证](https://kiro.dev/license/) 读于 2026年10月30日，写明 IDE 和 CLI 是按 AWS 内容（AWS Content）许可的，依据是 AWS 客户协议（AWS Customer Agreement）或其他书面协议，以及 AWS 知识产权许可（AWS Intellectual Property License）。Kiro 适合希望由这款产品起草那三份文件的人。见 [SpecScore 与 Kiro](https://specscore.md/zh-cn/vs/kiro/)。句式见[EARS 需求语法](https://specscore.md/zh-cn/articles/ears-requirements/)。

## Tessl

[Tessl 的文档](https://docs.tessl.io/) 读于 2026年10月30日，描述的是一个管理智能体技能的开放平台：注册表、治理、评测以及相关控制。技能、规则和文档都是仓库里的文件。

另一份产物是规范驱动开发 tile，发布自 [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)，并列在 [Tessl 注册表](https://tessl.io/registry/tessl-labs/spec-driven-development) 上。tile 的 README 说，代理会写出 `.spec.md` 文件，放在 `specs/` 目录里，带有 YAML 前置元数据、`targets` 和 `[@test]` 链接。它还写了 `scripts/validate-specs.sh` 和 `scripts/check-spec-links.sh`，以及用来 lint 这块 tile 本身的 GitHub Actions。

这块 tile 的许可证是 [MIT](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE)，就在那个仓库里。文档把注册表平台写成 Tessl 的产品，并没有指向整个平台的公开仓库。Tessl 适合想把技能做成标准的团队，或想要这块 tile 那种先写规格再写代码的引导的团队。见 [SpecScore 与 Tessl](https://specscore.md/zh-cn/vs/tessl/)。

## BMAD Method

[BMAD Method](https://github.com/bmad-code-org/BMAD-METHOD) 仓库的 README 读于 2026年10月30日，描述的是一套面向 AI 驱动开发的敏捷方法。它说你可以端到端使用这套方法，也可以把它的简报、规格和架构带进你已经有的工作流。那里点名的稳定线是 v6.12。v7 被写成 main 分支上的预览。项目把名字拼成 BMad；仓库名是 BMAD-METHOD。

README 以那些规划产物、以及产出它们的代理技能为中心。它没有记载一条命令，用来在 CI 里检查一套固定的规格模式。

许可证是 [MIT](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE)，位于 [bmad-code-org/BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)。那份许可证文件里还有一份关于 BMad 的商标声明。这套方法适合想要这条敏捷循环、并把规格留在那些简报和规格里的团队。见 [SpecScore 与 BMAD Method](https://specscore.md/zh-cn/vs/bmad-method/)。

## Task Master AI

[Task Master AI](https://github.com/eyaltoledano/claude-task-master) 是给 AI 编码代理用的任务列表。README 读于 2026年10月30日，建议准备一份 PRD，路径常常是 `.taskmaster/docs/prd.txt`，再用 `task-master parse-prd` 把那段散文变成任务。[文档](https://tryhamster.com/docs/taskmaster) 涵盖任务结构、依赖和标签。

README 把 PRD 当作输入，把任务列表当作代理据以工作的东西。它没有描述一种检查器，用来检查 PRD 的措辞或结构。

许可证是 [MIT 再加一条 Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE)，位于 [eyaltoledano/claude-task-master](https://github.com/eyaltoledano/claude-task-master)。README 说，你可以用 Task Master 来构建产品；把 Task Master 本身卖掉，或把它做成托管服务来提供，则不在这项授权之内。它适合想把 PRD 拆成任务的团队。见 [SpecScore 与 Task Master AI](https://specscore.md/zh-cn/vs/task-master-ai/)。

## CodeSpeak

[CodeSpeak](https://codespeak.dev/) 的网站读于 2026年10月30日，描述的是一套智能体工程工具包。它从代理聊天里捕获意图，把意图变成映射到代码的结构化需求，并说每一次变更都会强制这些需求。网站还说，在完整产品发布之前，有一个网页工具可以从聊天里找回意图。

[服务条款](https://codespeak.dev/terms-of-service) 于 2026年3月3日生效，写明 CodeSpeak Ltd 保留该服务（Service），包括其软件和源代码。产品网站没有公布这套工具包的源码仓库，因此本页不为它指名一种软件许可证。

CodeSpeak 适合想在那款产品里面从对话捕获需求、并让需求一直映射到代码的团队。见 [SpecScore 与 CodeSpeak](https://specscore.md/zh-cn/vs/codespeak/)。

## Datarim

[Datarim](https://github.com/Arcanada-one/datarim) 的 README 带有 4.9.0 版本徽章，读于 2026年10月30日，描述的是一套给 Claude Code、Codex CLI、Cursor 和 Google Antigravity 用的迭代工作流。`/dr-prd` 会生成一份 PRD。进行中的任务放在 `backlog.md`，完成的历史放在 `backlog-archive.md`。

`/dr-compliance` 在你运行该命令时，对照 PRD 检查一次实现。`/dr-dream lint` 会对知识库做健康检查，查找矛盾、孤儿、断链、过期内容和重复项。这些都是工作流里的命令。

许可证是 [MIT](https://github.com/Arcanada-one/datarim/blob/main/LICENSE)，位于 [Arcanada-one/datarim](https://github.com/Arcanada-one/datarim)。Datarim 适合想在 README 点名的那些代理上使用这些分阶段命令的团队。见 [SpecScore 与 Datarim](https://specscore.md/zh-cn/vs/datarim/)。

## Plain Markdown

纯 Markdown 就是把规格写成一份普通的 `.md` 文件：一个标题，若干条目，提交到你选定的地方。没有模式。在你自己加上检查器之前，审查就是有人去读这份文件。

没有产品，也没有可以链接的许可证文件。这份文件的条款，就是你给仓库采用的那份许可证。纯 Markdown 适合一则短注、一次短程试验，或打算靠阅读散文来审查的团队。见 [SpecScore 与纯 Markdown](https://specscore.md/zh-cn/vs/plain-markdown/)。

## SpecScore

[SpecScore](https://specscore.md/zh-cn/) 是规格的一种格式——功能、需求和验收标准写成带 YAML 的 Markdown——外加一支检查这些文件的 CLI。格式位于 [specscore/specscore](https://github.com/specscore/specscore)。CLI 位于 [specscore/specscore-cli](https://github.com/specscore/specscore-cli)。

怎样写出代理能够核验的标准，见[如何编写验收标准](https://specscore.md/zh-cn/articles/acceptance-criteria/)。

含需求、验收标准、计划和任务的 Markdown 功能规格模板见[Markdown PRD 模板](https://specscore.md/zh-cn/articles/feature-spec-template/)。

用 Claude Code 和 Cursor 做规范驱动开发：功能文件、代理指令文件，以及循环中的 `specscore spec lint`，见 [用 Claude Code 和 Cursor 做规范驱动开发](https://specscore.md/zh-cn/articles/claude-code-specs/)。

如何在持续集成里运行这个 linter，见[在 CI 中 lint 规格](https://specscore.md/zh-cn/articles/lint-specs-in-ci/)。

在本网站的仓库里，[dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) 会安装那支 CLI，并在拉取请求上、以及向 main 的推送上运行 `specscore spec lint`。规格若把格式写坏，那项作业就会失败。[/score](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md) 技能是一次手动的 AI 评分：你提出要求时，它会重新运行配置好的评审；dogfood 工作流不会去调用它。

格式许可证是 [CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)，位于 [specscore/specscore](https://github.com/specscore/specscore)。CLI 许可证是 [Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)，位于 [specscore/specscore-cli](https://github.com/specscore/specscore-cli)。SpecScore 适合这样的团队：标题、链接或状态错了，规格就要让 CI 失败，不论文件是哪个代理写的。`openspec validate` 是这里其他工具里最接近的结构检查；它检查的是 OpenSpec 自己的变更形状。各篇对比从 [/vs/](https://specscore.md/zh-cn/vs/) 开始。

## 怎么选。

若你要的是一条有引导的流程，以及可以在拉取请求里审查的 Markdown，就选 GitHub Spec Kit、OpenSpec、BMAD Method 或 Datarim。若你要那款产品来起草 EARS 需求，就选 Kiro。若 PRD 应当变成任务列表，就选 Task Master AI。若意图应当在那款产品里面从聊天捕获，就选 CodeSpeak。若问题在于代理技能，规格 tile 只是可选的引导，就选 Tessl。

若规格文件本身必须让 CI 失败，就选 SpecScore。本仓库里的检查是 `specscore spec lint`，写在 [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) 里。上面清单里的某条工作流，仍可以是规格被写下来的方式。

## 来源。

读于 2026年10月30日，除非某一页自己印了更新日期。价格和方案名称会变动，因此略去。

- [GitHub Spec Kit 文档（页面日期 2026年9月28日）](https://github.github.io/spec-kit/)
- [Spec Kit——智能体 SDD 参考](https://github.github.io/spec-kit/reference/agentic-sdd.html)
- [Spec Kit——升级指南（specs/ 路径）](https://github.github.io/spec-kit/upgrade.html)
- [github/spec-kit——MIT 许可证](https://github.com/github/spec-kit/blob/main/LICENSE)
- [Fission-AI/OpenSpec——README](https://github.com/Fission-AI/OpenSpec/blob/main/README.md)
- [OpenSpec CLI 参考——openspec validate](https://openspec.dev/docs/cli)
- [Fission-AI/OpenSpec——MIT 许可证](https://github.com/Fission-AI/OpenSpec/blob/main/LICENSE)
- [Kiro 文档——功能规格与 EARS（更新于 2026年8月4日）](https://kiro.dev/docs/specs/feature-specs/)
- [Kiro——许可证](https://kiro.dev/license/)
- [Tessl 文档——Tessl 是什么？](https://docs.tessl.io/)
- [tesslio/spec-driven-development-tile](https://github.com/tesslio/spec-driven-development-tile)
- [Tessl 规范驱动开发 tile——MIT 许可证](https://github.com/tesslio/spec-driven-development-tile/blob/main/LICENSE)
- [bmad-code-org/BMAD-METHOD——README](https://github.com/bmad-code-org/BMAD-METHOD)
- [BMAD-METHOD——MIT 许可证](https://github.com/bmad-code-org/BMAD-METHOD/blob/main/LICENSE)
- [eyaltoledano/claude-task-master——README](https://github.com/eyaltoledano/claude-task-master)
- [Task Master——MIT 再加 Commons Clause](https://github.com/eyaltoledano/claude-task-master/blob/main/LICENSE)
- [CodeSpeak](https://codespeak.dev/)
- [CodeSpeak——服务条款（2026年3月3日生效）](https://codespeak.dev/terms-of-service)
- [Arcanada-one/datarim——README（4.9.0 徽章）](https://github.com/Arcanada-one/datarim)
- [Datarim——MIT 许可证](https://github.com/Arcanada-one/datarim/blob/main/LICENSE)
- [specscore/specscore——dogfood.yml（specscore spec lint）](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml)
- [specstudio-skills——/score 技能（手动 AI 评分）](https://github.com/specscore/specstudio-skills/blob/main/skills/score/SKILL.md)
- [specscore/specscore——CC BY 4.0](https://github.com/specscore/specscore/blob/main/LICENSE)
- [specscore/specscore-cli——Apache-2.0](https://github.com/specscore/specscore-cli/blob/main/LICENSE)