SkillsBench vs 我们自建的 skillrank：复盘

明天准备认真看一下 skillsbench.ai/leaderboard，对比一下我们自己设计的 skillrank。Leaderboard 这个形式我们抓对了，但 SkillsBench 还多做了几件关键的事：

  • With / without skill 对比——同一个 agent、同一个 task，加 skill 和不加 skill 各跑一次。
  • 记录每次跑了多长时间、消耗了多少 tokens。
  • Task 不是大类，而是一个个具体小任务，每个 task 配一份 instruction、verifier、results、trajectory。

错误 1：没先搜「谁已经做了这个」

这是最大的错误。第一天哪怕花 30 分钟搜「AI skill evaluation benchmark」或「skill leaderboard for agents」，就会发现 SkillsBench——2026 年就有论文、有 GitHub、有 leaderboard。我们等于从零造了一个劣质版本。

教训：Build before search = 浪费。应该先花时间搜竞品，再决定 fork、contribute 还是自己做。

错误 2：用 LLM-as-judge 代替真执行

我们的「real execution」其实不是真执行。是把 SKILL.md 丢给一个 LLM，让它写一段回答。SkillsBench 是真的让 agent 在 Docker 里跑代码、编译 Maven 项目、处理 .pcap 文件。

  • 我们测的是：「qwen-turbo 读了这份文档后写的回答好不好」。
  • SkillsBench 测的是：「Claude Code 用了这个 skill 后能不能真的完成任务」。

教训：Real execution 意味着真的有 input 文件、真的跑命令、真的验证 output。把 SKILL.md 丢给 LLM 让它写作文不是 execution。

他们不用 LLM-as-judge，而是确定性 verifier

SkillsBench 用的是 deterministic verifier——一个脚本，检查 agent 的输出是否符合预期。例如：

  • Task：把这个 Spring Boot 2 项目升级到 3，跑通测试。
  • Verifier：mvn test exit code 是否为 0，且关键文件里不再有 javax. import。
  • 结果：PASS 或 FAIL，没有模糊地带。

我们的方法是让 qwen-turbo 读两段文字然后选「A 好还是 B 好」——这是主观判断，每次跑结果都不一样。Deterministic verifier 跑 100 次结果一样，所以 SkillsBench 能给 95% 置信区间，而我们的 shadcn 排名能从 #1 翻到 #5。

错误 3：pairwise 比较而不是 pass/fail

Bradley-Terry pairwise 排名在能力相近的选手之间效果差——我们亲眼看着 shadcn 和 stitch-react 来回翻转。SkillsBench 用的是绝对的 pass/fail：task 要么通过 verifier 要么不通过，没有模糊地带。

教训：如果你能定义 pass/fail，就不要用 pairwise。Pairwise 是 pass/fail 不可能时的退路（比如「哪个文章写得好」），不是默认选择。

错误 4：没有 with/without 基线对比

SkillsBench 最杀手的 insight：同一个 agent + 同一个 task，有 skill 时 pass rate 48.7%，没 skill 时 31.3%。这直接回答了「skill 到底有没有用」这个问题。

纯排名根本回答不了这个问题。排名只说「A 比 B 好」，但没法说「A 比不用 skill 好多少」。

教训：Eval 的核心问题是「skill 有没有用」，不是「A 和 B 谁好」。有 baseline 才有答案。

错误 5：scenario 太宽泛，不可验证

我们写的 scenario 像考试作文题（「给我做一个多步表单组件」）。SkillsBench 的 task 像物理实验题（「给你这个 .stl 文件，算出质量，输出到 /root/answer.json」）。

前者只能让 LLM 主观判断，后者可以用 verifier 自动检查。

教训：好的 eval task = 有明确 input + 有明确 expected output + 有 verifier 能自动判断。

错误 6：分类逻辑反复翻转

  • 最开始 ship_code（太宽泛）
  • 改成 10 个 intent（太多）
  • 砍到 3 个（太少）
  • 把 sub-skill 当 skill（模型错误）
  • 改回 repo-level（对了）
  • 又重新扩到 10 个

每次翻转都要重写 import 脚本、重跑 eval、重新部署，时间全砸在反复 pivot 上。

教训：在写代码之前，先把「什么是一个 skill」「怎么验证 skill 是否好用」想清楚。不要边跑边想。

错误 7：花太多时间在基础设施上

Fly.io 部署、OpenRouter 免费 tier rate limit、SQLite migration、judge prompt 调参……这些都是基础设施噪音，跟「eval 做得好不好」无关。SkillsBench 大概在本地跑 Docker + 写 Python verifier 就搞定了，不需要 Fly.io、不需要 dashboard、不需要 Bradley-Terry。

教训：Eval 的核心是 (task, execution, verification)。Dashboard 和 leaderboard 是展示层，不是核心。先把 eval 做对，再做展示。