「从零开始写好 Skill」系列 —— 上一个系列我们用 7 篇文章拆解了 Agent 的骨架，这个系列教你给 Agent 写"工作手册"。

• 第一篇：Skill 是什么？为什么你应该关心它
• 第二篇：一个好 Skill 长什么样——SKILL.md 的解剖
• 第三篇：手把手写你的第一个 Skill
• 第四篇：写 Skill 太费劲？让 skill-creator 来帮你（本文）

开场：三轮迭代的代价

还记得第三篇吗？

我们从零写了一个 article-summarizer，经历了三轮迭代：第一版 description 触发不了、输出格式不稳定；第二版对照检查清单修了一遍，好多了但实际跑起来又发现观点数量太死板、字段之间撞车；第三版基于踩坑再优化，终于好用了。

三轮迭代，每一轮都要自己思考问题在哪、怎么改、改完再跑一遍验证。这还只是一个功能很简单的总结 Skill。如果你要写一个代码审查 Skill、一个部署流水线 Skill，复杂度翻几倍，迭代次数也会翻几倍。

有没有办法让这个过程更高效？

有。Anthropic 官方出了一个"元技能"—— skill-creator。它本身就是一个 Skill，但它的职责是帮你创建和优化其他 Skill。

用 AI 来写 AI 的工作手册。

一、skill-creator 是什么

一句话：它是一个帮你创建、测试和迭代 Skill 的 Skill。

它覆盖了 Skill 开发的完整生命周期：

1. 理解你的意图——你想让 Skill 做什么
2. 起草 SKILL.md——包括 description、操作流程、注意事项
3. 生成测试用例——验证 Skill 效果
4. 运行对比评估——有 Skill vs 没 Skill，效果差多少
5. 基于评估结果迭代优化
6. 优化 description 的触发精准度

本质上，它把第三篇里我们手工做的三轮迭代，变成了一个系统化的、有数据支撑的流程。你不需要自己猜"description 写得够不够好"，它会用 20 个测试查询帮你验证；你不需要自己判断"总结质量提升了没有"，它会并排对比有 Skill 和没 Skill 的输出，让你一目了然。

二、先看它的文件夹结构

在讲怎么用之前，先看看 skill-creator 自己长什么样。它是"Skill 是文件夹不是文件"这个概念的最佳实例：

skill-creator/
├── SKILL.md              ← 主文件：完整的创建流程指南
├── agents/               ← 子代理定义
│   ├── grader.md         ← 评分员：评估测试结果
│   └── analyzer.md       ← 分析员：找出数据背后的模式
├── eval-viewer/          ← 评估结果可视化工具
│   └── generate_review.py
├── references/           ← 参考资料
│   └── schemas.md        ← 评估数据的 schema 定义
├── scripts/              ← 辅助脚本
│   ├── init_skill.py     ← 初始化新 Skill 的目录结构
│   ├── package_skill.py  ← 打包 Skill 用于分发
│   └── aggregate_benchmark.py  ← 聚合评估数据
└── assets/               ← 模板等资源

一个 SKILL.md 主文件，搭配子代理定义、脚本、参考资料、可视化工具。Agent 读 SKILL.md 了解整体流程，执行时按需调用 scripts/ 里的脚本，评估时启动 agents/ 里定义的子代理，最后用 eval-viewer/ 生成可视化报告。

这就是第二篇讲的"渐进式揭示"的教科书案例——SKILL.md 不塞所有内容，而是指向各个子文件，Agent 在需要的时候才去读。

三、完整流程：从意图到成品

安装好 skill-creator 之后，告诉它你想创建什么 Skill，它会引导你走完以下六个阶段。

阶段一：意图捕获

skill-creator 不会让你一上来就写 SKILL.md。它先用"采访模式"收集需求：

• "这个 Skill 要解决什么问题？"
• "用户会怎么描述这个需求？给几个具体的说法。"
• "给几个具体的使用场景？"
• "有没有什么边界条件——哪些事情这个 Skill 不该做？"

它会根据你的回答追问细节，但不会一次问太多——它的 SKILL.md 里明确写了"避免在一条消息里问太多问题"。

这里有一个细节值得注意：skill-creator 会根据你的技术水平调整表达方式。它的 SKILL.md 里有一段很有意思的话——大意是"现在连水管工都开始打开终端了，另一方面大多数用户又是程序员，所以要看上下文线索来决定怎么说话"。比如 "JSON" 和 "assertion" 这种词，它会先确认你是否了解再使用。

这个设计本身就是一个好 Skill 该有的样子：不假设用户的背景，根据上下文自适应。

阶段二：起草

