来源：Claude Code 会话实践沉淀（2026-10 定型，脱敏版）。依据：官方 Claude Code skill-creator / claude plugin eval（后者 early access）+ Ratchet 论文（模型自写技能 +0.0pp vs 人写 +16.2pp）。

技能评测（eval-skills）

你要解决的事

用户的原话通常是这几句：

"我这个技能改了 description，还会被触发吗？" / "这个技能到底有没有用？" / "帮我跑个评测"

他这会儿有的是一个已经发布的技能和一个说不清的担心。你要把他从「不知道它还好不好使」带到「有可复现的证据说它好或不好」。

边界（先看这个，别越界）：

一句话区分：别人管"建"和"管"，本技能管"验"。

这个技能为什么存在

• 解决什么问题：技能的质量保障长期停在"跑两下 demo 没报错就发布"——没有用例、没有回归、没有门禁。技能仓常见的结构检查（name 与目录名一致 / 凭据残留 / 内容红线）只验包的结构，一行都不验行为。改一行 description，触发面就可能塌，而当前完全测不出来。
• 不解决什么（边界）：不创建技能、不改技能正文、不做体积治理、不生成技能建议。评测与修复分离——本技能定位问题，修不修由人和对应技能决定。
• 决策依据：① 官方 Claude Code 已内建评测能力（skill-creator 稳定可用、claude plugin eval 尚在 early access），优先调用、不自研 grader；② Ratchet 论文实测 LLM 自写技能 +0.0pp / 人写 +16.2pp → 用例必须人定标准；③ 官方明文「The two formats aren't interchangeable」→ 两套格式不可混用，选定一套。

四条铁律

1. 用例的人定标准，AI 不自已出题——AI 可以起草，但**"什么算通过"必须由人确认**。数据依据：LLM 自写的评测 +0.0pp，人写的 +16.2pp。
2. 不让被评测者当自己的裁判——跑评测的会话不挂被评测技能的上下文，判定用独立的 grader/子代理。
3. 用例必须可断言——断言要能机械判真假（文件存在 / 正则命中 / 调用了某工具），拒绝"回答得不错""感觉更好了"这类判据。
4. 绿灯不算证据，附一条变异测试——用例群全绿后，必须再跑一条「测试的测试」：把实现故意回退（或注入缺陷），断言对应用例必须变红。不变红的用例群，绿灯只是巧合。数据依据：2026-10-14 对素材库 ID 稳定化的 4 条用例实测——没有这一条，回归线形同虚设。

第 0 步：先问清楚（别猜）

只问三件，一句话回答就行：

⚠️ 别问："你要跑几个用例""用什么模型"——这些是你该按下面规则定的，不是他的选择题。 成本提示：每次评测都是真实模型调用（按 token 计费），先告诉他这次大概要跑多少次。

第 1 步：先查有没有现成的（别重复造）

建用例之前，先扫池子——同一个技能可能已经有人写过评测，或你要测的能力已被别的技能覆盖。

# 池内已有评测用例？（约定的 eval 目录）
ls <skills-dir>/<技能名>/evals/ 2>/dev/null

判据：命中的先摆出来给人看，由人决定是补用例还是新建。不要默默另起一套。

第 2 步：写用例（人定标准，AI 起草）

调官方 skill-creator（Claude Code 已内建）——它自带 grader 子代理与 eval-viewer，稳定可用。

用例结构（skill-creator 格式）：

{
  "skill_name": "<必须等于 SKILL.md 的 name>",
  "evals": [
    {
      "id": 1,
      "prompt": "<用户会怎么说——照抄口语，别写书面语>",
      "expected_output": "<期望结果的白话描述>",
      "expectations": [
        "<可机械判断的陈述，一条一条列>"
      ]
    }
  ]
}

写 prompt 的两条硬规矩：

• ✅ 写成用户的原话（"帮我把这个 PDF 翻一下"），不要提技能名——提了就等于给了提示，测不出真实触发率
• ✅ 覆盖近似说法：同一个意图换 3–5 种讲法，其中至少一种是"它可能不触发"的边缘说法

对照组必配：每条用例除了"该触发"的，至少配一条不该触发的（比如通用能力就能完成的任务）——否则测不出误触发。

第 3 步：跑

先跑 A。B 通了再切——B 有 with/without 双跑（Δ 能证明"技能确实起了作用"）和 --threshold 退出码，但要迁移用例格式（两套不可互换）。

跑之前固定模型，否则模型换代会被误判成技能回归。

第 4 步：判失败归属（这一步最容易做错）

用例红了，先别改技能。逐条判是技能错还是用例错：

🔴 别为了让用例变绿去改技能——那是拿用例倒推实现，等于自己给自己出题。

第 5 步：留档（不落盘 = 白跑）

• 用例进技能仓（不进分发包——npm 包/插件包只装使用方需要的东西，评测是发布方的责任）
• 结果登记：跑了几条、过了几条、失败归属、改了什么
• 用例不复用一次就完——接进后续每次改动后的回归

排错

红线

• ❌ 不用例就跑评测——"跑了两下没问题"不算验证过
• ❌ 用 LLM 自拟的标准当通过线（+0.0pp）——标准必须人确认
• ❌ 为了让用例变绿改技能——倒果为因
• ❌ 绿灯不退一步做变异测试——没有"测试的测试"，绿灯不构成证据
• ❌ 把评测用例打进分发包——内部标准不进分发产物
• ✅ 跑完报告：几条用例、过没过、失败归谁、下一步建议——不含糊说"没问题"