## 概述 本教程面向已能写出第一个 `SKILL.md`、却苦于"今天能用、明天模型一升级就飘"的开发者。你将学会用 Skill Creator 插件内置的 **Evals（评测）+ 方差分析 + 盲测 A/B + Benchmark** 体系，把一个自定义 Skill 从"凭感觉调"变成"用数据迭代"。全程围绕一个真实可运行的**变更影响分析（blast-radius）Skill** 展开：从骨架创建、编写测试用例、解读报告，到盲测对比两版指令、沉淀回归基线。 ## 前置条件 - 已安装 Claude Code（CLI 版本），能跑通交互会话 - Node.js ≥ 18（Skill Creator 插件依赖） - 一个带有 git 历史的真实代码仓库（用于实战案例的真实 diff） - 基础认知：知道 `SKILL.md` 的 frontmatter（`name` / `description`）和"渐进披露"概念 - 安装官方 **Skill Creator** 插件（来源见文末参考 2），它把评测/基准/盲测封装成了可调用的工作流 --- ## 第 1 步：先想清楚"可度量性"这件事 很多 Skill 教程止步于"写好 description，能被触发就完事"。但这留下两个致命盲区： 1. **行为漂移**：同一个 Skill，在 Claude 4.6 和 4.8 上行为可能不同；一次模型升级就可能让原本稳定的输出变差，而你毫无察觉。 2. **主观调参**：改一句指令"顺手看一眼输出像不像对的"，本质是猜。没有数字，就没有迭代。 Evals 体系解决的就是这两点：**用一组带预期结果的测试用例，量化 Skill 的通过率与稳定性（方差），并允许在"不知道来源"的前提下盲测对比两版指令**。这是把 Skill 从玩具变成生产级工具的分水岭。 > 常见误区：把 evals 当成单元测试那种"对/错二值"。实际上 Skill 输出是自然语言，评测本质是**用一个评判 agent 按规则打分**，更像"双盲临床试验"而非 assert。 ## 第 2 步：安装 Skill Creator 插件 Skill Creator 是 Anthropic 官方维护的 Skill 开发工具箱，2026 年的 2.0 版本把 evals、benchmark、盲测 A/B 做成了内置能力。 ```bash # 在 Claude Code 交互会话中 /plugin install skill-creator ``` 安装后你获得一组命令，本教程用到三个核心能力： - **创建/编辑 Skill**：生成符合规范的 `SKILL.md` 骨架 - **evals**：按用例集跑 N 次，输出通过率与方差 - **benchmark / blind A/B**：保存历史结果、盲测对比版本 预期结果：`/plugin list` 中能看到 `skill-creator`，会话内可调用其工作流。 > 常见问题：国内网络拉取插件市场失败 → 配置代理或用镜像源；插件装上但命令不出现 → 重启会话让命令注册生效。 ## 第 3 步：创建 Skill 骨架（变更影响分析） 我们的实战 Skill 做一件事：**给定当前 git diff，输出"爆炸半径"——受影响的文件、模块、测试、文档，并给出评审顺序**。这在每次提交/合并前极有用，且天然适合用 evals 度量（因为有明确的"对错"信号：是否漏了调用方、风险等级是否合理）。 让 Skill Creator 生成骨架，或直接手写。文件放在仓库的 `.claude/skills/change-impact-analysis/SKILL.md`： ```markdown --- name: change-impact-analysis description: Analyzes the current git diff to map blast radius — affected files, modules, tests, docs — and produces a ranked review order. Use when the user asks about the impact of changes, "what will this break", blast radius, or before committing/merging a non-trivial change. --- # Change Impact Analysis Analyze the scope and risk of pending changes in the current git repository. ## Procedure 1. Get the diff: `git diff HEAD` (staged + unstaged) or `git diff ` for a PR. 2. Classify each changed file by layer: source / test / config / docs / build. 3. For any changed **exported symbol**, grep its call sites to map dependents. 4. List tests that cover changed code, and tests that should be added. 5. Output a ranked review order: highest-risk, least-isolated first. ## Output format A Markdown table: `File | Change Type | Likely Affected | Confidence | Suggested Action` Then a "Review order" numbered list and a "Risk summary" (Low/Med/High + one-line rationale). ## Rules - Confidence is High ONLY if grep-verified; otherwise Medium/Low. - Never say "no impact" for an exported-symbol change without grepping callers. - If no diff exists, say so and STOP — do not invent changes. ``` 设计要点（也是后续 evals 的评分依据）： - **`description` 写清"什么时候用 + 做什么"**：触发词覆盖"impact / blast radius / 提交前 / 合并前"。这是触发命中率的基础。 - **渐进披露**：frontmatter 只放最小元数据；详细步骤放正文；可复用的 grep 模式可下沉到同目录 `reference.md`，按需读取。 - **可验证规则**：`Confidence 仅 grep 验证才 High`、`无 diff 必须停止`——这些硬规则让评测有客观判据。 > 常见问题：Skill 写完不被触发 → 90% 是 `description` 没覆盖用户的真实措辞；把"blast radius"和"提交前"都写进去。本教程第 6 步会专门讲触发调优。 ## 第 4 步：编写 Evals 测试集 这是整个体系的核心。一个 evals 用例 = **prompt + 前置 setup + 预期（断言/规则）**。我们写 4 个能覆盖关键行为的用例，放在 `.claude/skills/change-impact-analysis/evals.yaml`： ```yaml skill: change-impact-analysis runs_per_case: 3 # 每个用例跑 3 次 → 方差分析 cases: - id: empty-repo prompt: "分析我当前改动的影响" setup: shell: "git stash" # 制造无 diff 场景 expect: must_match_regex: ["(?i)no.*(diff|changes)|没有.*改动"] must_not_contain: ["src/", "invented"] rubric: "无 diff 时必须明确停止，禁止编造改动" - id: doc-only prompt: "这个改动的 blast radius？" setup: shell: "echo '## Notes' >> README.md && git add README.md" expect: must_contain: ["README.md"] risk_level: "Low" must_not_contain: ["High"] rubric: "纯文档改动 → Low 风险，不应声称影响测试" - id: exported-api-change prompt: "提交前帮我看下这次改动的影响" setup: shell: "sed -i 's/export function calculate/export function calculate(x, y)/' src/api.js && git add src/api.js" expect: must_contain_regex: ["(?i)call.*(site|er)|依赖|调用方"] must_contain: ["src/api.js"] confidence_must_be_grep_verified: true risk_level: "High" rubric: "导出符号签名变更，必须 grep 调用方，风险 High" - id: test-only prompt: "blast radius" setup: shell: "echo 'test' >> tests/api.test.js && git add tests/api.test.js" expect: risk_level: "Low" must_not_contain: ["High"] rubric: "仅测试文件改动 → Low，不应升级为 High" ``` 四个用例刻意覆盖了**易错边界**：空 diff（防编造）、纯文档（防过度告警）、导出 API 变更（防漏报调用方）、纯测试（防误判风险）。`runs_per_case: 3` 让每个用例跑 3 次，为第 5 步的方差分析提供数据。 > 常见问题：`rubric` 写成"输出要正确"等于没写——评判 agent 无法判断。要写成**可观测的行为契约**（"必须 grep 调用方"、"无 diff 必须停止"）。 ## 第 5 步：运行 Evals，解读报告（通过率 + 方差） 在 Skill Creator 工作流里指向这个用例集运行。输出是一张表，关键看三列：**通过率 / 方差 / 失败原因**。 ``` Case Pass(3/3) Variance Notes empty-repo 3/3 low OK doc-only 3/3 low OK exported-api-change 1/3 HIGH 2/3 未 grep 调用方，直接给了 Medium test-only 2/3 med 1/3 偶发标 High ``` 如何读这张表： - **通过率低** → 行为不对，是**正确性**问题（如 `exported-api-change` 漏 grep）。 - **方差高（同一用例跑 3 次结果不一致）** → 是**稳定性**问题，比正确性更隐蔽：用户某次跑得到对的结果，下次跑就错了。方差高的 Skill 不能上生产。 - **偶发失败** → 多半是指令里有模糊措辞（"如果适用就 grep"里的"如果适用"是灾难）。 预期诊断：`exported-api-change` 方差高，根因是 `Procedure` 第 3 步用了"any changed exported symbol"但模型有时判断为"非导出"而跳过 grep。这就是第 6、7 步要修的点。 ## 第 6 步：触发调优（先让 Skill 被"正确激活"再谈行为） 在改行为之前，先确认触发本身没问题——一个没被激活的 Skill，evals 跑得再好也没意义。Skill Creator 的触发评测会拿一批**应当激活**和**不应激活**的 prompt，统计命中率与误触发率。 调优 `description` 的三条经验： 1. **覆盖用户的真实问法**：不要只写"analyze impact"，要补"what will this break / blast radius / 提交前 / 合并前"。中文用户记得加中文触发词。 2. **划清边界（负向声明）**：写明"不用于：单文件 typo 修复、纯样式调整"，能压低误触发。 3. **动词开头、一句话讲完"何时 + 做什么"**：description 是模型路由的唯一依据，越像"if 用户说X且场景是Y，就做Z"越好。 调优后用 Skill Creator 重跑触发评测，命中率应从 ~70% 提升到 95% 区间（参考文末 dev.to 的"2 fixes for ~100% activation"经验）。 ## 第 7 步：盲测 A/B 对比两版指令 这是 Skills 2.0 最强的能力：**在不知道输出来自哪个版本的前提下，让一个独立的 comparator agent 评判哪个更好**。 针对第 5 步发现的 `exported-api-change` 方差问题，我们准备两个版本的 `Procedure` 第 3 步： - **版本 A（模糊）**："If the change touches an exported symbol, consider grep-ing its callers." - **版本 B（强制）**："Step 3 (mandatory): For EVERY changed `export`/`module.exports`/`pub fn`, run a grep for call sites before scoring Confidence. Skipping grep is a failure." 跑盲测 A/B：同一个用例集喂给两版，comparator 逐条盲评"哪个输出更符合 rubric"。结果通常是 B 在 `exported-api-change` 上完胜，因为它把"模糊建议"变成了"硬性步骤"。把 B 合并进 `SKILL.md`，重跑第 5 步的 evals，方差应显著下降。 > 关键认知：盲测的价值在于**消除你自己的确认偏误**。你已经知道哪版是你"精心改的"，会下意识偏袒；comparator 不知道，所以它的判断可信。把"我看着不错"升级为"盲评胜出"。 ## 第 8 步：Benchmark 沉淀为回归基线（防模型漂移） 当 Skill 通过率稳定、方差低，把这次结果写入 **benchmark** 作为基线快照。它记录：当时用的模型版本、各用例通过率、方差、平均评判分。 之后两件事会触发"重跑基准"： 1. **Claude 模型升级**（如 4.6 → 4.8）：重跑全套 evals，对比基线。通过率掉了就说明你的 Skill 在新模型上漂移了，需要重新调指令。这就是开篇说的"今天能用、明天飘"的预警机制。 2. **改了指令**：改完先跑 evals，确认没有回退，再更新基线。 养成节奏：**每次模型升级 / 每次改指令 → 跑 evals → 对比基线 → 必要时盲测迭代**。这才是"用数据维护 Skill"的完整闭环。 --- ## 实战案例：完整可运行产物 把上述步骤凝结成两个文件，放进任意 git 仓库即可跑通： **`.claude/skills/change-impact-analysis/SKILL.md`** —— 见第 3 步完整内容（务必用版本 B 的强制 grep 步骤）。 **`.claude/skills/change-impact-analysis/evals.yaml`** —— 见第 4 步完整内容。 一键验证流程： ```bash # 1. 在真实仓库制造一个导出符号改动 sed -i 's/export function calculate/export function calculate(x, y)/' src/api.js git add src/api.js # 2. 进 Claude Code 会话，自然语言触发（不直呼命令名，测试自动激活） # 输入："提交前帮我看下这次改动的影响" # 3. 让 Skill Creator 跑 evals + 方差 # 用其工作流指向 .claude/skills/change-impact-analysis/evals.yaml # 4. 把稳定的 v2 写入 benchmark；下次模型升级后重跑对比 ``` 预期：自动激活 → 输出含调用方 grep 结果的表格 → evals 通过率 ≥ 3/3、方差 low → benchmark 记录基线。 --- ## 工作流程图 ```mermaid flowchart LR A["写/改 SKILL.md"] --> B["编写 evals 用例
prompt+setup+预期"] B --> C["运行 evals
每例跑 N 次"] C --> D{"通过率 / 方差"} D -->|"失败或不稳"| E["盲测 A/B
v 模糊 vs v 强制"] E --> F["comparator 盲评"] F --> A D -->|"稳定通过"| G["触发评测
调 description"] G --> H["写入 benchmark
= 回归基线"] H --> I["模型升级/改指令
→ 重跑对比基线"] I --> D ``` --- ## 延伸阅读 - **Skill Creator 官方页面**：插件能力的权威说明，含 evals / benchmark / 盲测的官方表述 - **Claude Code Skills 官方文档**：`SKILL.md` 规范、渐进披露原则、skills 与 subagents / commands 的边界 - **社区 eval 实操指南（agensi.io）**：把"模型升级导致 Skill 漂移"讲透，强调 evals 的防回归价值 - **盲测 A/B 详解（mindstudio / perevillega）**：comparator agent 的双盲评判机制与踩坑提醒 --- ## 训练营适用性评估 - **适合类型**：中高级开发者训练营、AI 工程化 / LLMOps 训练营、企业内部"AI 编程提效"进阶班。不适合纯零基础（需先过第 1 轮入门）。 - **前置衔接**：建议放在"Skill 入门（从零创建）"之后，作为**质量工程**模块的开篇。 - **教学时长**：约 3–4 学时。其中讲授 1 学时（可度量性 + evals 体系）、动手实操 2 学时（跑通 4 个用例 + 至少一次盲测迭代）、复盘讨论 0.5–1 学时。 - **学员产出**：每人交付一个带 evals.yaml + benchmark 基线的自定义 Skill，并附一份"迭代前后通过率/方差对比"报告，作为可评分的结业物。 - **可裁剪**：若课时紧张，第 8 步 benchmark 可降为课后自学；第 6 步触发调优可与第 7 步合并演示。 --- ## 参考来源 1. [Extend Claude with skills — Claude Code 官方文档](https://code.claude.com/docs/en/skills) — `SKILL.md` 规范、渐进披露与 skills 管理的权威说明 2. [Skill Creator — Claude Plugin（Anthropic 官方）](https://claude.com/plugins/skill-creator) — 本教程所用 evals / benchmark / 盲测 A/B 能力的来源插件 3. [How to Eval and Benchmark SKILL.md Skills (2026 Guide) — agensi.io](https://www.agensi.io/learn/how-to-eval-benchmark-skill-md) — 模型升级导致 Skill 漂移、用 evals 防回归的实操方法论 4. [How to Use Claude Code Skills 2.0: Built-In Evaluation and A/B Testing — MindStudio](https://www.mindstudio.ai/blog/claude-code-skills-2-evaluation-ab-testing) — 结构化评分与 A/B 对比工作流 5. [What's New in Claude Code Skills 2.0 — Pere Villega](https://perevillega.com/posts/2026-04-01-claude-code-skills-2-what-changed-what-works-what-to-watch-out-for/) — 盲测 comparator agent 的双盲评判机制与注意事项 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。