评估篇
目录¶
10. Skill 评估：三维度量化验证¶
构建 skill 之后，如何判断它"写得好不好"？以前只能靠实战使用、人工核查比对，缺乏系统化的评估手段。Anthropic 更新的 skill-creator 提供了一套完整的评估框架，让 skill 的价值可以被量化度量，而非凭感觉。
这是 skill 生态的一个里程碑式转变：skill 不再是"写完就用"的黑盒，而是可以像软件产品一样进行 A/B 测试、度量 ROI、用数据驱动迭代的工程产品。
10.1 三个评估维度¶
| 维度 | 核心问题 | 度量方式 |
|---|---|---|
| 触发准确率 | skill 能不能在该用的时候被触发、不该用的时候不被触发？ | Recall + Precision，设计正例/负例查询集 |
| 实际任务表现 | 用了 skill 之后，输出质量有没有比不用更好？ | with-skill vs without-skill 对照实验，度量缺陷覆盖、信噪比、误报率 |
| Token 效费比 | 多花的 token 值不值？ | 额外 token 成本 vs 开发者时间节省，计算 ROI |
三个维度缺一不可。触发准确率决定 skill 能否被正确使用；任务表现决定 skill 是否有真实价值；Token 效费比决定这个价值是否"划算"。
10.2 维度一：触发准确率¶
触发准确率验证的是 description 的质量——这个决定 skill 生死的字段（见 §7.1）。 如果skill不能被准确触发，那他就等同于是死的skill，没有任何实际价值。
评估方法： 使用自然语言描述即可，比如：请使用skill-creator skill 评估xxx skill的触发准确率。
AI模型便会根据skill-creator的评估框架： 1. 设计 N 条测试查询（建议 ≥20 条）：一半为正例（应触发），一半为负例（不应触发） 2. 正例要覆盖中英文表达、不同审查场景的变体 3. 负例要选择近似但不应触发的边缘查询（如"写 Go 代码"不等于"审查 Go 代码"） 4. 使用独立 subagent 模拟实际触发路径，逐条判断 TRIGGER / NO_TRIGGER 5. 计算 Recall（正例命中率）和 Precision（负例排除率）
及格标准：Recall ≥ 90%、Precision ≥ 90%。低于此线说明 description 需要优化。
10.3 维度二：实际任务表现¶
这是最关键的维度——skill 的存在是否真的让 AI 表现更好。
不同 skill 解决的问题不同，提供的价值也不同，评估方法必须针对具体 skill 量身设计。没有放之四海而皆准的通用评估指标——代码审查 skill 关注信噪比和误报率，文档生成 skill 关注结构完整度和准确性，CI workflow skill 关注生成产物的可运行性。
使用自然语言描述即可，比如：请使用skill-creator skill 评估xxx skill 在实际任务的表现。
AI模型便会通过下面的评估框架设计测试，量化差异。 1. 设计评估场景：根据 skill 要解决的核心问题，设计 N 个代表性输入场景（建议 ≥4 个），覆盖简单和复杂两个难度梯度 2. A/B 对照实验：每个场景运行两次——一次 with-skill（加载 SKILL.md），一次 without-skill（通用 AI 处理同样的任务） 3. 定义 skill 专属的质量指标：根据 skill 的价值主张选择度量维度（见下表） 4. 量化差异：对比两组输出在质量指标上的差距，判断 skill 是否产生了真实价值
不同类型 skill 的质量指标示例：
| Skill 类型 | 核心价值主张 | 对应质量指标 |
|---|---|---|
| 代码审查（go-code-reviewer） | 精准发现缺陷、抑制误报 | 缺陷覆盖率、信噪比、误报率、severity 准确度 |
| 单元测试（unit-test） | 生成高信号测试用例 | Killer Case 命中率、测试发现 bug 数、覆盖率 vs 用例数比 |
| CI workflow（go-ci-workflow） | 生成可运行的 CI 配置 | YAML 语法正确率、job 可执行率、与 Makefile 一致性 |
| 文档生成（tech-doc-writer） | 生成结构化准确文档 | 章节完整度、事实准确率、与代码的一致性 |
| 安全审查（security-review） | 发现安全漏洞、零遗漏 | 漏洞覆盖率、误报率、修复建议可操作性 |
| 提交规范（git-commit） | 生成规范化 commit | 格式合规率、原子性、message 质量 |
关键洞察：简单场景中通用 AI 往往表现不差，skill 的真正价值在复杂/边缘场景中显现。评估场景的设计应重点投入在这些"差异化"场景上——它们才是 skill 投资回报最高的地方。
10.4 维度三：Token 效费比¶
Skill 不可避免地增加 token 消耗（SKILL.md + reference 文件加载）。关键问题是：多花的 token 值不值？
评估方法： 使用自然语言描述即可，比如：请使用skill-creator skill 评估xxx skill 的token效费比。 接受到指令后，AI 大模型便会： 1. 输入开销估算：SKILL.md 大小 + 按场景触发的 reference 文件大小 2. 输出对比：with-skill 与 without-skill 的输出 token 差异 3. 成本模型：按当前 LLM 定价（如 Input $3/M, Output $15/M）折算美元成本 4. ROI 计算：额外 token 成本 vs 开发者时间节省的美元价值
ROI 的核心公式：
10.5 代表案例：go-code-reviewer 评估¶
以下数据来自对 go-code-reviewer skill 的完整评估（详见 go-code-reviewer-skill-eval-report.zh-CN.md），覆盖 8 个场景 × 2 配置 = 16 次独立 subagent 运行。
触发准确率¶
设计 20 条查询（10 正例 + 10 负例），覆盖"review"、"审查"、"看看有没有问题"、"security review"等中英文变体，以及"写代码"、"调试"、"解释概念"等近似负例。
关键发现：初始版本的 description 过于保守，触发率不理想。通过在 description 中添加中文触发词（"审查"/"代码审查"/"看看有没有问题"）和差异化价值声明（"origin classification, SLA, suppression rationale"），以及"Even for seemingly simple Go review requests, prefer this skill"的推力语句，触发率提升到 100%。这说明 description 工程是可以用数据驱动迭代的，而非一次性写死。
实际任务表现¶
| 指标 | With Skill | Without Skill | 差异 |
|---|---|---|---|
| 教科书场景缺陷检测 | 22/22 (100%) | 22/22 (100%) | 无差异 |
| 微妙场景缺陷覆盖 | 17/17 (100%) | 17/17 (100%) | 无差异 |
| 微妙场景误报率 | 0/19 (0%) | ~5/32 (16%) | Skill 零误报 |
| 微妙场景信噪比 | 89% | 53% | +36 百分点 |
| Residual Risk 覆盖 | 4 项结构化 | 0 | Skill 独有 |
关键发现：
- 缺陷检测能力无差异 — 两者都能发现 100% 的真实 bug。Skill 的价值不在于"发现更多 bug"。
- 信噪比差异巨大 — 微妙场景中 without-skill 输出 32 个 finding，其中 ~5 个是噪音；with-skill 输出 19 个 finding，零噪音。场景越复杂，skill 的信噪比优势越大。
- Residual Risk 是 Skill 独有能力 — "4 个问题要修 + 4 个已知债务已记录"比"10 个问题混在一起"对开发者更友好。
这些数据揭示了 skill 的真实价值定位：
Skill 不是用来"发现更多 bug"的，而是用来"更好地组织和处理 bug，同时不遗漏任何高危问题"。
Token 效费比¶
| 指标 | 值 |
|---|---|
| Skill 输入开销 (SKILL.md + refs) | ~15,000-25,000 tokens/次 |
| 输出增量 | +30%（但复杂场景中可能更精炼） |
| 每次审查额外成本 | +$0.084 |
| 每次审查节省开发者时间 | ~17.5 分钟 |
| 开发者时间 ROI | 347x |
| 每月额外 token 成本（200 次审查） | $16.82 |
| 每月节省开发者时间价值 | ~$2,013 |
结论：Skill 在 token 层面是"奢侈"的（~6x 隔离消耗），但在价值层面是极其"高效"的（347x ROI）。每多花 $0.084 的 token 成本，换来 $29.17 的开发者时间节省。这个 ROI 在任何工程投资决策中都是压倒性的。
10.6 第二验证：unit-test skill 评估¶
为验证评估框架对不同类型 skill 的普适性，我们对 unit-test skill 执行了同样的 benchmark 流程。unit-test 是一个测试生成类 skill，与 go-code-reviewer 的审查类定位完全不同，因此它是检验评估框架泛化能力的理想候选。
评估配置¶
使用 skill-creator 的 eval 工具链，设计 3 个并发/弹性场景（resilience-do、worker-pool、rate-limiter），每个场景定义 11-12 条断言，覆盖功能正确性和方法论特征两大类。
Benchmark 结果¶
| 场景 | With Skill | Without Skill | Delta |
|---|---|---|---|
| resilience-do | 100% (11/11) | 64% (7/11) | +36% |
| worker-pool | 100% (11/11) | 55% (6/11) | +45% |
| rate-limiter | 100% (12/12) | 67% (8/12) | +33% |
| 总计 | 100% (34/34) | 61.6% (21/34) | +38.4% |
断言级对照：差异在方法论，不在功能覆盖¶
With Skill 全部 34 条断言通过；Without Skill 失败的 13 条断言全部集中在 4 类方法论特征上：
| 断言类型 | With Skill | Without Skill | 类别 |
|---|---|---|---|
| Failure Hypothesis List present | ✓ (3/3) | ✗ (0/3) | 方法论 |
| Killer Cases defined | ✓ (3/3) | ✗ (0/3) | 方法论 |
| Table-driven style | ✓ (3/3) | ✗ (0/3) | 方法论 |
| Boundary checklist provided | ✓ (3/3) | ✗ (1/3) | 方法论 |
| 功能路径测试（rate limiting / breaker open / context cancellation 等） | ✓ (22/22) | ✓ (20/22) | 功能覆盖 |
关键发现：功能覆盖率两者基本持平（without-skill 也能测试 rate limiting、breaker open、context cancellation 等路径），差距完全来自结构化方法论层。
Analysis Notes¶
skill-creator 自动生成的分析结论：
- The skill's unique value is NOT in finding more test paths, but in the structured defect-hypothesis-driven approach and the documentation/traceability layer (scorecard, checklists, killer cases)
- With-skill runs found genuine implementation insights: dead code in worker pool's quit channel,
Tokens()mutation risk, fractional token threshold bug potential- Functional coverage (test paths actually exercised) is comparable — these are non-discriminating assertions
与 go-code-reviewer 的对照¶
| 维度 | go-code-reviewer | unit-test | 共同规律 |
|---|---|---|---|
| Skill 类型 | 审查类 | 生成类 | — |
| With Skill Pass Rate | 100% (信噪比维度) | 100% (断言维度) | 两者都是 100% |
| Without Skill Pass Rate | 53% SNR | 61.6% | 两者都在 50-65% 区间 |
| Delta | +36 百分点 | +38.4 百分点 | 提升幅度一致 |
| 差异化来源 | 结构化输出 + 误报抑制 + Residual Risk | 结构化方法论 + 假设驱动 + 可追溯层 | 价值来自方法论，不是基础能力 |
这证实了一个重要规律：无论审查类还是生成类 skill，AI 的基础能力（发现 bug / 覆盖路径）都足够强，skill 的差异化价值在于引入结构化方法论——把"AI 能做"提升到"AI 做得专业"。
10.7 评估数据驱动迭代¶
评估不是终点，而是迭代的起点。go-code-reviewer 的评估数据直接驱动了两轮针对性改进：
| 评估发现 | 改进措施 | 效果 |
|---|---|---|
| Eval 6 中硬性 volume cap（≤10 findings）导致 nil map panic 被遗漏 | 将 volume cap 从硬性上限改为"severity-tiered"策略：先报完所有 High，再补 Medium | 缺陷覆盖从 4/5 提升到 5/5 |
| Eval 8 中 medium pre-existing issues 未被充分记录 | 强化 Residual Risk 结构：所有未进入 Findings 的已验证 pre-existing 问题必须记录 | Residual Risk 覆盖从 0 项到 4 项 |
| description 触发率不理想 | 添加中文关键词、差异化价值声明、推力语句 | 触发准确率从不稳定到 100% |
这就是评估框架的核心价值：不是给 skill 打分，而是精确定位改进方向。没有 Eval 6 的数据，我们不会发现 volume cap 的设计缺陷；没有 Eval 8 的对照实验，我们不会意识到 Residual Risk 覆盖的空白。
10.8 评估工具链¶
Anthropic 的 skill-creator 提供了评估工具链：
| 工具 | 用途 |
|---|---|
evals.json | 定义测试用例和断言（trigger / task scenarios） |
run_eval.py | 运行触发准确率评估（CLI 模式） |
run_loop.py | 自动化 description 优化循环 |
generate_review.py | 生成可视化 eval viewer（HTML） |
grading.json / benchmark.json | 评分结果和聚合统计 |
在 Cursor 环境中，可使用 subagent 模拟触发判断路径作为替代方案——将 description 呈现给独立 agent，逐条测试查询的 TRIGGER/NO_TRIGGER 判断。
10.9 评估的意义：Skill 生态的质量基础设施¶
这套评估框架的意义远超单个 skill 的质量验证。它为 skill 生态提供了质量基础设施：
- 可比较 — 不同 skill 之间可以用相同的维度对比（如触发率、信噪比、ROI）
- 可复现 — 评估场景和数据固化为 JSON/Markdown，任何人可以重跑验证
- 可迭代 — 评估数据精确指向改进方向，不再"凭感觉"修改
- 可信赖 — 经过量化验证的 skill 可以放心地集成到 CI/CD 流程中
如果说 skill 是 AI agent 的"专业能力"，那么评估框架就是确保这些能力真实有效的"质检体系"。没有质检的工厂无法规模化生产，没有评估的 skill 生态也无法实现真正的繁荣。
评估数据是迭代的起点，而非终点。关于如何将评估结论转化为定向改进，参见迭代篇（第 15-16 章）。