开篇:这份笔记能帮你解决什么问题
如果你正在用 Claude(或任何大模型)做写作、总结、审阅、编码、整理资料等重复性工作,你很快会遇到两个痛点:
- 同一类任务,每次都要把背景、规则、格式重新讲一遍;
- 输出质量容易波动:有时很稳,有时跑偏,难以复用。
Claude Skills 可以把"可重复任务的知识 + 流程 +资源"打包成可复用的能力单元,让模型在需要时按需加载,从而更稳定地完成特定工作。这篇文章会用最小规范、加载机制、以及一个完整的中文示例,带你快速建立可落地的理解。

1. Claude Skills 是什么
Claude Skills 可以理解成给 Claude 增加"专项能力包"的一种方式:把一类可重复任务的知识、流程和资源打包成一个可复用单元,让 Claude 在需要时再加载它,从而更稳定地完成特定工作。
Anthropic 官方 skills 仓库和 Agent Skills 官方说明都把 Skill 描述为一个由说明、脚本和资源组成的目录;最核心的入口文件是 SKILL.md。
从最小结构看,一个 Skill 至少是这样:
objectivec
my-skill/
└── SKILL.md
在此基础上,还可以按需添加:
- scripts/:可执行脚本
- references/:参考资料或规范文档
- assets/:模板、图片、字体等资源文件
这些目录都是可选的,不是每个 Skill 都需要。

Skill 和一次性的临时提示词最大的区别,在于它是可复用、可维护、可分享的。Anthropic 官方公开仓库本身就是以"一个个独立 Skill 目录"的形式组织示例,目的是展示 Claude Skills 能覆盖的不同任务模式。
2. Skills 有什么作用
Skills 的价值,不是单纯"让 Claude 更聪明",而是让 Claude 在某一类任务上更稳定、更一致、更像一个带经验的专职助手。官方说明里提到,Skills 可以用来处理专业文档、组织内部工作流、创意任务、技术任务以及企业流程。
实际使用里,Skills 通常有四类明显作用。

第一类,是封装专业知识和组织规范。
如果某项任务总要遵守固定规则,比如品牌语气、技术规范、法务措辞、团队输出格式,把这些内容写进 Skill 后,就不用每次重新解释一遍。Agent Skills 官方也明确把"专门知识"和"特定工作流"列为 Skill 的核心用途。
第二类,是沉淀可重复工作流。
很多工作并不难在某一步,而是难在"每次都要从头再走一遍流程"。Skill 可以把输入整理、澄清问题、输出结构、检查清单这些步骤固定下来,让 Claude 更稳定地重复执行。官方 skills 仓库对 Skills 的定义就是:教 Claude 以可重复的方式完成特定任务。
第三类,是让输出更稳定、更可控。
对于写作、总结、审阅、结构化交付物这类任务,Skill 可以约束 Claude 按固定结构输出、使用固定语气、遵守边界条件。
第四类,是按需加载,减少上下文浪费。
Agent Skills 官方说明把这套机制叫作 progressive disclosure。代理在启动时只读取每个 Skill 的名称和描述;当某个任务与描述匹配时,才会把完整 SKILL.md 读入上下文;如果正文还引用了脚本或其他资源,再进一步按需读取或执行。这样既能节省上下文,又能在需要时获得更强的专门能力。
3. Skill 的最小规范与加载机制
如果只讲最小可用版本,一个 Skill 的门槛非常低:一个目录,加一个 SKILL.md 文件就够了。Anthropic 官方仓库 README 和 Agent Skills 官方文档都明确这么写。
SKILL.md 里最关键的是 YAML frontmatter。按照 Agent Skills 官方规范,最小必需字段是:
- name
- description
其中:
- name 是 Skill 的唯一标识,要求使用小写字母、数字和连字符
- description 用自然语言说明这个 Skill 做什么,以及何时应该触发
Agent Skills 规范另外还支持可选字段,例如 license。GitHub 上的相关 issue 也显示,Claude 端对 frontmatter 的可接受字段有明确限制,随意添加常见字段如 version、author 可能导致导入或验证失败。
一个最小的 SKILL.md 通常长这样:
yaml
---
name: my-skill
description: 用一句话描述这个 Skill 做什么,以及什么时候应该使用它。
---
# Instructions
在这里写模型需要遵循的规则与流程。
这里最值得重视的是 description。它不只是简介,也是 Skill 是否会被正确命中的主要触发入口。Agent Skills 官方说明里明确提到,代理启动时先读取的就是 name + description;只有描述匹配任务,才会继续加载正文。
所以,一个好 Skill 的关键,往往不只是正文写得多详细,而是 description 是否把"做什么"和"什么时候用"写清楚了。
4. skill-creator 是什么
skill-creator 是 Anthropic 官方 skills 仓库中的一个"元 Skill"。它不是直接帮你做业务任务的,而是专门帮助你创建、改进、测试和迭代别的 Skill。官方 skill 页面对它的定位就是:一个用于创建新 Skill 并持续改进它们的 Skill。
简单说:普通 Skill 是"解决问题"的;skill-creator 是"帮你把解决问题的方法做成 Skill"的。
它的核心价值有两层。
第一层,是把"写 Skill"这件事流程化。
官方说明里给出的基本循环是:先确定 Skill 要做什么,再写草稿,再设计测试提示,再让 Claude 带着 Skill 跑测试,再基于结果迭代,最后继续扩大测试范围。
第二层,是把"触发效果"也纳入优化目标。
skill-creator 不只关心正文写得对不对,还强调后续可以继续优化 Skill 的描述,让它在真正需要时更容易触发。
如果你是第一次做 Skill,skill-creator 最大的帮助不是"替你写几段文字",而是把你拉回到一条更工程化的路径上:先澄清意图,再做最小版本,再用真实提示测试,再迭代。
5. skill-creator 如何帮助你创建 Skill
把官方思路拆开来看,skill-creator 实际上在帮助你完成四件事。

