每次让 Claude 审一个 PR,你是不是都得重新交代一遍:“按我们团队的规范来,先看安全问题,再看命名,反馈分级列出”?下次再审,又得说一遍。写 commit message 也一样——每次都得提醒它你要什么格式。
这种反复对同一个 AI 解释同一件事的感觉,就是一个 skill 在喊着要被写出来。
skill 就是把”这件事该怎么做”写一次,存成一个文件。以后只要这类任务出现,Claude 自己把这套做法翻出来用,不用你再开口。
这一篇讲清四件事:一个 skill 长什么样、AI 凭什么决定用它、它该放哪、以及它和你可能听过的 CLAUDE.md、斜杠命令有啥不一样。
一个 skill 长什么样
一个 skill 本质就是一个文件夹,里面有一个 SKILL.md 文件。文件分两部分:
---
name: pr-review
description: Reviews pull requests for code quality. Use when reviewing PRs or checking code changes.
---
(下面是正文:你的 review 清单、反馈格式偏好、
任何你希望 Claude 做这件事时知道的东西)- 上面
---包起来的叫 frontmatter(元数据),就是几对 键值对,关键的只有两个:name(名字)和description(描述)。 - 下面是正文,用大白话写清楚这件事该怎么做。
就这么简单。没有代码,没有配置语法,就是一篇 Markdown。你不会写代码,照样能写 skill。
description 是 AI 的”选择开关”
这是整个机制里最该懂的一点。
description 不是写给人看的注释——它是 AI 决定要不要用这个 skill 的唯一依据。
当你对 Claude 说”帮我审一下这个 PR”,它会拿你这句话,去和手上每一个 skill 的 description 逐个比对,谁的描述匹配上了,就激活谁。所以 description 里那句 Use when reviewing PRs... 不是废话,是触发条件。
写得含糊,该用的时候 AI 不用;写得精准(说清”什么时候用我”),AI 才能在对的时刻自动把它掏出来。
skill 放哪:跟人走,还是跟项目走
两个位置,区别是”谁能用到”:
| 放哪 | 路径 | 谁能用 |
|---|---|---|
| 个人 skill | ~/.claude/skills(Windows:C:/Users/<你的用户名>/.claude/skills) | 只有你,但跨所有项目跟着你走 |
| 项目 skill | 项目仓库根目录下的 .claude/skills | 任何 clone 这个仓库的人自动获得 |
判断很简单:
- 这是你个人的习惯(你爱用的 commit 格式、你喜欢代码怎么解释给你听)→ 放个人 skill。
- 这是团队/项目的规范(公司品牌色、字体、统一的 PR 流程)→ 放项目 skill,跟着代码一起提交到版本库,全队共享。
举个具体的例子
假设你的用户名是 shawn,你在写一个叫 auplus 的项目,项目放在 D 盘,路径是 D:/project/auplus。你想写一个 skill,它的完整路径取决于你想让谁用到它:
- 当个人 skill →
C:/Users/shawn/.claude/skills/my-skill/SKILL.md在你的家目录(C 盘)下。不管你今天在auplus、明天换别的项目,这个 skill 都跟着你走。 - 当项目 skill →
D:/project/auplus/.claude/skills/my-skill/SKILL.md就在项目自己的目录里(项目在 D 盘,它也在 D 盘)。只在auplus里生效,但谁 clone 了auplus谁就自动有它。
一眼看出区别:个人 skill 跟着”你”——永远在家目录(C 盘);项目 skill 跟着”项目”——项目在哪个盘,它就在哪个盘(这里是 D 盘)。 每个 skill 自己还是一个文件夹(my-skill/),SKILL.md 装在里面。
那 D:/project/auplus/.claude/ 这个文件夹是什么时候冒出来的? 它不是 clone 下来就自带的,也不是你一打开项目就自动生成的。它是第一次有人往里放项目级配置时才被创建的——比如你手动建了 .claude/skills/ 文件夹,或者你在这个项目里让 Claude 写入了项目设置。一旦它存在,就跟着 git 一起提交进版本库,别人 clone 才会拿到里面的 skill。
⚠️ 正因为项目 skill 会跟着 git 提交,这里有个新手最容易踩的雷:别在
SKILL.md或脚本里写死密钥、token、私有路径。 它们会原封不动进版本库——你一旦推到公开仓库,等于把密钥公开挂出去了。需要用到敏感信息时走环境变量,别硬编码进 skill。这也是为什么:没完全搞懂之前,先别急着分享你的 skill。
skill vs CLAUDE.md vs 斜杠命令:差在”什么时候上场”
Claude 这个跑在终端里的命令行(CLI)工具,有好几种”教它做事”的方式,容易混。核心区别就一句话——谁决定它上场、什么时候上场:
| 方式 | 什么时候生效 | 代价 |
|---|---|---|
| CLAUDE.md | 每次对话都加载,永远在场 | 一直占着 context;只适合放”永远成立”的规则 |
| 斜杠命令 | 你手动敲 /xxx 才触发 | 你得记得它、主动调用 |
| skill | AI 认出场景自动加载,平时不占地方 | 几乎没有——这正是它的优势 |
举个对比:
- “永远用 TypeScript 严格模式”——这种无条件的规则,放 CLAUDE.md。
- 你的 PR review 清单——你 debug 的时候根本用不上它,没必要一直占着 context。做成 skill,等你真要 review 时它才加载进来。
这就是 skill 的精髓:按需加载。平时 AI 只知道它的名字和描述(很轻),要用的那一刻才把完整内容调进来。
什么时候该写一个 skill
一条经验法则就够了:
如果你发现自己在对 Claude 反复解释同一件事,那就是一个 skill 在等着被写出来。
典型场景:
- 团队的 code review 标准
- 你偏好的 commit message 格式
- 公司的品牌规范(色值、字体、语气)
- 某类文档的固定模板
- 某个框架的调试清单
给 vibe-coder 的话
你不需要会写代码才能写 skill——它就是一篇说明书,用大白话把”这件事我希望你怎么做”讲清楚就行。
真正的心智转变是:别再把每次对话当成一次性的。当你第二次、第三次对 AI 解释同一套要求时,停下来——把它写进一个 SKILL.md。你不是在”配置工具”,你是在把自己的判断力沉淀下来,让 AI 每次都按你的标准来,而不是每次都从零开始猜。
下一篇钻进引擎盖里看:AI 启动时到底读了 skill 的什么、凭什么匹配、命名撞了谁赢。