SpecScore vs OpenSpec
两者都将规范以 Markdown 形式放在代码旁边，可供 AI 代理读取。它们解决的问题不同：OpenSpec 组织规范并生成代理指令；SpecScore 对规范内容进行 linting、强制执行生命周期，并将代码追溯到需求。
两者的共同点
OpenSpec 的优势
最广泛的代理支持
OpenSpec 通过生成技能文件支持 29 个 AI 编码代理 — Claude、Cursor、Copilot、Gemini、Windsurf、Cline 等。如果你的代理在支持列表中，OpenSpec 无需任何配置即可集成。
极低的上手门槛
npm install -g @fission-ai/openspec && openspec init 即可开始编写规范。无需学习 schema，无需必填的 frontmatter。设计上追求零摩擦 — 尤其适合现有项目。
清晰的变更增量模型
OpenSpec 的 ADDED / MODIFIED / REMOVED 规范演进格式设计精良。每个变更是一个包含提案、增量规范和任务的文件夹 — 一种结构化的修改提案方式。
功能对比
| 能力 | OpenSpec | SpecScore |
|---|---|---|
| 规范格式 | Markdown（无 frontmatter） | Markdown + YAML frontmatter |
| 规范 linting | 仅文件结构 | 内容质量 — 模糊动词、缺失验收标准、悬空引用 |
| 需求 ID | 无（通过标题引用） | 基于 slug（REQ: slug-format） |
| 验收标准 ID | 无 | 机器可寻址的 ID |
| 生命周期状态 | 隐式（基于文件位置） | 强制执行 — Draft → Under Review → Approved → Implementing → Stable → Deprecated |
| 代码到规范的可追溯性 | 无 | specscore: 注解 + Verifies: 提交尾注 |
| 子功能 | 否 | 支持（嵌套目录） |
| 交叉引用 | 无正式机制 | 依赖关系、源 Idea、计划引用 |
| CI 集成 | 基础（openspec validate） | specscore lint 可配置严重级别，支持 pre-commit 钩子 |
| 代理支持 | 29 个代理 | 以 Claude Code 为主 + CLI 支持任何代理 |
| Schema 自定义 | 支持（schema.yaml、fork/init） | 固定 schema（设计上保持一致性） |
| 变更提案 | 增量模型（ADDED/MODIFIED/REMOVED） | 变更请求 Idea + 提案 |
| 运行时依赖 | Node.js 20.19+ | 无 — 单个 Go 二进制文件 |
| 许可证 | MIT | MIT |
SpecScore 更进一步之处
校验不止于文件结构
OpenSpec 的 validate 检查文件结构 — 文件是否存在、是否包含正确的章节。SpecScore 检查得更多，分为两层：lint 确定性地校验内容关系 — 每个需求都有验收标准、交叉引用可解析、状态转换合法 — 而 AI 审查器（/review、/score）则捕获任何 linter 都无法发现的问题：含糊的验收标准和模糊的动词。
$ specscore lint checkout/apply-discount.md ✗ R3 no acceptance criteria ✗ link "Related Feature: discount-tiers" not found
每个需求都有机器可读的 ID
OpenSpec 通过标题引用需求 — 重命名时容易出错。SpecScore 分配基于 slug 的 ID（REQ: slug-format）和验收标准 ID，在重命名、重构和代理交接时保持稳定。
生命周期是强制的，而非隐含的
在 OpenSpec 中，规范的生命周期由文件位置决定：specs/（当前）、changes/（提议中）、archive/（已完成）。在 SpecScore 中，生命周期是一个强制执行的状态字段 — Draft → Under Review → Approved → Implementing → Stable → Deprecated — 由 lint 验证，通过 git 钩子或 CI 中的 specscore change-status 进行状态转换。
代码可追溯到规范
OpenSpec 没有可追溯性机制。SpecScore 在代码注释中使用 specscore: 源注解和 Verifies: 提交尾注。运行 specscore code refs 即可确定性地回答"哪些代码实现了这个需求？"
无运行时依赖
OpenSpec 需要 Node.js 20.19+。SpecScore 是单个 Go 二进制文件 — 无运行时依赖、无 node_modules。可直接用于 Go、Rust、Python、Java 项目，无需在工具链中引入 Node。
可组合的工件层级
OpenSpec 的规范按领域平铺。SpecScore 具有类型化层级结构：Idea 晋升为 Feature，Feature 包含需求和验收标准，Plan 引用验收标准，Task 引用 Plan。所有关系均可通过 CLI 进行机器导航。
何时使用哪个
以下场景适合从 OpenSpec 开始……
- 你使用 Cursor、Copilot 或非 Claude 代理，需要开箱即用的集成。
- 你首次为现有代码库添加规范，希望零摩擦上手。
- 你的团队更看重 schema 灵活性而非强制约束。
以下场景适合使用 SpecScore……
- 你需要规范质量保障 — lint 在代理浪费 token 之前就能捕获歧义。
- 你需要代码到规范的可追溯性 — "哪些代码实现了这个需求？"能得到确定性答案。
- 你正在构建具有大量功能、子功能和生命周期转换的大型系统。
- 你需要零运行时依赖 — 单个二进制文件，无需 Node.js。
- 你需要在 CI 中设置规范质量门禁 —
specscore lint在检查失败时返回非零退出码，与 ESLint 或go vet一致。
两者并不互斥
SpecScore 可以对 OpenSpec 的 spec.md 文件进行 lint。从 OpenSpec 起步的团队可以在不迁移的情况下添加 SpecScore 的质量层 — 对现有规范进行 lint，在需要时添加可追溯性，在团队扩大时强制执行生命周期。
OpenSpec 是一个优秀的入门通道。SpecScore 是质量护栏。
反馈
本对比基于公开可用的文档和源代码。发现不准确或过时的信息？请 提交勘误 issue. 希望我们将 SpecScore 与其他工具进行对比？请 提交请求.