Claude Code Skills 深度玩法：99% 的人不知道的高级用法

发表于 更新于 分类于 阅读次数： 本文字数： 6k 阅读时长 ≈ 5 分钟

cover

大多数人用 Claude Code 的 Skills，停留在这个阶段：知道有 /commit、/simplify、/review 这些内置命令，偶尔用一用，觉得”还行”。

但 Skills 系统真正的威力，远不止几个斜杠命令。

Claude Code 的 Skills 本质上是一套可编程的行为模块系统。你可以定义 AI 在什么场景下用什么工具、以什么方式工作、调用哪个模型、要不要隔离上下文——甚至可以让一个 Skill 自动创建子代理去并行执行任务。

截至 2026 年 3 月，社区已经贡献了超过 1,234 个 Skills，Claude Code 的 GitHub Stars 突破了 87K。但真正深入玩过 Skills 高级特性的人，我敢说不超过 1%。

今天这篇文章，带你把 Skills 从”会用”升级到”玩透”。

先搞清楚 Skills 到底是什么

很多人把 Skills 理解成”Prompt 模板”。这个理解不能说错，但太浅了。

Skills 的核心是一个叫 SKILL.md 的 Markdown 文件。它放在 .claude/skills/ 目录下，Claude Code 在启动时会自动扫描这个目录。

一个最简单的 Skill 长这样：

1
2
3
4
5
6
7
8
9
10
11
12
---
description: 生成符合团队规范的 commit message
user-invocable: true
---

# Commit Skill

分析当前 git diff，生成一条符合 Conventional Commits 规范的提交信息。
规则：
- feat/fix/refactor/chore 前缀
- 中英双语描述
- 关联 Issue 编号

保存到 .claude/skills/commit/SKILL.md，然后在 Claude Code 里输入这个 Skill 的触发词，它就会按照你定义的规则生成 commit message。

到这里为止，90% 的教程就结束了。但真正有意思的，是 Frontmatter 里那些大多数人从没碰过的字段。

高级玩法一：context: fork —— 上下文隔离

这是我认为 Skills 系统最被低估的特性。

默认情况下，Skill 运行在你当前的对话上下文中。这意味着它能看到你之前的所有对话历史，也会把它的输出加入到你的上下文里。

问题来了：如果你跑一个大型的代码审查 Skill，它可能会读几十个文件、生成大量分析内容。这些内容会撑爆你的上下文窗口。

context: fork 解决了这个问题。

1
2
3
4
5
---
description: 深度代码审查，扫描安全漏洞和性能问题
context: fork
user-invocable: true
---

加上 context: fork 后，这个 Skill 会在一个独立的上下文分支中运行。它能看到你当前的对话历史（作为只读快照），但它产生的所有中间过程不会污染你的主对话。

执行完毕后，只有最终结果会被返回到你的主对话中。

什么时候用它？

  • 代码审查类 Skill（会读大量文件）
  • 代码生成类 Skill（会产生大量中间 Token）
  • 搜索分析类 Skill（需要多轮搜索和整理）

一个实际的例子：我有一个 security-audit Skill，它会扫描整个项目的依赖树、检查 OWASP Top 10、分析 API 端点的权限配置。跑一次大概消耗 5-8 万 Token。

不加 context: fork，跑完之后我的主对话基本就废了——上下文被安全报告塞满，后续的编码任务质量直线下降。

加了 context: fork，我只在主对话里拿到一份精简的审查报告，上下文干干净净。

高级玩法二：allowed-tools —— 精确控制 AI 的能力边界

这个字段决定了 Skill 运行时，Claude Code 可以使用哪些工具。

1
2
3
4
5
6
7
8
9
10
---
description: 只读分析代码架构，不修改任何文件
allowed-tools:
  - Read
  - Glob
  - Grep
  - Bash(git log:*)
  - Bash(git diff:*)
user-invocable: true
---

上面这个 Skill，Claude 只能读文件、搜索文件、查 Git 历史。不能写文件、不能编辑文件、不能执行任意 Shell 命令。

这听起来像是在”限制” AI，但实际上是在保护你的代码库。

想想这个场景：你让一个 Skill 分析代码质量。如果不限制工具，Claude 可能”顺手”帮你重构了几个文件——你可能并不想要这些改动。

allowed-tools 的语法支持通配符：

  • Bash(npm test:*) —— 只允许运行 npm test 相关命令
  • Bash(git:*) —— 只允许运行 git 命令
  • Read —— 允许读取文件
  • Edit —— 允许编辑文件
  • Write —— 允许创建新文件

