前面已经详细介绍了 SKILL 的本质和设计使用，今天来看 Claude 官方提供的元技能 skill-creator，怎么帮助你创建更好的SKILL。
一、skill-creator 是什么
skill-creator 是 Anthropic 官方的元技能（Meta-Skill），用来创建、测试、评估和改进其他技能。它自己就是一个 Skill，某种意义上算是 Skill 系统"用自己造自己"的例子。
一句话核心
skill-creator 本质是一个"Skill 工程化系统"，不是写 SKILL.md 的模板器。它把"写技能"升级为"假设 → 实验 → 度量 → 人审 → 迭代"的研发流程，重点解决三个问题：
- 技能是否真的提升了结果质量，还是只是心理安慰
- 技能是否在正确场景被触发，触发精度和召回怎么样
- 技能在模型升级后还有没有用，会不会过时
为什么需要它
Anthropic 官方博客提到："most authors are subject matter experts, not engineers"。很多写技能的人是领域专家，不是工程师。
skill-creator 把软件开发的那套东西（测试、基准测试、迭代改进）搬到了技能创作过程中，作者不需要写代码也能用起来。
两类技能的区分
在用 skill-creator 之前，先搞清楚技能的两种类型：
| 类型 | 说明 | 示例 |
|---|---|---|
| 能力提升型 | 让 Claude 做到基础模型搞不定的事 | 用特定技术创建文档 |
| 偏好编码型 | 按组织工作流编排 Claude 已有的能力 | NDA 审查流程 |
这个区分很重要。能力提升型技能可能随模型进化而过时，偏好编码型则需要持续验证是否匹配团队实际流程。两类技能的评估逻辑也不同：提升型看"有技能 vs 没技能"能不能拉开差距；流程型看是否稳定遵守团队规范。
核心工作流程
skill-creator 的完整流程：
捕获意图 → 面试调研 → 撰写 SKILL.md
↓
创建测试用例 → 运行(with/without skill)
↓
评估与评分 → 生成基准报告
↓
人工审核(Viewer) → 反馈
↓
改进 Skill → [回到运行测试]
↓
描述优化 → 打包发布
整个过程就是"草稿 → 测试 → 评估 → 改进 → 再来一轮"的循环。
二、skill-creator 使用
触发方式
在 Claude Code 中调用 skill-creator：
/skill-creator create # 创建新技能
/skill-creator eval # 评估技能
/skill-creator improve # 改进技能
/skill-creator benchmark # 基准测试
也可以直接用自然语言，比如"帮我创建一个技能"，Claude 会自动识别并调用。
Create 模式：创建新技能
第一步：意图捕获
告诉 AI 你想要什么技能。这里有个技巧：用真实场景描述，别写抽象需求。
差：创建一个处理数据的技能
好：我老板发了个 xlsx 文件（在下载目录，叫 Q4 sales final FINAL v2.xlsx），
她要我加一列显示利润率百分比。收入在 C 列，成本在 D 列
前者太模糊，AI 不知道该做什么；后者具体到文件名和列号，AI 能准确理解意图。
第二步：面试调研
AI 会追问关键细节：
- 目标用户是谁，技术背景如何
- 输入输出格式
- 边界情况怎么处理
- 依赖哪些工具或 MCP
第三步：生成 SKILL.md
AI 生成标准化的技能文件，包含 YAML frontmatter（name + description）、工作流程、示例、参考文件等。
第四步：立即测试
技能创建后直接调用看效果。
Eval 模式：评估技能表现
Eval 模式做的事情是并行测试加严格评分。
5 步执行流程：
- 并行启动所有运行 - 同一 turn 启动 with-skill 和 baseline。新技能的 baseline 是不用任何技能，改进已有技能的 baseline 是旧版本快照
- 利用等待时间起草断言 - 要求客观可验证、命名有描述性、不搞主观判断
- 捕获计时数据 - total_tokens、duration_ms 来自任务通知，只有一次捕获机会，错过就没了
- 评分 + 聚合 - Grader 评分 → aggregate_benchmark.py 聚合 → Analyzer 分析
- 读取反馈 - 空反馈表示认可，重点看有具体意见的用例
什么算好的断言：
| 好的断言 | 坏的断言 |
|---|---|
| 客观可验证 | 主观判断 |
| 有区分力（有技能 vs 没技能结果不同） | 总是通过（比如"输出是文件"） |
| 检查内容正确性 | 只检查文件名是否存在 |
| 命名一眼看懂 | 命名写成"test-1" |
Eval Viewer 交互式审核：
评估结果通过浏览器查看。Outputs 标签页逐个展示测试用例和输出文件（支持内联渲染），Benchmark 标签页展示统计摘要和配置对比。Server 模式下刷新浏览器就能看到最新结果。
Improve 模式：改进技能设计
Improve 模式根据评估数据给出改进方向。
改进建议分几类：指令修改、脚本和工具的增删改、示例补充、错误处理指导、内容重组、参考文档引用。
这里有个原则值得单独说：泛化，不要过拟合。改进要从反馈中抽取通用规律，不是给某个测试用例打补丁。写技能指令的时候如果发现自己满篇大写 MUST/NEVER，该停下来想想能不能用推理解释清楚。
Benchmark 模式：基准测试对比
技能趋于稳定后，Benchmark 模式做量化评估。
对同一组测试用例跑多次（比如 10 次），看成功率是否稳定、执行时间分布怎样、输出质量一不一致。统计上用样本标准差（n-1 除法），两个配置之间算 Delta。
有一点要注意：Benchmark 模式的 Analyzer 只负责发现模式和异常（哪些断言区分力不够、哪些评估方差太大），不会输出改进建议。改进是 Improve 模式的事。
三、简单分析 skill-creator 内容
三个智能体
skill-creator 背后跑着三个独立的智能体（agent），各管一摊。
Grader Agent（评分）
干两件事：一是给每条断言判 PASS/FAIL，二是反过来批判断言本身写得好不好。
评分标准很严格，走证据导向。有明确证据且确实完成了任务才算 PASS；证据不足、矛盾、无法验证或者只是表面满足（比如文件名对了但内容是空的），统统 FAIL。拿不准的时候，举证责任在断言一方，偏向判 FAIL。
Comparator Agent（盲比较）
两份输出标记为 A 和 B，比较者不知道也不能推断哪个是用了技能的、哪个是没用的。纯粹看输出质量打分：内容维度（正确性、完整性、准确性）和结构维度（组织性、格式化、可用性），各项 1-5 分。平手很少，因为设计上就要求尽量分出高下。
Analyzer Agent（分析）
这个智能体有两种工作模式，别搞混了：
- 事后分析模式：盲比较完成后"解盲"，看指令遵循度（1-10 分），给出改进建议
- 基准分析模式：基准测试聚合后运行，只找模式和异常，明确不允许提改进建议
设计上几个有意思的点
渐进式加载
三层加载，按需消耗上下文。元数据（name + description）约 100 词，始终在上下文里。SKILL.md 正文在技能触发时才加载，建议控制在 500 行以内。scripts/ 和 references/ 之类的捆绑资源按需加载，没有大小限制。
脚本可以直接执行而不用先加载进上下文，这个设计挺聪明的，省了不少 token。
无意外原则
技能的实际行为不应超出描述范围。技能不能包含恶意代码，这点不用多说。
解释 Why 而非强制 Must
写技能指令时，与其用大写 ALWAYS/NEVER 吼模型，不如解释清楚为什么要这么做。今天的 LLM 理解能力够强了，给它讲道理比给它下死命令效果好。
人在循环中
关键决策由人来审，重复工作交给自动化。这个在 Eval Viewer 的设计上体现得很明显。
关键工程机制
触发评测引擎（run_eval.py）
不是用 regex 匹配字符串，而是通过 claude -p + 流式事件检测技能是否真的被调用了。
具体做法：创建临时 .claude/commands/<name>.md 文件把被测描述注入进去，用 --output-format stream-json 做流式早期检测，还会移除 CLAUDECODE 环境变量来支持嵌套运行。每条查询默认跑 3 次，算触发率。
描述优化循环（run_loop.py）
这个设计挺有意思。它把 description 优化建模成了一个机器学习问题，做了 train/test split 来防过拟合。
默认 40% 的评估查询留作测试集，最多迭代 5 次。
最精妙的地方是 Blinded History 机制：改进模型完全看不到测试集，也看不到测试分数。它只能基于训练集的失败案例来改进描述。最终选型时才拿测试集来评判。这是标准的 ML 工程实践，在 prompt 优化场景中用起来很到位。
Description 怎么写
Claude 有个倾向：对技能"欠触发"，就是明明该用的时候不用。所以描述要写得"推"一点。
弱描述：
How to build a simple fast dashboard to display internal data.
强描述：
How to build a simple fast dashboard to display internal data.
Make sure to use this skill whenever the user mentions dashboards,
data visualization, internal metrics, or wants to display any kind
of company data, even if they don't explicitly ask for a 'dashboard.'
好的描述要包含：做什么、什么场景该触发、用祈使语气写、解释为什么 Claude 应该用这个技能。
用 skill-creator 创建技能只是第一步。后面在实际使用中调整、根据反馈改进、甚至分享给团队其他人，这些才是真正花时间的地方。一个技能用着用着发现哪里不对劲，回去改改再跑一轮评估，慢慢磨出来的东西才好用。
