评测 Skills 方向：skill-creator 与 OpenAI Evals 对比与选型指南

摘要

如果目标是评测一个 SKILL.md（Anthropic Agent Skill）到底有没有让 Claude 变好，结论非常清晰：首选 Anthropic 官方 skill-creator，不要套 openai/evals。原因是被评对象的形态决定了评测姿势——skill-creator 被设计用来评 “skill 文件 + 模型 + 任务” 的组合增益，强制 with-skill vs baseline 双跑、配带 grader / comparator / analyzer 三个评委 sub-agent、含独立的”description 触发率”优化管线和浏览器交互式 viewer，是工程化、闭环、可迭代的方法学；而 openai/evals 是通用 LLM 评测框架，强项是 registry 注册机制和跨模型 CompletionFn 协议，但没有 baseline 对照、没有触发率评测、没有 non-discriminating assertion 检测——这些恰好是评 skill 必须的能力。两者并不互斥：可以把 openai/evals 作为”通用任务能力”的横向 sanity check，把 skill-creator 作为”skill 是否真的产生增量”的纵向 A/B 闭环；评开放式输出时，openai/evals 的 cot_classify LLM-as-judge 模板可以借鉴进 skill-creator 的 grader prompt。本文给出两条完整 SOP（1 小时落地版 + 1 天落地版）以及 7 个常见坑。

研究问题

• 评测 SKILL.md 与评测 LLM 任务表现，技术上有什么本质差异？
• 两个框架各自交付了什么”评测资产”？粒度对齐到什么程度？
• 在评 skill 这件事上，能做什么 vs 不能做什么？
• 不同场景下应该选哪个？能否组合？
• 落地一次评测的最小可行步骤是什么？

发现

1. 一图看清两者本职

维度	skill-creator	openai/evals
定位	评测 + 创建 + 改进 SKILL.md 的端到端工作流	评测 LLM/agent 任务输出的通用框架
被评对象	SKILL.md 文件 + 加载它的 Claude	任意实现 CompletionFn 的 LLM/agent
核心抽象	双跑（with-skill vs baseline） + iteration 目录 + viewer feedback 闭环	YAML 注册的 eval + JSONL 样本 + 5 个内置模板
评测产物	benchmark.json / feedback.json / grading.json / 交互 viewer	oaieval 控制台报告 / Snowflake 落库
是否有触发率评测	✅ 独立 run_loop.py 管线	❌ 无概念
是否强制 baseline	✅ 同回合双跑	❌ 自由
评委角色数	3（grader / comparator / analyzer）	1（ModelBasedClassify）
用户在环	✅ 浏览器 viewer 逐 case 留 feedback	❌ 控制台分数
跨模型	主要 Claude（claude -p 真调）	任意（CompletionFn 协议）

2. skill-creator 的真实资产清单（实测 sparse clone 抓取）

skills/skill-creator/
├── SKILL.md                    485 行，方法学主文档
├── agents/
│   ├── grader.md               223 行 单边打分（assertion + 隐含声明审查）
│   ├── comparator.md           202 行 A/B 盲对比（不告评委哪个是哪个）
│   └── analyzer.md             274 行 benchmark 模式分析（找非区分性 assertion）
├── eval-viewer/
│   ├── generate_review.py      生成可交互 HTML 评测报告
│   └── viewer.html             浏览器内 Outputs / Benchmark 双 tab
├── scripts/
│   ├── run_eval.py             310 行 跑触发率 eval（spawn `claude -p`）
│   ├── run_loop.py             328 行 description 自动优化迭代循环
│   ├── aggregate_benchmark.py  401 行 汇总 grading → benchmark.json/md
│   ├── improve_description.py  247 行 基于 fail case 重写 description
│   ├── generate_report.py      326 行
│   ├── package_skill.py        136 行
│   ├── quick_validate.py       102 行
│   └── utils.py
├── references/schemas.md       430 行 固化所有评测 JSON schema
└── assets/eval_review.html     触发率 eval 人工审核 UI 模板

3. openai/evals 的真实资产清单（评 skill 视角）

