SpecScore vs Spec Kit
它们运作在不同的层面。Spec Kit 是一套工作流—— 一个引导代理从想法走向实现的有序流程。 SpecScore 是规范书写所用的格式，外加一个用于 lint、查询和追溯它们的 CLI。 Spec Kit 可以产出 SpecScore 文件。
两者的共同点。
Spec Kit 的优势。
Spec Kit是来自 GitHub Next 的规范驱动开发工作流。
完整、有主见的流程
Spec Kit 给你整条主线：constitution → specify → plan → tasks → implement。 每一步都有一个斜杠命令和一段提示词，旨在让代理保持在轨道上。 如果你想要一套流程，Spec Kit 直接递给你一套。
强大的分发与影响力
背靠 GitHub Next，拥有庞大的社区和不断增长的扩展库。 对许多开发者而言，Spec Kit 是他们接触到的第一个规范驱动工作流。
与代理无关的命令
Spec Kit 的命令在 Claude Code、Cursor、Copilot 等之间通用—— 无论你运行哪一个，工作流都能驱动代理。
功能对比。
这些工具回答的是不同的问题，所以这张表对比的是角色，而非胜负。
| 能力 | Spec Kit | SpecScore |
|---|---|---|
| 主要角色 | 工作流 / 方法论 | 存储格式 + CLI |
| 规范产出 | 自由格式 Markdown | Markdown + YAML frontmatter（结构化） |
| 规范 linting | 无 | 内容质量 — 模糊动词、缺失验收标准、悬空引用 |
| 需求 / 验收标准 ID | 无 | 机器可寻址的 ID（REQ: slug） |
| 生命周期状态 | 隐式（工作流步骤） | 强制执行 — Draft → Approved → Implementing → Stable → Deprecated |
| 代码到规范的可追溯性 | 无 | specscore: 注解 + Verifies: 提交尾注 |
| 从 CLI 查询规范 | 脚手架（specify、plan、tasks） | 查询 API — feature list / show / deps、lint、code refs |
| 运行时依赖 | Python | 无 — 单个 Go 二进制文件 |
| CI 集成 | 运行工作流 | specscore lint 返回非零退出码，支持 pre-commit 钩子 |
| 关系 | 它们可以组合 — Spec Kit 可以产出 SpecScore 文件 | |
| 许可证 | MIT | MIT |
SpecScore 增添了什么。
产出是可 lint 的
Spec Kit 产出自由格式 Markdown——无论好坏，它都会交付。 SpecScore 分两层检查结果：lint确定性地校验每个需求都有验收标准、交叉引用可解析、 状态转换合法——而 AI 审查器（/review、/score）则捕获含糊的 标准和模糊的动词。
$ specscore lint checkout/apply-discount.md ✗ R3 no acceptance criteria ✗ link "Related Feature: discount-tiers" not found
产出是可查询的
Spec Kit 写文件；要回头读它们就得打开它们。SpecScore 的规范能从 CLI 回答问题：specscore feature list、feature deps、code refs——这样代理无需 阅读仓库中的每个文件即可导航规范图谱。
每个需求都有 ID
Spec Kit 通过散文引用需求。SpecScore 分配基于 slug 的 ID（REQ: slug-format）和验收标准 ID，在重命名、 重构和代理交接时保持稳定。
生命周期是强制的
在 Spec Kit 中，规范的阶段取决于你处在工作流的何处。 在 SpecScore 中，生命周期是一个强制执行的状态字段——Draft → Approved → Implementing → Stable → Deprecated——由 lint 验证，并通过 git 钩子或 CI 中的specscore change-status 进行状态转换。
代码可追溯回规范
Spec Kit 没有可追溯性机制。SpecScore 拥有specscore: 源注解和 Verifies:提交尾注——运行 specscore code refs 即可确定性地回答 "哪些代码实现了这个需求？"。
无运行时依赖
SpecScore 是单个 Go 二进制文件——无需安装任何运行时。 可直接用于 Go、Rust、Python、Java 或 JavaScript 项目， 无需在工具链中引入任何东西。
何时使用哪个。
以下场景适合使用 Spec Kit……
- 你想要一套有引导、有主见的流程，从想法走向实现。
- 你的团队需要明确的 specify / plan / tasks 步骤所带来的纪律。
- 你正在团队范围内统一驱动代理的方式。
以下场景适合使用 SpecScore……
- 你需要代理无需阅读每个文件即可 lint、查询和修改的规范。
- 你需要带有确定性答案的代码到规范可追溯性。
- 你正在构建具有大量功能和生命周期转换的大型系统。
- 你想要零运行时依赖——一个二进制文件，无需任何语言工具链。
- 你需要在 CI 中设置返回非零退出码的规范质量门禁，就像 ESLint 或
go vet。
SpecScore 扩展 Spec Kit——而非取代它。
Spec Kit 是产出规范的流程；SpecScore 是该规范可以书写所用的格式。 一个能输出 SpecScore 格式的 Spec Kit 扩展正在开发中—— 运行 Spec Kit 工作流，在另一端得到可 lint、可查询、可追溯的规范。
为流程选择 Spec Kit。为工件选择 SpecScore。当你两者都想要时，两者一起用。
反馈
本对比基于公开可用的文档和源代码。发现不准确或过时的信息？请 提交勘误 issue. 希望我们将 SpecScore 与其他工具进行对比？请 提交请求.