上一篇我们讲了 Command------把自己的重复操作封装成一键命令。
Command 解决的是「你的流程」。
但还有另一个问题：你可能不知道这件事该怎么做。
先说一件让我有点尴尬的事
有一次，一个项目着急上线，我让 Claude Code 帮我做了一遍安全 review。
它给出的结论是：「代码整体符合安全规范，未发现明显漏洞。」
我觉得挺好，就这样上线了。
后来装了一个专门做安全审查的 Skill，同样的代码跑了一遍。
它找出来 3 个问题：一处 JWT 没有校验 expiration，一处接口缺少频率限制，一处敏感字段在日志里被打印出来了。
都是我平时不太关注、但真的会出事的点。
我后来才想明白：问题根本不在 AI。
我说的是「帮我做安全 review」。但我自己不懂安全审查的标准框架。AI 拿到这个 Prompt，只能按「通用理解」走。
那个 Skill 不一样。它是真正做过安全工程的人写的，把自己的检查清单和判断框架全部写进去了。
你的水平决定了你的 Prompt 上限。
装一个 Skill，就是装上了别人的经验上限。
什么是 Skill
说白了，Skill 是一个打包好的 Prompt 工作流，通常放在一个叫 SKILL.md 的文件里。
和 Command 一样，也是 Markdown 文件。但它不只是「一段 Prompt」，而是一套完整的工作流描述------触发条件、执行步骤、质量标准、异常处理，全都写进去了。
更关键的是：Skill 可以被社区分发和安装。
别人打磨好的工作流，你装上，直接用。
你可以把它理解成给 AI 员工的专业技能包。
Rule 告诉 AI 规矩，Command 告诉 AI 你的操作流程，Skill 让 AI 具备一项专业能力------哪怕那个领域你自己也不是专家。
Skill 和 Command 有什么区别
这是被问最多的问题。
Command 是你定义的快捷操作。
你有什么重复的操作流程，写进 .md 文件，/命令名 触发。问题是，你能写出来的，受限于你自己的认知。
Skill 是社区打磨过的专业工作流。
结构更完整，带有触发条件、操作步骤、质量标准。可以被打包、分发、安装，也可以持续迭代更新。
| Command | Skill | |
|---|---|---|
| 定位 | 你的个人 / 团队操作流程 | 社区可共享的专业工作流 |
| 触发方式 | /命令名 |
命令触发，或自动识别场景 |
| 内容质量 | 取决于你自己怎么写 | 经过社区打磨和验证 |
| 分发方式 | 通常只在本地 / 项目内 | 可发布到社区，供他人安装 |
| 适合场景 | 你已经熟悉、只想省事的事 | 你不熟悉、想借助他人经验的事 |
简单说：Command 是你的快捷操作，Skill 是别人帮你做好的工具。
当然，你也可以自己做 Skill，发布出去让别人用。
4 个需要用 Skill 的场景
① 你不知道这件事该怎么问 AI
生成单元测试、安全审查、性能优化、可访问性检查......
这些事，懂的人一口气能说出十几条标准，不懂的人写出来的 Prompt 就是「帮我做 XX」。
社区里有人已经把这些门道整理进 Skill 了。
你不需要先成为专家，再来写 Prompt。装上，直接继承。
② AI 需要在你不擅长的领域比你更专业
这是 Skill 最有价值的场景。
你是前端开发，让你写安全审查 Prompt，写出来的框架一定是残缺的。但一个真正做过渗透测试的工程师，会把 OWASP Top 10、JWT 校验、日志脱敏......这些检查项全都写进去。
装上这个 Skill，AI 审查代码的标准，就超过了你自己的认知范围。
你还是你，但 AI 帮你补上了那个短板。
③ 工作流需要多步骤、有结构
有些任务，一个 Prompt 搞不定。
比如「从 Figma 设计稿生成 Vue 组件」，正确的做法是：读取设计稿 → 识别组件结构 → 对照项目规范 → 生成代码 → 列出与设计稿的差异点。
每一步都有对应的逻辑，Skill 里面都可以写清楚。比你临时攒一段 Prompt 可靠得多。
④ 团队需要统一某个工作标准
团队里每个人写的 Prompt 质量不一样，同一件事的处理方式也不一样。
用 Skill 而不是 Command，好处是：Skill 有标准的包格式，可以被安装，可以被更新。
大家装同一个 Skill，工作方式就自然统一了。而且 Skill 更新了，所有人同步升级，不用逐个交代。
怎么安装一个 Skill
方式一：直接复制文件
最基础。
把 Skill 文件下载下来，放到对应目录：
个人全局 ：~/.claude/skills/技能名/SKILL.md
放这里的 Skill，你电脑上所有项目都能用。
项目级 ：.claude/skills/技能名/SKILL.md
只在当前项目生效，可以提交到 git，团队共享。
放好，Claude Code 自动读取，Skill 生效。
方式二：命令行工具安装
skills.sh 提供了统一的 CLI，一行命令搞定：
bash
npx skills add https://github.com/vercel-labs/skills --skill find-skills把链接换成你想装的 Skill 所在的仓库，--skill 后面跟技能名，就能直接拉到本地。
方式三：在对话里直接搜索安装
安装 find-skills 之后，Claude Code 执行 /find-skills 命令：
arduino
/find-skills security reviewAI 列出相关 Skill，你选一个，它帮你装上。不用离开对话，直接完成。
怎么使用一个 Skill
安装好之后，怎么触发取决于 Skill 自己的设计。
命令触发（最常见）：
bash
/security-review
/unit-test-generator
/vue-best-practices输入命令，AI 按照 Skill 里的工作流走完整个流程。
带参数触发：
有些 Skill 支持传入参数：
bash
/security-review src/api/auth.ts
/implement-design https://www.figma.com/design/xxxx自动识别场景触发：
有些 Skill 不需要手动触发。它描述了「当遇到 XX 情况时，按照这套流程处理」。AI 识别到对应的场景，自动应用。
比如一个「代码提交前检查」Skill，你每次执行 git commit 相关操作时，它自动介入。
怎么自己创建一个 Skill
会用了，进阶一步：做自己的 Skill。
什么时候该做 Skill？两种情况。
一是你的 Command 质量已经不错，想开放给社区。二是你在某个领域有积累，想把这套经验固化下来，让 AI 持续按你的标准干活。
第一步：写好 SKILL.md
每个 Skill 必须有一个 SKILL.md 文件，分两部分：
- YAML frontmatter （
---之间）：告诉 Claude 这个 Skill 叫什么、什么时候用 - Markdown 正文：Claude 调用 Skill 时遵循的说明
name 字段变成 /命令名，description 帮助 Claude 决定什么时候自动加载。
markdown
---
name: gen-tests
description: 为目标文件生成完整的单元测试。当用户说「写测试」「生成测试用例」，或某文件缺少测试时触发。
---
为 $ARGUMENTS 生成完整的单元测试。
1. 分析目标文件的导出函数和类
2. 识别项目的测试框架（jest / vitest / pytest）
3. 对每个函数生成测试用例：
- 正常输入 → 期望输出
- 边界值（空值、极值、特殊字符）
- 异常情况（抛出错误、网络失败）
4. Mock 所有外部依赖
5. 测试名称使用中文，格式：「当 XX 时，应该 XX」
6. 生成后立即运行，失败则修复后再报告
**质量标准**：
- 核心函数覆盖率 80%+
- 每个测试只验证一件事
- 不写「永远不会失败」的测试
**注意事项**：
- 找不到测试框架配置时，先问用户，不要猜
- 不要测试第三方库的行为，只测自己写的逻辑
- 生成后必须运行，不能只生成不验证放到 .claude/skills/gen-tests/SKILL.md，就能用了。
传参数：$ARGUMENTS
上面的例子里有个 $ARGUMENTS，这是 Skill 的参数占位符。
你调用 /gen-tests src/utils/auth.ts 时，$ARGUMENTS 就自动替换成 src/utils/auth.ts，Claude 拿到的是实际的文件路径。
不只是文件路径，任何内容都可以传进去：
bash
/gen-tests src/api/user.ts 只测 createUser 这个函数如果 Skill 里没有写 $ARGUMENTS，你传的内容会自动追加到 Skill 末尾，Claude 还是能看到。
注入动态上下文：!命令
这个用法更实用。在 Skill 里用 !bash 命令 的语法，Skill 执行前会先跑这段 Shell，把输出注入进来。
比如一个 commit Skill，让它自动把当前 diff 读进来：
markdown
---
name: commit
description: 根据当前代码变更生成规范的 commit message
disable-model-invocation: true
---
根据以下代码变更，生成符合约定式提交规范的 commit message：
!`git diff --cached`
要求：
- 类型：feat / fix / refactor / docs / chore
- 描述用中文，不超过 50 个字
- 直接给结果，不要多余解释执行 /commit 时，Claude 拿到的不是 !git diff --cached 这串字符，而是真实的 diff 内容。不用你手动复制粘贴，Skill 自己去取。
这是预处理，在 Claude 看到任何东西之前就执行了。
渐进式披露：让 Skill 只在需要时加载
这是 Skill 设计里一个值得了解的思路。
一个复杂的 Skill，不是把所有内容都堆进 SKILL.md。而是 SKILL.md 只写要点和入口，把大型参考文档、API 说明、使用示例放到单独的文件里。Claude 只在真正需要时才去加载这些文件，不会每次都占满上下文。
目录结构长这样：
perl
my-skill/
├── SKILL.md # 入口（必需），写要点和导航
├── reference.md # 详细 API 文档（按需加载）
├── examples.md # 使用示例（按需加载）
└── scripts/
└── helper.py # 辅助脚本（执行，不加载）在 SKILL.md 里告诉 Claude 这些文件是什么、什么时候去看：
markdown
## 参考资料
- 完整 API 说明：见 [reference.md](reference.md)
- 使用示例：见 [examples.md](examples.md)这样 SKILL.md 保持简洁，Claude 处理简单任务时不会被一堆文档撑满上下文。遇到复杂情况才去翻对应的文件。
官方建议：SKILL.md 控制在 500 行以内，超出的内容往支持文件里放。
注意事项
Skill 不是越多越好。
装了一堆 Skill，AI 上下文里全是工作流描述。可能互相干扰，也可能在「该用哪个」上卡住。按需安装，用不上的不装。
装之前先看质量。
社区 Skill 和 npm 包一样，质量参差不齐。装之前先看：安装量高不高？SKILL.md 写得清不清楚？触发条件合不合理？触发条件太宽泛的，会在你不想用的时候自动跳出来，挺烦的。
个人 Skill 和项目 Skill 分清楚。
个人习惯型 Skill 放 ~/.claude/skills/，团队共用 Skill 放 .claude/skills/ 并提交到 git。别把个人偏好强加给团队，也别让团队 Skill 只存在自己电脑上。
Skill 在 Rule 的基础上工作。
Rule 里定了「统一使用 Composition API」，单元测试 Skill 生成的辅助函数，自然会跟着这个规范走。你不用在每个 Skill 里重复写规范，Rule 已经覆盖了。两者配合，效果才最好。
去哪找好的 Skill
Agent Skills 的开放标准平台，也是前面说的 npx skills add 命令背后的数据来源。社区贡献者活跃，可以按分类浏览、搜索，也可以发布自己的 Skill。
目前收录了 63,000+ 个免费 Skill，覆盖 Claude Code、Codex、Cursor 等多个工具。按分类浏览、即搜即用，是找现成 Skill 最快的地方之一。
Agent Skills 市场，专注 Skill 的发现和分发。界面干净，分类清晰，适合按场景找 Skill。
awesome-claude-code
26,000+ Stars 的 Claude Code 资源大合集，里面有专门的 Agent Skills 分类，社区持续维护，收录的质量相对有保证。
你自己的历史 Command
这是最容易忽视的来源。
你已经写好、用了一段时间、质量还不错的 Command，可能就是一个很好的 Skill 雏形。加上 YAML frontmatter 和质量标准，打包成完整的 SKILL.md，发布出去。
你的「个人积累」，可能就是别人需要的「专业能力」。
最后
Rule 让 AI 知道规矩。Command 让 AI 知道你的流程。
Skill 做的是另一件事：让 AI 在你能力边界之外，还能继续工作。
安全审查、自动测试、性能优化......这些你还没搞透的领域，有人已经把专业判断力写进了 Skill。
你装上，AI 继承。就这样。
你的上限，不再是你的 Prompt 上限。
下一篇我们讲 Hook：AI 每次操作前后的自动检查站，怎么配置，配好了能省多少心。
欢迎感兴趣的朋友继续保持关注~
应部分读者呼声，作者组建了 AI 编程交流群，感兴趣的朋友请扫码加入，一起交流学习～
如果二维码过期，请添加作者微信并备注"AI编程交流群"，作者会拉你进群。