5.1 澄清意图
官方说明强调,第一步不是立刻开始写,而是先弄清楚:
- 这个 Skill 到底要解决什么问题
- 用户会怎么提这个需求
- 需要哪些输入才能产出好结果
- 希望输出成什么格式
这些问题看上去基础,但它们直接决定 description 是否能触发,以及正文是否能落地。
5.2 生成最小可用版本
skill-creator 倾向于先做一个能用的初稿,而不是一开始做成大而全的系统。官方建议里也有类似思路:先写 draft,再用几个真实测试提示验证。
这一步最重要的是三件事:
- 取一个清晰的名字
- 写一个覆盖真实触发语境的 description
- 在正文里给出规则、默认假设和输出格式
5.3 用真实提示测试
官方 skill-creator 页面建议,在写完草稿后准备 2 到 3 个真实测试提示,先跑起来看结果。它甚至给了 evals.json 的结构示例,用来记录测试 prompt 和期望输出。
这说明一个很重要的事实:Skill 不是"写完就结束",而是要靠真实触发场景来验证。
5.4 继续迭代 description 和正文
官方特别强调两类容易出问题的地方。
- 一类是 description 写得太弱,导致该触发时不触发。
- 另一类是正文规则太模糊,导致即使触发了,输出仍然不稳定。
所以,Skill 的迭代通常也优先围绕这两点展开:
- description 是否覆盖真实使用语境
- 输出格式、规则和检查点是否足够稳定
6. 最简单示例:创建一个"个人介绍 Skill"(中文版本)
下面给一个最小、最实用的例子:做一个属于你自己的 Skill,让 Claude 在你要求"写我的自我介绍""帮我生成个人简介""写个人主页介绍"时,优先按你固定的人设、语气和格式来写。

这个例子的目标不是让 Claude "永久记住你",而是把你的资料、偏好和输出规则封装成一个可复用 Skill。这样的做法,符合官方对 Skills 的定义:把某类可重复任务的说明和资源封装起来,在相关任务发生时再加载。
6.1 第一步:把需求告诉 skill-creator
你可以直接在 Claude Code 里这样说(中文示例):
diff
使用 skill-creator 技能帮我创建一个 personal-profile(个人介绍)skill。
它需要在不同场景下帮我写自我介绍:
- 一句话简介(很短的 bio)
- 正式的职业介绍(用于主页/简历/演讲嘉宾介绍)
- 更口语的社交介绍
当我提出类似这些需求时触发:
- 写我的自我介绍
- 给我一段个人简介
- 帮我写一个个人主页介绍
- 给我一个演讲嘉宾介绍
我的基本信息:
- 姓名:萧凡
- 方向:产品、AI 工作流、自动化
- 风格:清晰、温暖、专业
- 默认输出语言:中文;如果我明确要求英文,再输出英文
这段提示的好处,是把最关键的四类信息一次交代清楚:
- Skill 做什么
- 什么时候触发
- 有哪些输出模式
- 你的基础资料是什么

如图,已使用 skill-creator 将 Skill 打包成一个 .skill 文件。你可以将该文件分享出去,或将 personal-profile.skill 放到对应环境的 skills 目录下。

如果想查看里面的内容可以在文件后添加后缀名.zip,解压之后得到完整的结构