• 能直接用：ModelBasedClassify 模板 + cot_classify prompt 范式（评开放式答案最稳的 LLM-as-judge 形态）
• 可借用骨架：CompletionFn 协议（让”加载 skill 的 Claude”成为被评对象的统一接口）
• registry/evals 下数百个 YAML 例子：当任务样本灵感库
• 能补的事：跨模型横向对比（同一任务 GPT-4 / Claude / Llama 一起跑）
• 不能直接用于评 skill 的部分：触发率管线、双跑对照、non-discriminating 检测、用户在环 viewer——这些必须自己搭

4. 评测 SKILL.md 与评测 LLM 任务的三个本质差异

1. 病因二元性：skill 失败可能是”description 让它没被触发”，也可能是”触发了但输出差”。前者只能用真调 claude -p 看是否 read 该 skill 来评，后者才是输出质量评测。openai/evals 完全没有第一种。
2. 增量 vs 绝对值：skill 的价值是”加载它后比不加载更好”，看 delta 不看绝对分。一个 skill 跑出 0.78 完全不能证明它有用——可能不挂时也是 0.78。必须 baseline 对照。
3. non-discriminating assertion 风险：写出”任何 LLM 都能过”的断言是反向误导。skill-creator 的 analyzer.md 主动找出”挂不挂 skill 都过 100%”的断言，建议删除或调严，这是数据质量自检。openai/evals 无此检测。

对比与判断

详细对比矩阵（评 skill 视角，14 维度）

维度	skill-creator	openai/evals
是否原生支持评 SKILL.md	✅ 这就是它本职	❌ 需自建 CompletionFn 把 SKILL.md 拼进 system
触发率（trigger rate）评测	✅ run_eval.py + run_loop.py 独立管线	❌ 概念缺失
强制 baseline 对照	✅ 同回合 spawn 双跑	❌ 自由
多评委角色	✅ grader + comparator + analyzer	⚠️ 仅 ModelBasedClassify
盲 A/B 对比	✅ comparator.md 标 A/B 不告知归属	❌ 自建
Self-preference bias 控制	✅ comparator 设计内建	❌ 用户自负
Non-discriminating assertion 检测	✅ analyzer.md	❌ 无
用户在环 feedback	✅ viewer.html 浏览器内	❌ 控制台
Token/timing 自动采集	✅ task notification 强制	⚠️ 部分支持
迭代闭环（feedback 喂下一轮）	✅ feedback.json → iteration-N+1	❌ 自建
跨模型对比	⚠️ 主要 Claude	✅ CompletionFn 协议
公开 registry / 样本库	❌ 暂无	✅ 数百个 YAML
Snowflake / 持久化	❌ 本地 JSON	✅ 内建
CI 友好度	⚠️ Python 脚本可接	✅ oaieval 命令式

各自的”优势 / 弱点”清单

skill-creator 优势

1. 唯一的官方 skill 评测方法学（直接由 Anthropic 维护、与 Claude Code 深度集成）
2. 强制双跑 + delta 视角，杜绝”绝对分数空洞数字”
3. 三评委角色分工清晰：grader 评单边、comparator 防 self-preference、analyzer 评数据质量
4. 触发率独立管线——抓住 SKILL.md 的命门
5. 浏览器交互式 viewer 让人工 feedback 成为可持久化资产
6. 隐含声明（implicit claim）审查：grader 不仅评显式 assertion，还会反向找”输出里隐含的事实/过程主张”逐一核对

skill-creator 弱点

1. 跨模型对比薄弱（评委本身也是 Claude，跨家做”中立 judge”要自己改造）
2. 没有公开 registry，社区 skill 评测样本库尚未形成
3. 强依赖 claude -p 调用链，纯 API 场景（不用 Claude Code）有适配成本
4. CI 集成需要写 wrapper（不像 oaieval 一行命令）
5. 文档相对少，错过细节就跑不起来（如 grading.json 字段必须用 text/passed/evidence）

openai/evals 优势

1. 通用性：任何 LLM/agent 实现 CompletionFn 都能挂
2. 公开 registry 数百个 YAML 模板，可借鉴 prompt 与 assertion 写法
3. cot_classify 是工业级 LLM-as-judge 范式，稳定性高
4. CLI 一行跑（oaieval gpt-4 my_eval），CI 友好
5. 跨模型横评天然支持（同一份 eval 跑多个 CompletionFn）

openai/evals 弱点

