前面几篇文章里，我们已经聊过 CLAUDE.md（记忆系统）、Slash Commands（快捷命令）、Checkpoint & Rewind（后悔药）和 Subagents（分身术）。

如果说这些能力是在提升 Claude 的基础能力，那么今天要讲的 Skills，则是在教 Claude 学会一门新的职业技能。

很多人使用 Claude Code 一段时间后，都会遇到同一个问题：每次都要重复解释。比如，帮我写 Commit Message，格式按 Conventional Commit。过两天又要说一次。再比如，帮我 Review 代码，重点关注性能、安全性和可维护性，下次还得重新解释。甚至帮我生成 PR 描述，按照我们团队模板来，每次都要重新输入。时间久了你会发现 Claude 其实不是不会，而是它每次都要重新学习。Skills 的出现，就是为了解决这个问题。

考虑到Skills的内容比较多，Skills相关的功能将分成两篇来写，这是上篇。

什么是 Skills？

官方给出的定义是，Skills 是 Claude Code 可以自动发现和调用的能力包。你可以简单理解成给 Claude 安装插件，但这个插件不是代码插件，而是一套规则、一套经验、一套工作方法。

例如，如何写 Commit Message、如何做代码Review、如何写技术文档、如何生成周报、如何分析日志、如何检查前端设计规范……

你只需要教一次，以后 Claude 遇到类似任务时，就会自动使用。假设你每天都要让 Claude 帮你写 PR 描述，你总是这样说：请根据代码改动生成 PR 描述，格式如下：

CODE
What
Why
Changes

连续说几十次之后，你会发现自己已经变成了复制粘贴机器人。这时候就应该把这套规则做成一个 Skill，以后你只需要说：帮我写一个 PR 描述，Claude 就会自动调用对应规则，输出永远保持一致。

Skills 到底是怎么工作的？

很多人以为， Claude 会把所有 Skills 全部加载进上下文，其实不是。Skills 使用的是一种很聪明的机制：渐进式加载（Progressive Disclosure）。整个过程大概分三步：

第一步：先看简介 

Claude 启动时并不会读取整个 Skill，它只会读取：

CODE
Skill 名称
Skill 描述

例如： 

CODE
---
name: pr-review
description: Reviews pull requests for code quality and coding standards.
---

这部分信息非常小，几乎不占上下文。

第二步：判断是否匹配 

当你输入：帮我Review一下这个PR 后，Claude 会发现这个请求和 pr-review 很像，于是认为这个 Skill 可能有用。

第三步：加载完整内容 

确认后，Claude 才会真正读取 Skill 里面的详细规则。

所以即使你拥有几十个 Skills ，也不会把上下文窗口塞爆，这也是 Skills 最大的设计亮点之一。

Skills、CLAUDE.md 和 Slash Commands 到底有什么区别？

这是新手最容易混淆的地方，我们直接看表。

功能
触发方式
适合场景
CLAUDE.md
每次自动加载
全局规则
Skills
自动匹配加载
特定任务
Slash Commands
手动调用
快捷操作

CLAUDE.md 像员工手册 

例如：

CODE
项目统一使用 TypeScript
禁止使用 Any 样式
全部采用 Tailwind

这是项目级规则，无论做什么事情都要遵守，所以放到 CLAUDE.md。

Slash Commands 像快捷键 

例如：

CODE
/review
/fix
/test

必须手动触发，不输入就不会执行。

Skills 像专家顾问 

只有需要的时候才出现。例如：

CODE
PR Review
技术文档
发布流程
品牌规范

平时不占资源，需要时自动出现，这是 Skills 最大的价值。

Personal Skill 和 Project Skill

Skills 有两种存放方式。

Personal Skill 

位置： 

CODE
~/.claude/skills

这是你的私人技能库，适用于：

CODE
Commit Message 风格
文档格式
个人工作习惯
常用分析模板

无论进入哪个项目都能使用。

Project Skill 

位置：

CODE
 .claude/skills

放在项目根目录。适用于：

CODE
团队规范
品牌规范
UI设计标准
项目开发流程

提交到 Git 后整个团队都能共享，这才是真正有价值的地方。

手把手创建第一个 Skill

我们做一个最简单的例子——PR 描述生成器。首先创建目录：

CODE
mkdir -p ~/.claude/skills/pr-description

然后创建：

CODE
SKILL.md

内容如下：

CODE
---
name: pr-description
description: Write pull request descriptions for code changes.
---
When writing a PR description:
1. Run git diff main...HEAD
2. Follow this format
## What
Describe what changed.
## Why
Explain why it changed.
## Changes
- List key modifications

保存后重启 Claude Code，然后直接说：帮我写PR描述。Claude 会自动匹配这个Skill，并按照你的模板生成。

这就是一个完整的自定义能力。

Skill 其实就是一个 Prompt 工程

很多人第一次看到 Skill，会觉得它很神秘。实际上拆开来看，Skill 本质上就是：

CODE
Frontmatter（元数据）
+
Instructions（执行说明）
+
References（参考资料）

