> ## Content Index
> Fetch the complete content index at: http://38.65.91.206/llms.txt
> Use this file to discover other available public pages before exploring further.

# Skill 推荐｜别再复制粘贴同一套提示词：用官方 skill-creator 从 0 写一个自己的 Skill
- URL: http://38.65.91.206/skill-creator-build-your-own-skill/
- Published: 2026-10-28T02:46:55.000Z
- Updated: 2026-10-28T02:46:55.000Z
- Description: 别再复制粘贴同一套提示词：装上 Anthropic 官方的 skill-creator，让它带你走完定意图、访谈、写草稿、跑测评、改描述五步，从 0 写出一个能复用的周报 Skill。
- Author: Cherry
- Tags: skills

如果你每周都要让 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 怎么做事”从一次性输入，变成了可以复用、可以迭代、可以分享的资产。

## 参考来源

- [Anthropic 官方 Skills 仓库 anthropics/skills（README，含插件市场安装方式）](https://github.com/anthropics/skills?ref=38.65.91.206)
- [skill-creator 官方 SKILL.md（创建流程、测评与描述优化方法）](https://raw.githubusercontent.com/anthropics/skills/main/skills/skill-creator/SKILL.md?ref=38.65.91.206)
- [Agent Skills 开放规范 agentskills.io](https://agentskills.io/?ref=38.65.91.206)
- [Claude 官方支持文档：How to create custom skills](https://support.claude.com/en/articles/12512198-creating-custom-skills?ref=38.65.91.206)
- [Anthropic 工程博客：Equipping agents for the real world with Agent Skills](https://anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills?ref=38.65.91.206)