安全原则：Skill 只给它完成任务所需的最小权限。 分析类 Skill 不需要写权限，生成类 Skill 不需要执行命令的权限。

这不是过度设计。当你的 Skill 被团队共享、在 CI/CD 中自动执行时，权限控制就是安全的最后一道防线。

高级玩法三：agent 和 model —— 子代理编排

这是 Skills 系统最强大的特性，也是最少人知道的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
---
description: 并行审查多个模块的代码质量
agent: true
model: sonnet
context: fork
allowed-tools:
  - Read
  - Glob
  - Grep
user-invocable: true
---

# Multi-Module Review

对以下模块分别启动独立审查：
1. API 层 (src/api/)
2. 数据层 (src/models/)
3. 业务逻辑层 (src/services/)

每个模块的审查要点：
- 错误处理是否完整
- 命名是否符合规范
- 是否有重复代码
- 是否有明显的性能问题

最后汇总为一份统一报告。

当 agent: true 时，这个 Skill 会作为一个子代理运行。它有自己独立的执行环境，可以自主决定如何完成任务。

配合 model: sonnet，你可以指定子代理使用的模型。对于不需要最强推理能力的任务（比如格式检查、简单搜索），用 Sonnet 比 Opus 便宜得多，速度也更快。

子代理编排的核心价值是什么？

一个主 Skill 可以启动多个子代理，每个子代理负责一个独立的子任务。它们并行执行，互不干扰，最后结果汇总。

这就像你是一个技术总监，同时给三个工程师分配了三个审查任务。他们各干各的，你最后看汇总报告。

LangChain 团队在他们的技术博客中分享了一个发现：一个项目中 12 个 Skills 是最优的配置数量，过多的 Skills 会导致触发准确率下降。他们的实际触发率稳定在 70% 左右。

高级玩法四：disable-model-invocation —— 纯工具 Skill

这个字段可能是最反直觉的一个。

1
2
3
4
5
6
7
8
9
---
description: 运行项目标准测试套件
disable-model-invocation: true
user-invocable: true
allowed-tools:
  - Bash(npm test:*)
---

运行 `npm test` 并返回结果。

disable-model-invocation: true 意味着这个 Skill 不会调用 AI 模型。它只执行预定义的工具操作。

等一下，不调用 AI 的 Skill 还有什么用？

用处大了。

  • 跑测试：不需要 AI 分析，直接执行命令返回结果
  • 格式化代码：跑 Prettier/ESLint，不需要 AI 参与
  • 生成文档：用 TypeDoc/JSDoc 生成，纯工具操作
  • 部署命令：执行预定义的部署脚本

这类 Skill 的好处是：零 Token 消耗，执行速度极快，结果完全确定。

把这些纯工具操作封装成 Skill，不是因为 AI 做不到，而是因为不需要 AI 做。它们就是快捷命令，但比 shell alias 更强大——因为它们可以和其他 AI Skill 组合使用。

高级玩法五：三层渐进式加载

Claude Code 的 Skills 不是一次性全部加载的。它有一个三层渐进式加载机制，这对性能影响巨大。

第一层：Description 层

Claude Code 启动时，只加载每个 Skill 的 description 字段。这几个字就是 AI 判断”要不要激活这个 Skill”的全部依据。

1
2
3
---
description: 分析 PR 的代码改动并生成结构化审查报告
---

第二层：Frontmatter 层

当 AI 决定激活某个 Skill 时，才会读取完整的 Frontmatter——allowed-tools、context、agent、model 这些配置项。

第三层：内容层

最后才加载 SKILL.md 的正文——详细的指令、规则、示例。

这个设计为什么重要？

因为上下文窗口是有限的。如果你有 50 个 Skills，每个 Skill 的正文有 2000 个 Token，一次性全部加载就要吃掉 10 万 Token。

渐进式加载意味着，在任何一个时刻，上下文里只有当前需要的 Skill 内容。

这也解释了为什么 description 写得好不好如此关键——它是 AI 决定是否激活 Skill 的唯一依据。写得太模糊，该触发时不触发；写得太宽泛，不该触发时乱触发。

高级玩法六：用 Skill Creator 测试和优化

2026 年 3 月，Claude Code 更新了 Skill Creator 的 Eval 功能。这是一个被大多数人忽略但极其有用的特性。

Skill Creator Eval 可以：

  1. A/B 测试 Description：给同一个 Skill 写两个不同的 description，测试哪个触发率更高
  2. 基准测试：在一组预定义的场景下测试 Skill 的表现，生成成功率报告
  3. 方差分析：多次运行同一个 Skill，看结果是否稳定