收集完需求后，skill-creator 调用 scripts/init_skill.py 自动生成 Skill 的目录结构：

# skill-creator 自动执行
python scripts/init_skill.py my-new-skill

生成一个标准的 Skill 文件夹，包含 SKILL.md 模板和 scripts/、references/、assets/ 子目录。然后它会基于你在第一阶段提供的信息，填充 SKILL.md 的内容。

它生成的 SKILL.md 会自动遵循我们前几篇讲的原则：

• description 写成触发条件，而且覆盖面写得比较宽。比如不只写"当用户要求创建仪表盘时触发"，还会加上"即使用户没有明确说'仪表盘'，只要提到了数据可视化、内部指标，都应该触发"。这和第二篇讲的"覆盖用户多种说法"一脉相承，宁可多触发也不要漏触发。

• 内容区分"参考知识"和"任务流程"——该放进 references/ 的不会塞在 SKILL.md 里。

• 可复用的脚本放进 scripts/——确定性的工作交给代码，不靠 AI 每次重写。

它还会特别提醒你：写 Skill 是给另一个 Agent 实例看的，重点放在对 Agent 有用但不是显而易见的信息上。 不需要教 Agent "什么是 API"，但需要告诉它"调用这个 API 时必须传 X-Auth-Token 头，否则返回 403"。

阶段三：测试

这是 skill-creator 最有价值的部分。

它会为你的 Skill 生成一组测试用例，然后对每个用例同时启动两个子代理：

• 一个带着你的 Skill 执行任务
• 一个不带任何 Skill 执行同样的任务

两个子代理并行跑（不是先跑完一个再跑另一个），输出放在一起对比。

这直接回答了一个关键问题：你的 Skill 到底有没有用？ 不是你主观感觉"好像好了一点"，而是有/无 Skill 的输出并排放在面前，差距一目了然。

还记得第一篇那个公众号文章的对比吗？没有 Skill 的 Agent 说"我做不到"，有 Skill 的 Agent 说"做好了"。skill-creator 把这种对比变成了一个可重复执行的自动化流程——每次修改 Skill 之后都能重新跑一遍，量化改进效果。

阶段四：评分和分析

测试跑完后，skill-creator 启动两个专门的子代理来处理结果：

评分员（grader）：对每个测试用例的输出打分。能用脚本程序化验证的断言（比如"输出文件是否存在""格式是否符合 JSON schema"），就写脚本去检查，不靠 AI 的主观判断。只有需要定性评估的部分（比如"总结质量如何"）才用 AI 打分。

这个设计原则值得记住：确定性的事交给脚本，判断性的事交给 AI。 脚本更快、更稳定、可复用；AI 擅长做需要理解和判断的事，但不该浪费在"检查文件是否存在"这种事情上。

分析员（analyzer）：在评分数据的基础上找模式。比如：

• 某些断言不管有没有 Skill 都通过——说明这个断言没有区分度，需要改
• 某些测试方差很大——可能是断言本身不稳定
• 时间和 Token 的消耗变化——Skill 是否让 Agent 更高效了

最后生成一个交互式的浏览器页面（通过 eval-viewer/generate_review.py），你可以在页面上直观地看到每轮迭代的效果变化、定性输出和定量指标。

# skill-creator 自动执行，你也可以手动运行
python eval-viewer/generate_review.py \
  my-skill-workspace/iteration-1 \
  --skill-name "my-skill" \
  --benchmark my-skill-workspace/iteration-1/benchmark.json

阶段五：迭代

看完评估结果，你告诉 skill-creator 哪里不满意、需要怎么改。它会修改 SKILL.md，然后重新跑一轮测试，对比新旧版本的 benchmark 数据。

从第二轮迭代开始，评估报告会自动和上一轮对比，你能清楚地看到每次修改带来的变化——通过率是上升还是下降、Token 消耗是增加还是减少、哪些原来失败的测试现在通过了。

这就是第三篇里我们手工做的事情——但 skill-creator 把它从"靠感觉"变成了"靠数据"。

阶段六（可选）：description 优化

skill-creator 还有一个专门优化 description 触发精准度的功能。

它会生成 20 个测试查询：10 个应该触发这个 Skill 的，10 个不应该触发的。然后检查你的 description 在这 20 个查询上的匹配准确率，最多迭代 5 轮，每轮都调整 description 的措辞，直到准确率满意为止。

这个功能直接对应第二篇的关键点——"description 是触发器，不是摘要"。手工优化 description 很靠直觉，而 skill-creator 用 20 个测试查询把它变成了一个可量化的优化过程。

四、安装和上手

一条命令安装：

