本教程面向已能写出第一个 SKILL.md、却苦于"今天能用、明天模型一升级就飘"的开发者。你将学会用 Skill Creator 插件内置的 Evals（评测）+ 方差分析 + 盲测 A/B + Benchmark 体系，把一个自定义 Skill 从"凭感觉调"变成"用数据迭代"。全程围绕一个真实可运行的变更影响分析（blast-radius）Skill 展开：从骨架创建、编写测试用例、解读报告，到盲测对比两版指令、沉淀回归基线。
SKILL.md 的 frontmatter（name / description）和"渐进披露"概念很多 Skill 教程止步于"写好 description，能被触发就完事"。但这留下两个致命盲区：
Evals 体系解决的就是这两点：用一组带预期结果的测试用例，量化 Skill 的通过率与稳定性（方差），并允许在"不知道来源"的前提下盲测对比两版指令。这是把 Skill 从玩具变成生产级工具的分水岭。
常见误区：把 evals 当成单元测试那种"对/错二值"。实际上 Skill 输出是自然语言，评测本质是用一个评判 agent 按规则打分，更像"双盲临床试验"而非 assert。
Skill Creator 是 Anthropic 官方维护的 Skill 开发工具箱，2026 年的 2.0 版本把 evals、benchmark、盲测 A/B 做成了内置能力。
# 在 Claude Code 交互会话中
/plugin install skill-creator
安装后你获得一组命令，本教程用到三个核心能力：
SKILL.md 骨架预期结果：/plugin list 中能看到 skill-creator，会话内可调用其工作流。
常见问题：国内网络拉取插件市场失败 → 配置代理或用镜像源；插件装上但命令不出现 → 重启会话让命令注册生效。
我们的实战 Skill 做一件事：给定当前 git diff，输出"爆炸半径"——受影响的文件、模块、测试、文档，并给出评审顺序。这在每次提交/合并前极有用，且天然适合用 evals 度量（因为有明确的"对错"信号：是否漏了调用方、风险等级是否合理）。
让 Skill Creator 生成骨架，或直接手写。文件放在仓库的 .claude/skills/change-impact-analysis/SKILL.md：
---
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 <base>` 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 / 提交前 / 合并前"。这是触发命中率的基础。reference.md，按需读取。Confidence 仅 grep 验证才 High、无 diff 必须停止——这些硬规则让评测有客观判据。常见问题：Skill 写完不被触发 → 90% 是
description没覆盖用户的真实措辞；把"blast radius"和"提交前"都写进去。本教程第 6 步会专门讲触发调优。
这是整个体系的核心。一个 evals 用例 = prompt + 前置 setup + 预期（断言/规则）。我们写 4 个能覆盖关键行为的用例，放在 .claude/skills/change-impact-analysis/evals.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 必须停止"）。
在 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）。预期诊断：exported-api-change 方差高，根因是 Procedure 第 3 步用了"any changed exported symbol"但模型有时判断为"非导出"而跳过 grep。这就是第 6、7 步要修的点。
在改行为之前，先确认触发本身没问题——一个没被激活的 Skill，evals 跑得再好也没意义。Skill Creator 的触发评测会拿一批应当激活和不应激活的 prompt，统计命中率与误触发率。
调优 description 的三条经验：
调优后用 Skill Creator 重跑触发评测，命中率应从 ~70% 提升到 95% 区间（参考文末 dev.to 的"2 fixes for ~100% activation"经验）。
这是 Skills 2.0 最强的能力：在不知道输出来自哪个版本的前提下，让一个独立的 comparator agent 评判哪个更好。
针对第 5 步发现的 exported-api-change 方差问题，我们准备两个版本的 Procedure 第 3 步：
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 不知道，所以它的判断可信。把"我看着不错"升级为"盲评胜出"。
当 Skill 通过率稳定、方差低，把这次结果写入 benchmark 作为基线快照。它记录：当时用的模型版本、各用例通过率、方差、平均评判分。
之后两件事会触发"重跑基准"：
养成节奏：每次模型升级 / 每次改指令 → 跑 evals → 对比基线 → 必要时盲测迭代。这才是"用数据维护 Skill"的完整闭环。
把上述步骤凝结成两个文件，放进任意 git 仓库即可跑通：
.claude/skills/change-impact-analysis/SKILL.md —— 见第 3 步完整内容（务必用版本 B 的强制 grep 步骤）。
.claude/skills/change-impact-analysis/evals.yaml —— 见第 4 步完整内容。
一键验证流程：
# 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 记录基线。
flowchart LR
A["写/改 SKILL.md"] --> B["编写 evals 用例<br/>prompt+setup+预期"]
B --> C["运行 evals<br/>每例跑 N 次"]
C --> D{"通过率 / 方差"}
D -->|"失败或不稳"| E["盲测 A/B<br/>v 模糊 vs v 强制"]
E --> F["comparator 盲评"]
F --> A
D -->|"稳定通过"| G["触发评测<br/>调 description"]
G --> H["写入 benchmark<br/>= 回归基线"]
H --> I["模型升级/改指令<br/>→ 重跑对比基线"]
I --> D
SKILL.md 规范、渐进披露原则、skills 与 subagents / commands 的边界SKILL.md 规范、渐进披露与 skills 管理的权威说明[!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 等场景全覆盖。