评审者真正问过的问题。

spec-kit 是一种方法论——写规格说明的流程。SpecScore 是你所写规格说明的存储格式，外加 一个用于查询和编辑的 CLI。两者可以组合：spec-kit 能产生 SpecScore 文件，一个以 SpecScore 格式输出的 spec-kit 扩展 正在开发中。

需要流程时选 spec-kit。需要 AI 代理无需读取仓库中每个文件 就能进行 lint、查询和变更的规格说明时，选 SpecScore。 两者都要的时候，就都用。

理念相近。三者都是引导 AI 代理走完 ideate → specify → plan → implement 的技能库。差异在机制上，不在理念上。

SpecStudio Skills 以 SpecScore 格式 （定义好的 Markdown + YAML 结构）写出产物，并通过specscore CLI 完成查询、lint 和状态变更。 Superpowers 和 agent-skills 主要通过技能文本直接读写文件。

当 token 消耗很重要时，选 SpecStudio Skills——CLI 通过一次 调用就能给出 "所有带未决问题的开放 Feature"这样的结构化答案，而基于文件的技能要回答同样的问题， 就得读 N 份文档。

技能可以读写文件。但它们无法可靠地做到：

• 在整棵规格树上保证引用完整性（链接能解析、ID 唯一、索引保持同步）；
• 不读取每个文件就返回一份过滤后的"带未决问题的开放 Feature"列表；
• 在每个产物上、在正确的时机、变更正确的状态字段。

CLI 让代理在每项任务上只需一次干净的调用——就像jq 让你只需一次干净的调用就能查询 JSON。 单靠技能则消耗更多 token、更容易漂移、还经常忘记更新索引。

"Score"可以有两种解读，且都是有意为之。

Partitura（总谱）。一份结构化的需求总谱—— 就像乐谱组织声部、声线和时序那样。打开一棵 SpecScore 树， 你应该能像指挥读总谱那样去读它：层级、声部、引用，一目了然。

字面意义上的质量评级。CLI 检查器是 确定性的分数（规格的结构是否站得住？）。/score 技能是 AI 评判的分数——每个产物的 A–F 就绪度评级，并附给作者 逐项反馈。名字里"Score"的那一半，从一种愿景变成了 工具实际产出的能力。

实测的并排对比正在进行中，会在 Habr 文章前发布——同一项任务 （"我接下来该做什么？"）跑两次：一次是普通代理读文档， 一次是同一个代理调用 SpecScore CLI。两边都给出 token 计数 和响应时间。

在那些数字落地之前，主张是结构层面的：向 CLI 询问开放 Feature 和未决问题的代理，得到的是一份小而结构化的回应； 没有 CLI 的同一个代理则要读 N 份文档——N 通常以十计。 CLI 的接口正是为了避开这种扇出读取而设计的。