你完全可以把它理解成一个拥有名字和触发条件的高级 Prompt。一个标准的 Skill 通常长这样：

CODE
---
name: pr-description
description: Write pull request descriptions for code changes.
---
# Instructions
当用户要求生成PR描述时：
1. 先分析 git diff
2. 总结改动内容
3. 按固定模板输出
## Output Format
### What
...
### Why
...
### Changes
...

前面的 Frontmatter 是给 Claude 看的，后面的 Instructions 才是真正执行的内容。

name：Skill 的身份证 

name: XXXXX 这个名字必须唯一。官方建议采用小写字母、数字和连字符（-）的形式来取名。

例如： 

CODE
frontend-review
backend-review
commit-message
design-spec-review

不要使用：

CODE
review
test
helper

这种名字太宽泛，后期 Skills 多了以后很容易冲突。

description：整个 Skill 最重要的部分 

如果说 Skill 什么最重要，那一定是 description。因为 Claude 并不是通过名字匹配 Skill，而是通过 description 来判断。例如：

CODE
description: Reviews pull requests for code quality.

当你说：帮我Review一下这个PR ，Claude 就会认为这个 Skill 可能有用，于是触发。所以 description 其实是在回答两个问题： 

这个 Skill 是干什么的？ 

    例如： Reviews pull requests. 

什么时候使用？ 

    例如： Use when reviewing pull requests, checking code changes, or performing code reviews. 

组合起来：

CODE
description: Reviews pull requests for code quality. Use when reviewing pull requests, checking code changes, or performing code reviews.

这样的触发率通常会高很多。

一个写description的经验是，把你平时说的话写进去。很多人写 Skill 最大的问题是写得太官方。例如：

CODE
description: Provides engineering assessment.

Claude 根本不知道什么时候该触发，不如直接写：

CODE
description: Review code quality, architecture and performance. Use when user asks to review code, review a PR or inspect code changes.

因为这就是你平时真正会说的话，Claude 的匹配效果反而更好。

Instructions 才是真正的核心价值 

很多新手会把重点放在 description，但真正具体体现Skills价值的是Instructions这部分。例如：

CODE
当执行代码Review时：
重点检查：
1. 性能问题
2. 安全问题
3. 可维护性问题
4. 架构一致性问题
输出格式：
## 风险等级 高 / 中 / 低
## 发现的问题 ...
## 建议 ...

这里其实就是把你的经验写进去。Skill 不是在教 Claude 做事，而是在教 Claude 按照你的方式做事。

好 Skill 的三个标准

我自己总结下来，一个优秀 Skill 基本符合三个原则。

1、一个 Skill 只解决一个问题 

推荐：

CODE
commit-message
pr-description
frontend-review
bug-analysis

不推荐： 

CODE
coding-assistant
super-reviewer
all-in-one-helper

越聚焦越好。 

2、描述一定要具体 

推荐： 

CODE
description: Write Conventional Commit messages. Use when creating commits or commit messages.

不推荐： 

CODE
description: Help with Git.

3、输出格式固定 

这是很多人忽略的点，如果希望结果稳定，不要说：

CODE
帮我分析一下

而要说： 

CODE
输出格式：
问题：
原因：
影响：
解决方案：

Claude 最擅长的不是创造格式，而是遵守格式。

一个 Skill 写坏的典型案例

很多人会这样写： 

CODE
---
name: code-review
description: Review code.
---

然后下面写：

CODE
帮我Review代码

结束。 

这种 Skill 基本没有价值，因为 Claude 本来就会 Review。Skill 应该提供的是：

CODE
你的经验
你的标准
你的模板
你的流程

而不是把用户问题重复一遍。

你可以把自己当成团队里最资深的同事，然后问自己，如果新人接手这项工作，我会给他哪些检查清单？

把这些内容写进去，这才是真正有价值的 Skill。

哪些东西最值得做成 Skill？

很多人学完以后最大的疑问是：我到底该写什么？有一个非常简单的判断标准：如果你已经向 Claude 解释过三次以上，那它就应该变成 Skill。例如：

Commit Message 

CODE
feat:
fix:
refactor:

代码 Review 

CODE
性能
安全
可维护性
架构一致性

技术方案评审 

CODE
优点
缺点
风险
落地成本

技术文档 

CODE
背景
目标
方案
风险
总结

等等。凡是你常用的可以结构化的，都可以。

如果你刚开始学习 Claude Code，不要急着研究高级配置，可以先试着写一些常用的Skills，也可以让AI直接帮你提意见。写好后，大概率就能帮你节省大量重复沟通时间。

因为 Skills 的本质并不是增强 Claude，而是在不断沉淀你自己的工作方法。当你的 Skills 越来越多时，你会发现一件很有意思的事情：最开始是你在教 Claude 工作，后来变成 Claude 在按照你的方式工作，再后来，你积累下来的已经不是一堆 Prompt，而是一套属于自己的数字化经验库。

这或许才是 Claude Code 最有价值的地方——它不仅在帮你完成任务，更在帮你把那些反复验证过的方法论，慢慢沉淀成可以复用、可以传承的能力。