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

这篇规范驱动开发工具对照涵盖 GitHub Spec Kit、OpenSpec、Kiro、Tessl、BMAD Method、Task Master AI、CodeSpeak、Datarim、纯 Markdown，以及 SpecScore。公开页面和仓库读于 2026年10月30日。命令、文件怎么摆，以及产品实际检查什么，之后都可能变；页底的来源写明每一条说法出自哪一页。

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

GitHub Spec Kit

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

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

许可证是 MIT，公开仓库为 github/spec-kit。Spec Kit 适合想要这套流程、也愿意把规格继续留成代理写下的那份 Markdown 的团队。与 SpecScore 的并排对比见 SpecScore 与 Spec Kit。

OpenSpec

OpenSpec 来自 Fission-AI。每一次变更各自放在一个文件夹里，人和代理可以在写代码之前先对齐。README 读于 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 参考 读于 2026年10月30日，写明验证失败时以非零状态退出，并给出一段可供 CI 作业运行的 shell。这项检查查的是 OpenSpec 自己的变更和规格结构。

许可证是 MIT，公开仓库为 Fission-AI/OpenSpec。OpenSpec 适合想要那个变更文件夹、也想要那道结构检查的团队。见 SpecScore 与 OpenSpec。

Kiro

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

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

Kiro 许可证 读于 2026年10月30日，写明 IDE 和 CLI 是按 AWS 内容（AWS Content）许可的，依据是 AWS 客户协议（AWS Customer Agreement）或其他书面协议，以及 AWS 知识产权许可（AWS Intellectual Property License）。Kiro 适合希望由这款产品起草那三份文件的人。见 SpecScore 与 Kiro。句式见EARS 需求语法。

Tessl

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

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

这块 tile 的许可证是 MIT，就在那个仓库里。文档把注册表平台写成 Tessl 的产品，并没有指向整个平台的公开仓库。Tessl 适合想把技能做成标准的团队，或想要这块 tile 那种先写规格再写代码的引导的团队。见 SpecScore 与 Tessl。

BMAD Method

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

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

许可证是 MIT，位于 bmad-code-org/BMAD-METHOD。那份许可证文件里还有一份关于 BMad 的商标声明。这套方法适合想要这条敏捷循环、并把规格留在那些简报和规格里的团队。见 SpecScore 与 BMAD Method。

Task Master AI

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

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

许可证是 MIT 再加一条 Commons Clause，位于 eyaltoledano/claude-task-master。README 说，你可以用 Task Master 来构建产品；把 Task Master 本身卖掉，或把它做成托管服务来提供，则不在这项授权之内。它适合想把 PRD 拆成任务的团队。见 SpecScore 与 Task Master AI。

CodeSpeak

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

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

CodeSpeak 适合想在那款产品里面从对话捕获需求、并让需求一直映射到代码的团队。见 SpecScore 与 CodeSpeak。

Datarim

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，位于 Arcanada-one/datarim。Datarim 适合想在 README 点名的那些代理上使用这些分阶段命令的团队。见 SpecScore 与 Datarim。

Plain Markdown

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

没有产品，也没有可以链接的许可证文件。这份文件的条款，就是你给仓库采用的那份许可证。纯 Markdown 适合一则短注、一次短程试验，或打算靠阅读散文来审查的团队。见 SpecScore 与纯 Markdown。

SpecScore

SpecScore 是规格的一种格式——功能、需求和验收标准写成带 YAML 的 Markdown——外加一支检查这些文件的 CLI。格式位于 specscore/specscore。CLI 位于 specscore/specscore-cli。

怎样写出代理能够核验的标准，见如何编写验收标准。

含需求、验收标准、计划和任务的 Markdown 功能规格模板见Markdown PRD 模板。

用 Claude Code 和 Cursor 做规范驱动开发：功能文件、代理指令文件，以及循环中的 specscore spec lint，见 用 Claude Code 和 Cursor 做规范驱动开发。

如何在持续集成里运行这个 linter，见在 CI 中 lint 规格。

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

格式许可证是 CC BY 4.0，位于 specscore/specscore。CLI 许可证是 Apache-2.0，位于 specscore/specscore-cli。SpecScore 适合这样的团队：标题、链接或状态错了，规格就要让 CI 失败，不论文件是哪个代理写的。openspec validate 是这里其他工具里最接近的结构检查；它检查的是 OpenSpec 自己的变更形状。各篇对比从 /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 里。上面清单里的某条工作流，仍可以是规格被写下来的方式。

来源。

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

• GitHub Spec Kit 文档（页面日期 2026年9月28日）
• Spec Kit——智能体 SDD 参考
• Spec Kit——升级指南（specs/ 路径）
• github/spec-kit——MIT 许可证
• Fission-AI/OpenSpec——README
• OpenSpec CLI 参考——openspec validate
• Fission-AI/OpenSpec——MIT 许可证
• Kiro 文档——功能规格与 EARS（更新于 2026年8月4日）
• Kiro——许可证
• Tessl 文档——Tessl 是什么？
• tesslio/spec-driven-development-tile
• Tessl 规范驱动开发 tile——MIT 许可证
• bmad-code-org/BMAD-METHOD——README
• BMAD-METHOD——MIT 许可证
• eyaltoledano/claude-task-master——README
• Task Master——MIT 再加 Commons Clause
• CodeSpeak
• CodeSpeak——服务条款（2026年3月3日生效）
• Arcanada-one/datarim——README（4.9.0 徽章）
• Datarim——MIT 许可证
• specscore/specscore——dogfood.yml（specscore spec lint）
• specstudio-skills——/score 技能（手动 AI 评分）
• specscore/specscore——CC BY 4.0
• specscore/specscore-cli——Apache-2.0