1. 评 SKILL.md 必须自建 CompletionFn 适配器（拼 SKILL.md 进 system）
2. 没有 baseline 强制约束、没有触发率概念
3. 评委只有 ModelBasedClassify 一个范式，缺 comparator / analyzer
4. PR 不接受纯 Python 自定义 eval（出于审计），公开沉淀有门槛
5. 对”是否调到 skill”完全不可见——只能评最终输出

何时选哪个（决策表）

场景	推荐	关键理由
你正在写一个新的 SKILL.md，想做”挂上后真的让 Claude 变好”验证	skill-creator	双跑 + viewer feedback + 触发率优化是核心闭环
已经有 SKILL.md，要做新版本 vs 旧版本回归	skill-creator	comparator 盲对比专为此设计
你的 skill 主诉求是”被正确触发”（描述写得对）	skill-creator	独立的 description optimization 管线无可替代
你不评 skill，是评一个 agent / RAG / function-calling 链路	openai/evals	CompletionFn 协议 + registry 模板更直接
多模型横评（同任务对比 GPT-4 / Claude / Llama）	openai/evals	CompletionFn 是为此设计
想往 CI 接、跑 PR 回归	混合	用 oaieval 的 CLI 形态，套 skill-creator 的双跑思想
想公开发布 eval 让别人复用	openai/evals	有公开 registry 与 PR 流程

能否组合？怎么组合最优？

可以而且推荐组合。两套是不同层级的能力：

• skill-creator 是垂直闭环（评 SKILL.md 的方法学）
• openai/evals 是水平管道（评任意 LLM 输出的工具）

组合姿势 1（轻）：用 skill-creator 的工作流和评委 prompt，但执行层用 oaieval+ 自定义 CompletionFn 跑分。优点是 CI 友好；代价是要自己实现”双跑”逻辑（注册 claude-with-skill + claude-no-skill 两个 CompletionFn）。

组合姿势 2（重）：核心评测走 skill-creator 全套；同时用 oaieval 跑标准学术基准（MMLU 子集、GSM8K 子集）做”模型基础能力没退化”的 sanity check。这样”skill 增益评测”和”模型能力监控”互不干扰。

组合姿势 3（偷招）：把 openai/evals 的 cot_classify prompt 模板抄进 skill-creator 的 grader.md，强化 grader 的”先 CoT 再判分”流程，分数稳定性会上升一档。

落地 SOP

A. 1 小时落地版（评一个已有 SKILL.md 的最小可行流）

0. 确认 skill 已挂（~/.claude/skills/<name>/SKILL.md 存在或软链）
1. 把 skill-creator 也挂进 ~/.claude/skills/skill-creator/
2. 跟 Claude Code 说："用 skill-creator 评测一下 <my-skill>"
3. 起 3 个真实任务作为 eval prompt（覆盖 should-trigger 主路径）
4. 让 Claude 同回合 spawn 双跑（with-skill / without_skill）
5. 起草 3-5 条客观 assertion（"输出含 X 字段"、"代码能编译"等），存 eval_metadata.json
6. 等运行完成，捕 timing 信息（task notification）
7. 跑 grader sub-agent 打分 → grading.json
8. 跑 aggregate_benchmark.py → benchmark.json/md
9. 跑 generate_review.py → 浏览器 viewer 看 Outputs + Benchmark 双 tab
10. 看 delta：with-skill - without_skill 的 pass_rate 差是否 > 20%；如果不到，说明 skill 没产生增量

B. 1 天落地版（含触发率优化 + 多轮迭代）

在 SOP A 基础上加：

11. 准备 20 个 trigger eval query（10 should-trigger + 10 should-not-trigger，强调 should-not-trigger 是"近邻陷阱"）
12. 用 assets/eval_review.html 让用户审 eval 集
13. 跑 run_loop.py：max-iterations 5，自动改 description 直到触发率 ≥ 90%
14. 回到输出质量评测：基于 viewer feedback 改 SKILL.md 主体
15. 再跑 iteration-2，--previous-workspace 指向 iteration-1，对比改进 delta
16. 跑 comparator 做盲对比："新版真的比旧版好吗"
17. 跑 analyzer 检查是否有 non-discriminating assertion，删除或调严
18. 重复直到 feedback 全空 / 用户满意 / 不再有进展

C. CI 接入版（混合方案）