一个实际的优化案例。

原始 description：

1
帮助处理代码相关的任务

触发率：23%。太模糊了，AI 不知道什么时候该用它。

优化后的 description：

1
分析 TypeScript 项目中的类型错误，提供修复建议和重构方案

触发率：78%。明确了语言、问题类型和输出形式。

优化 description 的方法论是：60/40 分割法。把你的测试场景分成 60% 训练集和 40% 测试集。用训练集优化 description，用测试集验证效果。

实战：我的 Skills 工具箱

分享几个我日常使用的 Skill 配置，你可以直接拿去用。

1. 代码清扫 Skill

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
---
description: 检查最近改动的代码，找出可复用的逻辑、违反规范的写法和性能问题
context: fork
agent: true
model: sonnet
allowed-tools:
  - Read
  - Glob
  - Grep
  - Bash(git diff:*)
user-invocable: true
---

# Code Sweep

1. 用 `git diff --name-only HEAD~1` 获取最近改动的文件列表
2. 逐个读取这些文件
3. 检查以下问题：
   - 是否有重复逻辑可以提取为公共方法
   - 是否违反了 CLAUDE.md 中定义的编码规范
   - 是否有明显的 N+1 查询或不必要的循环
4. 输出一份简洁的问题清单，按严重程度排序

2. PR 描述生成 Skill

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
---
description: 根据当前分支的 diff 自动生成结构化的 PR 描述
allowed-tools:
  - Bash(git:*)
  - Read
user-invocable: true
---

# PR Description Generator

1. 运行 `git log main..HEAD --oneline` 查看所有提交
2. 运行 `git diff main...HEAD --stat` 查看改动概览
3. 读取关键改动文件的内容
4. 生成 PR 描述，格式：

## Summary
[2-3 句话概述]

## Changes
[按模块列出主要改动]

## Testing
[描述测试覆盖情况]

## Breaking Changes
[如有，列出不兼容变更]

3. 依赖分析 Skill

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
---
description: 分析项目依赖的安全性和更新状态
context: fork
disable-model-invocation: false
allowed-tools:
  - Bash(npm:*)
  - Bash(npx:*)
  - Read
user-invocable: true
---

# Dependency Audit

1. 运行 `npm audit` 检查已知漏洞
2. 运行 `npx npm-check-updates` 检查可更新的依赖
3. 读取 package.json 分析依赖结构
4. 输出报告：
   - 高危漏洞列表及修复建议
   - 建议更新的依赖及变更说明
   - 可以安全移除的未使用依赖

Skills 的组织方式

当你的 Skills 越来越多，组织方式就变得重要了。

推荐的目录结构：

1
2
3
4
5
6
7
8
9
10
11
.claude/skills/
├── code-quality/
│   └── SKILL.md        # 代码质量检查
├── git-workflow/
│   └── SKILL.md        # Git 工作流相关
├── testing/
│   └── SKILL.md        # 测试相关
├── docs/
│   └── SKILL.md        # 文档生成
└── deploy/
    └── SKILL.md        # 部署相关

每个 Skill 一个目录，目录名就是 Skill 的标识符。Skill 目录里除了 SKILL.md，还可以放模板文件、示例代码等资源——Skill 执行时可以读取同目录下的文件作为参考。

团队共享的 Skills 放在项目仓库里。 这样每个团队成员 clone 项目后，自动就有了一套统一的 Skills。

个人的 Skills 放在 ~/.claude/skills/ 下。 这些是你自己的”瑞士军刀”，跟着你走，不绑定任何项目。

写在最后

Skills 系统是 Claude Code 最被低估的特性。大多数人只用了内置的几个命令，就像买了一台游戏主机只用来看视频。

真正的玩法是：把你的开发经验编码成 Skills。

你踩过的坑、总结过的规范、重复做过的检查——每一个都可以变成一个 Skill。下次遇到同样的场景，不是你去想”我该怎么做”，而是 AI 按照你定义的最佳实践自动执行。

这就像是你雇了一个永远不会忘记你教的东西的初级工程师。你教它一次，它记一辈子。

Boris Cherny 说过：”Skills 不是 Prompt 模板。它是你把自己的工程智慧外化成可执行代码的方式。”

从今天开始，每次你发现自己在 Claude Code 里重复输入类似的指令，就问自己一个问题：这能不能变成一个 Skill？

答案几乎总是：能。

你有自己常用的 Claude Code Skill 吗？或者有什么场景你觉得特别适合做成 Skill 但不知道怎么实现？欢迎在评论区交流，我们一起打造最好用的 Skills 工具箱。