npx skills add https://github.com/anthropics/skills --skill skill-creator

安装完成后，在 Agent（如 Claude Code）里就可以直接使用了。

如果你想从零创建一个新 Skill，直接告诉它你的需求：

它会引导你走完意图捕获 → 起草 → 测试 → 迭代的完整流程。

如果你已经有一个写好的 Skill 想优化，把路径告诉它：

它会对现有 Skill 做评估，找出问题，给出改进建议。

建议的上手路径：先用它优化你已有的 Skill，再用它从零创建新的。 优化一个已有的 Skill 能让你快速熟悉 skill-creator 的评估流程，理解"测试用例""断言""benchmark"这些概念在实际中怎么运作。有了这个基础，再从零创建就顺畅多了。

五、skill-creator 教给我们的三条设计理念

抛开工具本身不谈，skill-creator 的设计里藏着几条值得所有 Skill 作者学习的理念。

理念一：description 宁可写宽，不要写窄

大多数人写 description 倾向于保守——只在用户明确说出关键词时才触发。skill-creator 的建议是反过来：主动覆盖用户可能的各种说法，甚至用户没有明确提到关键词时也该触发。

它给的例子很直观：不要只写"当用户要求创建内部数据仪表盘时使用"，而是写"当用户提到仪表盘、数据可视化、内部指标，或者想展示任何类型的公司数据时使用，即使他们没有明确说'仪表盘'这个词"。

道理很简单：Skill 多触发一次，Agent 发现不需要，顶多忽略掉，没有损失。但 description 写得太窄导致该触发的时候没触发，用户就得不到帮助。漏触发的代价远大于多触发。

理念二：确定性的事交给脚本

skill-creator 的测试流程里，能用脚本验证的断言绝不用 AI 打分。"文件是否生成了"，"JSON 格式是否正确"，"行数是否在范围内"——这些有明确对错的事情，写一段脚本检查比让 AI 每次"看一眼"更快、更准、更稳定。

这个原则适用于所有 Skill 的设计：把确定性的操作封装成脚本放在 scripts/ 目录里，让 AI 专注于需要理解和判断的部分。 AI 的精力应该花在"这段代码的设计是否合理"这种问题上，而不是"这个文件是不是存在"。

理念三：Skill 是写给另一个 AI 的

skill-creator 在创建 Skill 时有一条很关键的提醒：你写的 Skill 是给另一个 Agent 实例使用的。重点应该放在"对 Agent 有用但不是显而易见的信息"上。

什么是"显而易见的"？Agent 已经知道怎么写 Python、怎么调用 REST API、怎么格式化 Markdown——这些不需要你在 Skill 里重复。

什么是"不显而易见的"？你们团队的内部 API 要传一个特殊的认证头、某个库的 2.x 版本有一个文档没提到的 bug、部署到生产环境前必须先跑冒烟测试——这些才是 Skill 应该写的内容。

Skill 的价值在于填补 AI 的知识盲区，而不是重复 AI 已经知道的东西。

六、工具和手艺

skill-creator 是一个好工具。但工具不能替代理解。

如果你跳过前四篇，直接用 skill-creator 来生成 Skill，你会遇到几个问题：它生成的 SKILL.md 你看不懂为什么这样写；评估结果出来了你不知道哪些指标重要；测试失败了你不知道是 Skill 的问题还是测试用例的问题。

反过来，如果你理解了 Skill 的本质（第一篇）、知道每个部分怎么写才有效（第二篇）、经历过手工迭代的过程（第三篇），再来用 skill-creator，你会发现——它加速的是你本来就知道该怎么做的事情。

意图捕获阶段，你知道该提供什么样的使用场景。起草阶段，你能判断它生成的 description 覆盖面够不够宽。测试阶段，你能设计出有区分度的断言。迭代阶段，你能从 benchmark 数据里读出真正的问题。

先学会手艺，再用工具放大效率。这个顺序不能反。

下一篇预告

到这里，你已经掌握了从理解 Skill、拆解 Skill、手写 Skill 到用工具加速的完整链路。

但我们一直在聊"一个 Skill"。真实的工作场景，往往需要多个 Skill 组合——先抓取再总结、先审查再修复、先收集需求再生成方案。下一篇，我们聊怎么拆开写、串起用，以及什么时候该拆、什么时候不该拆。

「从零开始写好 Skill」系列是「从零开始理解 Agent」系列的姊妹篇。如果你还没有读过 Agent 系列，建议先从 第一篇：Agent 的底层原理 开始。

关注 AGENT 魔方公众号，回复 Agent

免费领取「从零开始理解 Agent」全套资料包

加速入门和掌握 Agent: