SpecScore vs Plain Markdown
大多数团队已经有了"规范"——以 docs 文件夹里的临时 Markdown、Notion 页面或 Jira 工单的形式存在。它免费、它早已就位、它能用。SpecScore 就是同样的 Markdown，外加 AI 代理可以 lint、查询并追溯回代码的结构。
两者的共同点。
默认方案的优势。
Plain Markdown、Notion 和 Jira 才是真正的默认选择。它们当之无愧。
零学习曲线
没有 schema、没有必填字段、流程中没有 CLI。打开一个文件，开始打字。 对于一次性的笔记或微型项目来说，这恰到好处——你不需要的结构只是摩擦。
早已安装就位
你的团队已经在用 Notion、Confluence 或一个 docs/ 文件夹。 无需采用任何新东西，无需迁移。摩擦最小的选项就是你已经在用的那个。
普遍可移植
Plain Markdown 在任何地方都能打开，并且比任何工具都更长久。SpecScore 正是建立在 这一特性之上——这也是为什么 SpecScore 同样采用 Markdown，而非数据库。
功能对比。
差别不在于文件本身——而在于代理能用它做什么。
| 能力 | Plain Markdown / Notion | SpecScore |
|---|---|---|
| 格式 | 自由格式 Markdown / 文档 | Markdown + YAML frontmatter（结构化） |
| 需求存放在哪里 | Jira、Notion、Slack、某人的脑子里 | 在仓库中，紧挨着代码 |
| "这份规范完整吗？" | 由人阅读并判断 | specscore lint — 自动完成 |
| 歧义检测 | 无 — 模糊动词悄无声息地发布 | 标记模糊动词、缺失的验收标准、悬空引用 |
| 需求 / 验收标准 ID | 无 | 机器可寻址的 ID（REQ: slug） |
| 生命周期状态 | 隐式，如果有跟踪的话 | 强制执行 — Draft → Approved → Implementing → Stable |
| 代码到规范的可追溯性 | 无 | specscore: 注解 + Verifies: 尾注 |
| 代理导航 | 读取每个文件才能找到任何东西 | 从 CLI 查询规范图谱 |
| CI 质量门禁 | 无 | specscore lint 返回非零退出码，像 linter 一样 |
| 学习曲线 | 无 | 需要学习一种格式（可渐进） |
| 成本 / 许可证 | 免费 | 免费、开源 |
SpecScore 更进一步之处。
歧义被捕获，而非被解读
使用自由格式规范时，每次代理交互都从解读开始—— "登录应该能用"在正确与貌似合理但错误之间是一场抛硬币。 SpecScore 的 lint 会在代理据此行动之前标记出模糊的动词和缺失的 验收标准。
$ specscore lint auth/login.md ✗ R1 "should work" — unmeasurable ✗ R1 no acceptance criteria
误解不再层层累积
一个代理误读了需求，第二个在其基础上构建，第三个又依赖前两者—— 而你在三个代理之后才察觉。结构化的验收标准让每个代理拥有相同的 通过/失败条件，因此解读不会在它们之间发生漂移。
代码可追溯回规范
纯文档与实现它们的代码之间没有任何链接。SpecScore 添加了specscore: 源注解和 Verifies:提交尾注——specscore code refs 能确定性地回答"哪些代码 实现了这个需求？"。
一份规范胜过四十个工单
一位新队友（或一个全新的代理）只需阅读一份包含全部上下文的功能规范， 而不必从四十个 Jira 工单和一条 Slack 讨论串中重建意图。
代理查询，而非反复阅读
在 docs 文件夹里，要找出"哪些正在进行中？"意味着逐个打开文件。 在 SpecScore 中，那就是 specscore feature list——规范图谱 从 CLI 给出答案，因此代理不必为反复阅读仓库而消耗上下文。
质量在 CI 中强制执行
自由格式规范没有门禁——写了一半的规范与完整的规范一样容易合并。specscore lint 在出现问题时返回非零退出码， 就像 ESLint 或 go vet 守护代码一样。
何时使用哪个。
以下场景适合 Plain Markdown……
- 这是一次性的笔记、一次探针，或一个小到不需要结构的项目。
- 不会有 AI 代理基于该文档构建——人读了就明白。
- 你在记录一个粗略的想法，而非某人将要实现的需求。
以下场景适合使用 SpecScore……
- AI 代理基于规范构建——歧义会变成错误的代码。
- 多个代理或多人依赖同一批需求。
- 你需要知道哪些代码实现了哪个需求。
- "这份规范完成了吗？"应由工具回答，而非靠开会。
- 项目大到反复阅读所有内容已经无法扩展。
让你已有的规范进阶。
你无需转换你的待办列表，也无需更换工具。挑选你的下一个功能， 为它写一份 SpecScore 规范，运行 specscore lint——看看它是否 捕获到你的工单遗漏的东西。实现它时添加 specscore: 注解。 只有在它真正有帮助时，才扩展到下一个 sprint。
Plain Markdown 是入口匝道。SpecScore 是它进阶后的样子。
反馈
本对比基于公开可用的文档和源代码。发现不准确或过时的信息？请 提交勘误 issue. 希望我们将 SpecScore 与其他工具进行对比？请 提交请求.