SkillBenchmark：用盲测+置信区间回答”这个Skill到底有没有用”

Skill 生态现在有几万个 Skill，但最核心的问题没人回答：这个 Skill 到底有没有用？

大多数 Skill 的自我介绍都是”用了都说好”——但这不可证伪。你怎么知道输出变好是因为 Skill，还是因为模型今天心情好？

Ties Petersen 做了个很硬核的东西，叫 SkillBenchmark。它做的事情本质上是医学里的随机对照试验：同一个任务，跑 N 次有 Skill 的版本，再跑 N 次没有 Skill 的版本，然后让一个不知道哪个是哪个的 judge 模型打分，最后用置信区间来判定差异是否显著。

具体三步走：

• Runner LLM 拿任务跑两次——一次带 SKILL.md 作为 system prompt，一次不带。其他参数（模型、温度、max_tokens）完全相同。
• Blind Judge 给两份输出打分，评分依据是一份 rubric（评分标准）。Judge 不知道哪份用了 Skill，消除评分偏差。
• Welch’s t-interval 分别对”有 Skill”和”无 Skill”两组分数计算 95% 置信区间，再算 delta 的 CI。如果两组 CI 不重叠，才算有统计显著差异。

这个方法最妙的地方是 judge bias 被自动消除——因为 judge 盲评两份，偏差方向相同，delta 抵消了。你不需要 judge 绝对准确，只需要它相对一致。

举一个官方示例：评测”Caveman”这个 Skill（强制 AI 用极简语言输出，节省 token）。跑完三个任务，结果让人清醒：

• Commit message：93.5±1.5 vs 89.9±2.3，delta +3.6±2.8（CI 重叠，差异不显著）
• Python bug 解释：99.5±0.5 vs 100.0±0.0，delta -0.5±0.5（完全没区别）
• User-facing error message：89.7±3.2 vs 87.7±2.5，delta +2.0±4.0（CI 宽到几乎没有意义）

结论：所有任务 CI 都重叠，无法确认有任何质量提升。而且这个 Skill 还把 token 消耗翻了两到四倍。

这个框架对 Skill 开发者意义重大：以后不能光靠感觉说”我的 Skill 有用”，得拿数据。配置简单，config.yml 里改个 skill_path、number_of_runs、runner_model，然后 python run.py 出报告，支持 JSON + Markdown 输出。

下一步规划是支持多轮 agent 环境下的评测（Tool Use + Memory），那时候才能真正测出 Skill 在复杂 agent 流程里的价值。

GitHub：TiesPetersen/SkillBenchmark

GitHub: https://github.com/TiesPetersen/SkillBenchmark