6.2 手工创建一个最小可用的 Skill(目录 + SKILL.md)
如果你不想先用 skill-creator 生成 .skill 文件,也可以直接在本地"纯手工"创建一个 Skill:新建一个目录,并写好 SKILL.md 即可。
最小目录结构如下:
objectivec
personal-profile/
└── SKILL.md
你可以把这个目录放到你自己的 skills 搜索路径下(不同运行环境/工具的默认路径可能不同),之后在对话或运行时按需加载。
下面是一版可以直接参考的最简 SKILL.md 示例:
yaml
---
name: personal-profile
description: 为"萧凡"撰写自我介绍与个人简介,包括:一句话简介、正式职业介绍、社交口吻介绍、个人主页简介、演讲嘉宾介绍等。当用户提出"写我的自我介绍/个人简介/主页介绍/嘉宾介绍"等相似需求时,使用此 skill。默认输出中文;若用户明确要求英文,再输出英文。
---
# 个人介绍(Personal Profile)
除非用户提供更新信息,否则以下资料视为默认事实来源。
## 核心资料
- 姓名:萧凡
- 方向:产品、AI 工作流、自动化
- 默认语言:中文
- 备选语言:英文
- 语气:清晰、温暖、专业
## 写作规则
- 表达具体、自然,避免夸张与空话。
- 句子尽量短,读起来顺。
- 如果用户没有提供场景,先给一版"通用中等长度"的介绍。
- 如果用户指定平台/场景(如:领英、个人主页、演讲、社交媒体),按场景调整长度与语气。
- 如果关键背景缺失:先给一版合理默认稿,再提出 2-3 个精炼追问。
## 输出模式
### 1)一句话简介
用于头像旁/签名档等,1-2 句。
### 2)正式职业介绍
用于个人主页、简历摘要、演讲嘉宾页等。
### 3)更口语的社交介绍
用于社交/轻松场景。
## 默认输出格式
当用户没有指定格式时,按以下顺序返回:
1. 标准版自我介绍
2. 一句话简介
3. 更口语一点的版本
这版示例有几个优点:
- 符合最小规范:有 name、有 description、有正文。
- 把"何时使用"尽量写进了 description(利于触发)。
- 没有引入多余复杂度:对"自我介绍"这种任务,通常不需要脚本也能很好用。
7. 为什么这个最小示例已经够用了
对于"自我介绍型 Skill"这类文本任务,真正决定效果的通常只有三件事:
- 资料是否清楚
- description 是否覆盖真实触发语境
- 输出规则是否稳定
只要这三点写清楚,一个只有 SKILL.md 的 Skill 往往就已经足够实用。Agent Skills 官方文档也明确说明,Skill 可以从纯文本说明起步,再按需要扩展到脚本和资源。
只有当你遇到下面这些情况,才需要进一步引入 scripts/、references/ 或 assets/:
- 需要从外部数据源拉取内容
- 需要把某些重复操作自动化
- 需要依赖复杂模板或品牌资源
- 需要对输出做更机械、更稳定的处理
8. 使用时会怎么触发
这个 Skill 安装好之后,你以后就可以直接说:
写一个我的三句话自我介绍
或者:
帮我写一个放在个人主页上的简介
或者:
给我一个英文的 speaker bio
之所以它更容易在这些场景里起作用,是因为代理在判断是否要调用某个 Skill 时,先看的就是 Skill 的名称和描述。你的用户表达越贴近 description 中列出的真实语境,这个 Skill 越容易被正确加载。

9. 工程实践:如何组织个人级和项目级 Skills
如果你在 Claude Code 里长期使用类似能力,比较合理的组织方式是区分"个人范围"和"项目范围"。Anthropic 官方关于 Claude Code subagents 的文档明确给出了两类存放位置:项目级放在 .claude/agents/,用户级放在 ~/.claude/agents/,并且项目级优先于用户级。
落到 Skills 的组织上,一个很实用的思路是:

个人级 vs 项目级 Skills 组织与优先级
- 个人 Skill:放在个人环境里,服务你的跨项目偏好
- 项目 Skill:跟着仓库走,服务项目特有的术语、规范、流程
- 当两者冲突时:优先采用项目级约束
这不是官方标准文本里的强制规则,但非常符合实际协作逻辑。
10. 写 Skill 时最容易忽略的两个点
第一个,是把 description 写得太短。
很多人会把描述写成一句非常笼统的话,比如"help with writing bio"。这种写法太弱,Claude 不容易判断何时应该触发。更好的做法,是把任务类型和典型触发场景一起写进去。
第二个,是一开始就把 Skill 写得太复杂。
官方 skill-creator 的流程更鼓励先做 draft、先跑测试、再迭代,而不是上来就堆很多脚本和资源。Claude Code 官方关于 subagents 的文档也明确建议:先让 Claude 生成一个版本,再改成适合你自己的版本。
结尾:从"会用"到"可复用"
Claude Skills 的关键,不在于把提示词写得更长,而在于把高频任务的知识、流程和边界沉淀成可以复用的单元。
如果你刚开始上手,最推荐的路径是:先挑一个你最常做的任务(比如写简介、写周报、做文档审阅),用最小结构把它做成一个 Skill,准备 2-3 个真实提示去测试,然后优先迭代 description(能不能触发) 和 输出规则(稳不稳定)。
当这些"可重复"的能力慢慢积累起来,你获得的就不只是更快的输出,而是一套能持续复利的个人工作流资产。
🧪
这里是言萧凡的 AI 编程实验室。
我会在这里持续记录和分享 AI 工具、编程实践,以及那些值得沉淀下来的高效工作方法。
不只聊概念,也尽量分享能直接上手、能够复用的经验。
希望这间小小的实验室,能陪你一起探索、实践和成长。
2026 年,一起进步。