如果你每周都要让 Claude 干同一件事——写周报、审 PR、整理会议纪要——你大概率已经攒了一段固定提示词，每次复制粘贴，偶尔还得改两句。Skill 就是把这段提示词固化成一个可复用的“技能包”：以后不用再贴提示词，你说一句话，它自己就按那套流程干活。

更关键的是，Skill 不占上下文。Claude 平时只常驻它的名字和一句话描述，正文只有在触发时才加载。今天推荐的，就是 Anthropic 官方用来“造 Skill”的 Skill：skill-creator。用它从 0 写一个自己的 Skill，全程不用自己琢磨格式。

一、Skill 是什么，一句话讲清

一个 Skill 就是一个文件夹，里面至少有一个 SKILL.md。这个文件分两部分：顶部的 YAML frontmatter 只有 name 和 description 两个必填项，正文是模型触发后要照着执行的指令。旁边还可以放 scripts/（可执行脚本）、references/（长资料）、assets/（模板），这些只有用到时才读，这叫渐进披露——正文保持短，细节按需取。

放哪里分两种：项目里的 .claude/skills/，跟着仓库走，团队共享；个人的 ~/.claude/skills/，所有项目都能用。文件夹名要和 name 保持一致，这个名字同时就是你手动调用它的命令。

触发全靠 description。它既要写“做什么”，更要写“何时用”——用户会怎么说、什么场景下需要。只写主题不写场景的描述，是 Skill 永远不触发的最常见原因。

二、先装官方的 skill-creator

skill-creator 在 Anthropic 的官方仓库 anthropics/skills 里，它的自我定位就是：创建新 Skill、修改已有 Skill、测评 Skill 表现。也就是说，它不是教你写 Skill 的文档，而是一个会主动带你走完流程的 Skill。

安装有两种方式，任选其一：

# 方式一：插件市场（在 Claude Code 里执行）
/plugin marketplace add anthropics/skills
# 然后安装 example-skills，里面就包含 skill-creator

# 方式二：直接复制文件夹
git clone https://github.com/anthropics/skills
cp -r skills/skill-creator ~/.claude/skills/

装好之后不用学任何命令，直接说一句话就行：“我想做一个帮我写周报的 Skill。”它会接管后面的全部流程。

三、它会带你走的五步

1. 定意图：先回答 4 个问题

skill-creator 动笔之前会先确认四件事：这个 Skill 让 Claude 干什么？什么情况下触发？输出长什么样？要不要写测试用例验证？如果你在对话里已经提过某个工作流，它会先从对话记录里提取答案，不重复问你。

2. 访谈补细节

接下来它会追问边界情况、输入输出格式、成功标准和依赖项。别嫌问题多：这一步没聊透，写出来的 Skill 一跑真实任务就会在边角处翻车。

3. 写草稿：步骤和检查清单，不要散文

正文的写法有讲究：写成“先做什么、再做什么、最后自查什么”的步骤，加上一张检查清单。模型照着步骤执行，比读一段散文可靠得多。长资料不要塞进正文，放到 references/ 里，触发相关步骤时再读。

4. 跑测评：带 Skill 和不带 Skill 各跑一遍

这是大多数人自己写 Skill 时会跳过的一步，也是 skill-creator 最值钱的部分。它会准备一批真实用户会打出来的测试提示——包括口语化、带错别字、背景信息不全的问法——同时跑“带 Skill”和“不带 Skill”两组，再用一个结果查看脚本把两边摊开给你对比、打分。你能亲眼看到 Skill 到底有没有让结果变好，而不是凭感觉。

5. 改描述，防误触发

描述是触发的唯一依据，所以它还有一套专门的描述优化流程：生成一批“应该触发”和“不该触发”的测试问法，跑一圈，再根据结果改描述。记住一条原则：误触发比不触发更伤。一个部署 Skill 在你随口说一句“发了吧”时就动手，比等你一句明确指令要危险得多。

四、一个能直接抄的例子：周报 Skill

按上面的流程，第一个 Skill 别贪大，就做“写周报”这种每周都重复、输出格式固定的事。完整文件如下，存到 ~/.claude/skills/weekly-report/SKILL.md 就能用：

---
name: weekly-report
description: 把本周工作记录整理成结构化周报。Use when the user asks to 写周报、汇总本周进展、整理本周工作、输出本周总结。
---

# Weekly Report

1. 先收集本周记录：向用户要本周的提交记录、任务清单或笔记；缺了就先问，不要编。
2. 按四组归类：已完成 / 进行中 / 下周计划 / 风险与阻塞。
3. 每条只写一句话，并带可验证的事实（链接、单号、日期）；没有依据的写“待确认”，不要编数字。
4. 输出前自查：每条已完成项都有来源；全文没有“大概”“可能”这类含糊词。

验证方法：新开一个会话，直接说“帮我写本周周报”，看它是否自动加载了这个 Skill。如果没触发，别急着重写正文，先回头改 description——把里面的触发词改得更像你平时说话的样子，再试一次。描述改对了，触发问题就解决了一大半。

五、三条容易踩的坑

  • 描述只写主题，不写场景。把“帮助写周报”改成“Use when the user asks to……”的句式，列出用户原话和具体场景。
  • 正文写成散文。步骤加检查清单，永远比一段漂亮的描述更可靠。
  • 一个 Skill 塞太多事。正文写到几百行还收不住，通常是两个 Skill 穿了一件衣服，拆开，触发反而更准。

最后给一个上手顺序：今天先装上 skill-creator，让它陪你做一个最小可用的 Skill，跑一次真实任务，再按测评结果改一版。比起在聊天框里攒提示词，Skill 是唯一能越用越顺手的东西——因为它把“你希望 AI 怎么做事”从一次性输入，变成了可以复用、可以迭代、可以分享的资产。

参考来源