项目根/
├── .claude/skills/<my-skill>/SKILL.md
├── evals/
│   ├── completion_fns/
│   │   ├── claude-with-skill.yaml
│   │   └── claude-no-skill.yaml
│   ├── evals/<my-skill>-eval.yaml      # openai/evals 注册
│   └── data/<my-skill>/samples.jsonl
└── .github/workflows/skill-eval.yml

GitHub Action 跑：

oaieval --registry_path ./evals claude-with-skill <my-skill>-eval > with.txt
oaieval --registry_path ./evals claude-no-skill   <my-skill>-eval > without.txt
python compare_delta.py with.txt without.txt --threshold 0.15

compare_delta.py 计算 delta，低于阈值就 fail PR。每月人工跑一次完整 skill-creator 流程做深度迭代。

7 个常见坑

1. 绝对分数当成功：跑出 0.85 就开庆功。正确做法是 baseline 也跑，看 delta。
2. 评委用同家模型：Claude 评 Claude 输出有 self-preference。正确做法是用 OpenAI 当中立评委，或走 comparator 盲对比。
3. assertion 写得太软：”输出有结构” → 任何 LLM 都过。正确做法是 analyzer 跑完先扫 non-discriminating，调严断言。
4. judge 模型不锁版本：用 gpt-4 不带 timestamp，跨月分数飘 5-15%。正确做法是锁 gpt-4o-2024-11-20 这种带日期的。
5. 样本量太小：3 条样本得出”skill 提升 30%”是噪声不是信号。正确做法是至少 10-20 条（每条至少 3 次重跑评 variance），看 mean ± stddev。
6. 混淆触发率与输出质量：以为输出差是 SKILL.md 写得烂，其实是 description 让它没被触发。正确做法是先跑 run_eval.py 确认触发率 > 90% 再评输出。
7. Iteration 目录串台：第 N 轮没复制 baseline，分母用了第 1 轮的，delta 全乱。正确做法是每轮重跑 baseline（创建新 skill 时是 without_skill，改进现有 skill 时是上一版）。

一句话推荐

• 如果你只评一种东西且是 SKILL.md：直接 skill-creator，别绕路。
• 如果你想做团队级评测平台：把 skill-creator 的方法学（双跑、三评委、触发率独立、analyzer 找非区分）用 openai/evals 的注册机制 + CI 实现一遍。
• 如果你只是好奇 skill 有没有用，且时间有限：写 30 行 Python 脚本（anthropic SDK + 5 条样本 + 锁版本的 GPT-4 judge）做最小双跑，不用任何框架也行，但思路必须遵循 skill-creator 那一套（baseline / cot_classify / 看 delta）。

不确定性

• skill-creator 在非 Claude Code 场景的可用性：scripts 里强依赖 claude -p，纯 Anthropic API 用户需要二次封装。
• comparator 盲对比的 cost：每个样本要起两个 sub-agent + 一个评委，token 消耗显著，未实测。
• 触发率管线 max-iterations 5 的收敛性：description 自动改写循环是否真能稳定收敛、有没有”改飞”风险，待跑实例验证。
• openai/evals 是否会因托管版 Evals API 进一步停止演进：开源仓库 2025 年放缓，这套 GitHub 资产的长期保鲜度有不确定性。
• non-discriminating 检测的阈值经验值：analyzer 报”挂不挂都过”的判定阈值（百分比、显著性）官方未明确，需要团队自行经验积累。

后续行动

• 在沙箱挂上 skill-creator，对 agent-browser-cli 跑一次完整 SOP A，记录 token 与时间成本。
• 把 cot_classify prompt 段抄进 skill-creator 的 grader.md，对比稳定性差异。
• 用 SOP C 在本仓库（ai-model-research）建一个最小 CI demo：评 researcher.md skill 在”研究简报引用准确性”任务上的增益。
• 记录 7 个坑里我们实际踩中过的，沉淀进自家 SKILL 评测 checklist。
• 跟踪 skill-creator 的 commit 节奏与 schemas.md 改动，避免因字段更名（如 text/passed/evidence）跑挂。

来源

• anthropics/skills 仓库主页
• skill-creator/SKILL.md（raw, 485 行）
• skill-creator/agents/grader.md
• skill-creator/agents/comparator.md
• skill-creator/agents/analyzer.md
• openai/evals 仓库主页
• openai/evals docs/eval-templates.md
• openai/evals docs/completion-fns.md
• Agent Skills Engineering Deep Dive (社区)