Skills 生态里仓库成千上万，但有一个 Skill 的地位很特殊：它不帮你写代码、不帮你做 PPT，它专门帮你制造其他 Skill。这就是 Anthropic 官方仓库 anthropics/skills 里的 skill-creator——整个生态的「元技能」。本期把它从目录结构到 SKILL.md 每一段设计全部拆开：你会发现它不只是一个工具，更是一份官方亲自示范的「SKILL.md 应该怎么写」的活教材。官方在里面埋了渐进披露、触发词打磨、双盲测试、防过拟合等一整套方法论，读懂它，你自己动手写第一个 Skill 就有了模板。
flowchart TD
A[anthropics官方仓库] --> B[内容型Skill<br/>pdf与pptx与docx]
A --> C[设计型Skill<br/>canvas与前端]
A --> D[元技能<br/>skill-creator]
D --> E[制造与打磨<br/>其他所有Skill]
内容型 Skill 教 Claude 干一件具体的事，而 skill-creator 教 Claude 干「把事情固化成 Skill」这件事。装好它之后，你对 Claude 说「我想把刚才这套流程做成 skill」，它就会接管整个流程：访谈你、写草稿、生成测试用例、并行跑分、生成评审页面、根据反馈迭代、最后打包成 .skill 文件。
安装方式：
# 从官方仓库安装
git clone https://github.com/anthropics/skills
cp -r skills/skill-creator ~/.claude/skills/
# 或用技能市场 CLI 搜索
npx skills find skill-creator
| 维度 | 权重 | 评分 | 点评 |
|---|---|---|---|
| 功能完整度 | 25% | ★★★★★ | 从意图捕获到打包分发，造 Skill 的全生命周期无一缺席 |
| 设计质量 | 25% | ★★★★★ | 渐进披露、why 优先、双跑对照，官方方法论的浓缩展示 |
| 实战效果 | 20% | ★★★★☆ | 认真走完流程的 Skill 质量提升明显，代价是流程偏重 |
| 上手难度 | 15% | ★★★☆☆ | 全流程有门槛，但支持「vibe 模式」轻量走主线 |
| 社区活跃度 | 15% | ★★★★☆ | 官方维护、随主仓库更新，是大量第三方教程的事实参照 |
单 skill 拆解没有横向对手，更实用的对照是「三种造 Skill 的方式」：
| 造法 | 质量保障 | 触发准确率 | 成本 |
|---|---|---|---|
| 手写 SKILL.md，写完就用 | 无测试，全凭手感 | 碰运气 | 最低 |
| 手写 + 人工试几句 | 主观印象 | 靠感觉 | 低 |
| skill-creator 全流程 | 断言评分 + 基线对照 + 触发评测 | 数据说话 | 高，但可只走子集 |
SKILL.md 开篇没有寒暄，直接给出一条七步流水线：定意图 → 写草稿 → 造测试提示词 → 跑测试 → 和用户一起评估 → 按反馈重写 → 扩大测试集。紧接着是全篇第一处点睛之笔：
Your job when using this skill is to figure out where the user is in this process and then jump in and help them progress through these stages.
翻译过来：你的任务是先判断用户处于流程的哪一步，然后从那一步切入。用户可能说「我想做个 skill」，也可能说「我已有草稿帮我测」，甚至「别搞那些评估，陪我随便写写」（原文是 "just vibe with me"）。这段设计解决的是 Skill 工程的经典难题——同一个技能要接住完全不同成熟度的输入。你写自己的 Skill 时值得抄这一招：开头先列流程，再授权模型自行判断入口，而不是写死一条单行道。
还有个容易被忽略的细节：段落结尾写着 "Cool? Cool."。一份写给模型看的技术文档，官方却用了近乎聊天的语气。这提醒我们 SKILL.md 的读者是 LLM 而不是人——语气不需要板正，清晰和可执行才是唯一标准，适当的口语反而让模型更自然地延续协作氛围。
官方在 "Communicating with the user" 一节写了这么一段观察：
there's a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google "how to install npm"
水管工开始打开终端，父母祖辈开始搜索怎么装 npm。所以它给模型立了行话分级规则："evaluation" 和 "benchmark" 属于默认可以说的词，但 "JSON" 和 "assertion" 必须先确认用户听得懂，或者顺手给一句定义。一个 Skill 会命中什么人，写 Skill 的人最清楚，把沟通策略也写进去，这是绝大多数社区 Skill 完全没意识到的维度。
Capture Intent 一节给了四个必答题：这个 Skill 让 Claude 多会什么本领？什么话、什么场景应该触发它？输出的格式长什么样？要不要配测试用例？第四问它还给了判断启发式：输出能客观验证的（文件转换、数据抽取、代码生成、固定流程）值得配测试；输出主观的（文风、绘画）就不必强测。
更实用的是前一段：如果用户说「把咱们刚才这套做法固化成 skill」，模型应该直接从对话历史里提取答案——用了哪些工具、什么步骤顺序、用户纠正过什么、输入输出长什么样——再让用户补漏确认。这一段实际上教会模型「观察你已经发生过的工作流」，是把隐性经验显性化的正确姿势。
进入正文核心。它明确 frontmatter 的必填项是 name 和 description，可选 compatibility（声明依赖的工具），然后说了一句整个生态最重要的话：
This is the primary triggering mechanism - include both what the skill does AND specific contexts for when to use it. All "when to use" info goes here, not in the body.
description 是技能触发的唯一主要机制，所有「什么时候用」的信息必须写在这里，而不是正文里。 正文写得再漂亮，模型没触发就一个字都读不到。它还点破了一个现状：Claude 目前倾向于 "undertrigger"——明明该用却不用。对策是把 description 写得「pushy」一点，原文给的示例值得全文背诵，普通写法是：
How to build a simple fast dashboard to display internal Anthropic 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.'
划重点：把用户可能说的每一个近义触发词（dashboards / data visualization / internal metrics / any kind of company data）都枚举进 description，并且明确「即使用户没说出 dashboard 这个词也要触发」。社区里大量 Skill 触发率低的病根就在这一行。
Anatomy 一节给出标准骨架：
skill-name/
├── SKILL.md (required)
│ ├── YAML frontmatter (name, description required)
│ └── Markdown instructions
└── Bundled Resources (optional)
├── scripts/ - Executable code for deterministic/repetitive tasks
├── references/ - Docs loaded into context as needed
└── assets/ - Files used in output (templates, icons, fonts)
三分法的依据是加载时机：scripts/ 是确定性重复任务的可执行代码，执行时根本不用读进上下文；references/ 是按需载入的文档；assets/ 是产出时要用的模板、图标、字体。
其上叠加三级渐进披露：
配套的模式指令：逼近 500 行就再加一层层级并写清「接下来去哪读」；引用文件必须写明什么情况下读它；超过 300 行的大参考文件要带目录。多领域技能按变体拆文件（cloud-deploy 下分 aws.md、gcp.md、azure.md），Claude 只读命中那一个。这一套是官方对「上下文经济学」的标准答案：常驻的尽量小，贵的东西按需取。
Writing Style 一节是全篇的灵魂：
Try to explain to the model why things are important in lieu of heavy-handed musty MUSTs.
以及这句黄旗警告：
If you find yourself writing ALWAYS or NEVER in all caps, or using super rigid structures, that's a yellow flag
官方的判断是：今天的模型足够聪明，有不错的心理理论能力，给它讲清楚为什么这么做重要，它能把事情做到超出死规则的水平；满屏大写 ALWAYS/NEVER 反而是写作者偷懒的信号。改进一节还补了刀——哪怕用户反馈很糙很火大，也要真正理解用户在气什么，把那份理解转译成指令，而不是加更多枷锁。
写作模式上它给了两个可直接套用的模板：输出格式用「ALWAYS use this exact template」+ 完整骨架；示例用 Input/Output 成对出现。另外全篇指令几乎都用祈使句——这是写给执行者的文档，不是写给评审看的散文。
还有一条容易被略过的安全条款，官方起了个名字叫「无意外原则」（Principle of Lack of Surprise）：Skill 里不得含恶意软件、漏洞利用代码或任何危害系统安全的内容，Skill 的实际意图不得与描述相悖。你在市场上装第三方 Skill 时，这一条就是审查底线。
这是 skill-creator 最「重」也最见功力的部分。测试用例存进 evals/evals.json，每条包含 id、prompt、expected_output。跑测试时有个强规定：每个用例同一回合内并行 spawn 两个子代理——一个带技能，一个不带（基线），而不是先跑完带技能的再补基线，理由是让所有运行同时结束、尽快进入评审。改进已有技能时，基线换成「旧版本快照」，这样对比出的才是技能本身的增益。
接下来是一连串工程细节，每一处都值得抄：
total_tokens 和 duration_ms 存进 timing.json，因为「这是唯一能拿到这份数据的机会」；grading.json 的字段名被硬性约定为 text、passed、evidence，原文明说评审页面依赖这些确切字段名——接口契约写死，工具链才不会各说各话；eval-viewer/generate_review.py 生成浏览器评审页，Outputs 页逐条展示提示词、产物、上轮对比、人工反馈框；Benchmark 页展示量化对比。用户逐条点评后点「Submit All Reviews」，反馈落进 feedback.json，空反馈即默认满意。整套设计的关键思想：技能好不好，不靠作者自嗨，靠「带与不带」的差值说话，且差值要同时有人评和机评两条证据链。
拿到反馈后怎么改？它给了四条原则，条条戳中写提示词的人的通病：
create_docx.py，这就是强烈信号——把它写一次放进 scripts/，让每次调用直接复用。中间还夹了一句大实话："we are trying to create billions a year in economic value here!"——别嫌较真，你写的是要被复用无数次的资产，多花心思不亏。
高级玩法还有盲对比（blind comparison）：把两个版本的产物不加标注地交给独立代理评判，再分析赢家赢在哪。官方自己也承认这只是可选项，多数场景人工评审循环已够用——诚实地给方法标定适用边界，这本身也是好文档的写法。
技能写完后，它还有一整套 description 优化流水线，这是全文工程密度最高的段落：
第一步，造 20 条触发评测查询，应触发与不应触发各约 10 条。原文对查询质量的要求近乎苛刻：必须真实、具体、带细节（文件路径、列名、公司名、口语错字都要有），并给了一组教科书级的反例对比——坏查询是 "Extract text from PDF" 这种抽象短语；好查询是：
ok so my boss just sent me this xlsx file (its in my downloads, called something like 'Q4 sales final FINAL v2.xlsx') and she wants me to add a column that shows the profit margin as a percentage...
更精妙的是对否定用例的要求：最有价值的 should-not-trigger 是「near-miss」——共享关键词、概念相邻、朴素关键词匹配会误触发但实际该用别的工具的查询。像「写个斐波那契函数」这种明显无关的否定用例「测不出任何东西」。考验触发词的不是正面命中，而是边缘误伤。
第二步，用 assets/eval_review.html 模板生成可编辑页面让用户增删查询、翻转 should-trigger 标记。原文直言：坏的评测查询 leads to 坏的描述。
第三步，跑自动优化循环：评测集按 60%/40% 切成训练与保留测试集，当前描述每条查询跑 3 次取可靠触发率，失败样本交给模型提议改进，如此最多迭代 5 轮。最关键的一笔是：最终 best_description 按测试集分数而非训练集分数选出——在描述优化这件小事上也不忘防过拟合。
优化器一节顺带公开了触发机制的底牌：技能以 name + description 出现在模型的 available_skills 列表里，由模型自行决定是否查阅。而一个反直觉的事实是：
Claude only consults skills for tasks it can't easily handle on its own — simple, one-step queries like "read this PDF" may not trigger a skill even if the description matches perfectly.
简单的一步任务，即使描述完美匹配也可能不触发，因为模型用基础工具就能直接干。这解释了无数人的疑惑「装了技能为什么没反应」：可能不是 description 写得差，而是任务本身不够复杂。它顺势给出推论——触发评测查询必须「有足够分量」，"read file X" 这类简单查询是劣质测试用例，怎么写描述都不会触发。
结尾部分处理真实世界的参差：在 Claude.ai 上没有子代理，就由主代理自己串行执行测试（并坦诚标注「这不如独立子代理严格，因为写技能的和跑技能的是同一个我」，靠人工评审补偿）；没有浏览器就不起评审服务，直接在对话里贴结果；量化基准依赖基线对照，在没有子代理的环境里「对照无意义」，果断跳过。Cowork 环境则改用 --static 生成单文件 HTML 评审页。同一套方法论在不同能力环境下如何取舍降级，官方给出了一份逐项声明的清单——这是把技能做成「跨平台软件」的意识。
最后 package_skill.py 把目录打成 .skill 分发文件，并交代了更新既有技能的三条纪律：保留原 name 不加 v2 后缀；安装路径可能只读，先拷到 /tmp 再改；手工打包先在 /tmp 暂存再落盘。
flowchart TD
A[意图捕获<br/>四问清单] --> B[访谈补漏<br/>边界与依赖]
B --> C[写SKILL.md草稿]
C --> D[造2至3条真实测试提示]
D --> E[同回合并行双跑<br/>带技能对照基线]
E --> F[等待期起草断言]
F --> G[评分聚合<br/>benchmark]
G --> H[分析师过检<br/>找无区分度断言]
H --> I[生成评审页面]
I --> J[读feedback.json]
J --> K{满意或反馈全空?}
K -->|否| L[四原则改写]
L --> E
K -->|是| M[描述优化循环<br/>20条触发查询]
M --> N[打包分发<br/>package_skill]
渐进披露的三级装载单独看更清楚：
flowchart TD
A[第一级<br/>name与description<br/>常驻约100词] --> B[第二级<br/>SKILL.md正文<br/>触发后载入限500行]
B --> C[第三级<br/>references与scripts与assets<br/>按需取用不设限]
一句话总结：skill-creator 表面上是个工具，实际上是官方把自己写 Skill 的全部内功——上下文经济学、触发心理学、评测方法论、防过拟合纪律——写成了一份可供模型执行的清单。拆完它，你手里就有了生态里最硬的一份「SKILL.md 写作规范」。
[!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 等场景全覆盖。