Claude Code 实战入门(十):Skills,以及四种扩展机制各自该用在哪儿

Claude Code 现在有四种扩展机制:斜杠命令、MCP server、Hooks、Skills。Skill 是最新的——一个文件夹、一份 SKILL.md、一段按需加载的指令。它和其他三个怎么分工,给一棵决策树。

Claude Code 现在有四种扩展机制:斜杠命令、MCP server、Hooks、Skills。它们有重叠。第一次冒出"Claude 应该会做 X"这个念头时,问题就是用四种里的哪一种

这是系列的最后一篇。把决策树铺开。

Skill 到底是什么

Skill 是 ~/.claude/skills/<name>/(用户级)或 <repo>/.claude/skills/<name>/(项目级)下的一个文件夹,至少包含一份 SKILL.md

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
---
name: chenk-blog-write
description: 在 chenk.top 写新内容时使用——双语 EN/ZH 文章、系列、教程改编。涵盖 front matter、语气、matplotlib 图、封面生成、部署。
---

# 语气
- 第一人称,干、克制。不要 "let's",不要感叹号。
- 一句论断配一个例子。论断没例子,就把论断删掉。

# Front matter
[此处放精确 schema]

# 流程
1. 读源材料
2. 写 EN
3. 改写 ZH(不是翻译)
4. 生成封面
5. 构建+部署

会话开始时 Claude 会读所有可用 skill 的 description。当你的请求匹配上时,Claude 把 skill 主体加载进来——主体就成了那一轮 system prompt 的一部分。

两件事跟着来:

  • description 是承重的。它不说什么时候用,skill 就不会被用。
  • 主体可以很长。它按需加载,没触发就不算进 token。

和其他三种的差别

机制文件位置何时加载适合什么
斜杠命令<repo>/.claude/commands/<name>.md用户敲 /<name>1-2 行就能描述清楚的重复工作流
MCP servermcp.json 配置始终可用触达文件系统之外(浏览器、DB、第三方 API)
Hooksettings.json 引用的脚本围绕工具调用前后策略强制、编辑/写入时的副作用
Skill.claude/skills/<name>/SKILL.mddescription 匹配上 prompt领域知识、语气、多步规程

最清晰的分界线:斜杠命令是命令,Skill 是知识。 斜杠命令是"做这件具体的事"。Skill 是"我对这一类问题的思考方式都在这儿,凡是涉及到就用上"。

什么时候用哪一个

按顺序问:

1. 任务需要一个目前不存在的工具吗?(浏览器自动化、查真实数据库、调内部 API。) → 写 MCP server。其他三种都不能授予新能力。

2. 是不是希望某件事在工具调用前后自动发生——拦、校验、记日志、格式化? → 写 Hook。这是唯一一个不需要模型决定调用就会跑的机制。

3. 是不是一段紧凑的、用户会显式调用的过程?/commit/deploy-staging/make-changelog) → 写 斜杠命令。命令就是用名字喊起来的东西。

4. 是不是一组领域知识——一种语气、一套流程、一组约定——希望话题一出现就生效? → 写 Skill。Skill 是给那些你希望 Claude 认出来并主动应用、而不需要你点名的事。

如果一件事看起来同时落两格,挑更简单的那个。Skill 内部调用斜杠命令没问题;斜杠命令假装自己是 Skill 就脆。

我自己写过的三个 Skill

1. chenk-blog-write — 给本站写文章用。涵盖 front matter、语气、EN/ZH 对齐、封面生成、部署。任何提及 chenk.top 或者"写一篇"的请求都会触发。主体大约 600 行,每一行都值。

2. update-config — 改 ~/.claude/settings.json 用。“放过 X 命令”、“设环境变量 Y”、“加个 hook” 会触发。把上面的权限优先级规则和典型套路编码进去。省得每次重新推合并顺序。

3. simplify — 给我自己改动做代码 review 用。“是否有更简单的写法"会触发。把我的取舍编码进去:偏好组合、清掉死代码、按它是什么而不是按它怎么做出来命名。

这三个用斜杠命令都不行。它们不是按名字调用的,是按话题调用的。这就是 skill 形状的用例。

什么时候 Skill 是错答案

一个触发太频繁的 Skill 比没有 Skill 更糟——它会污染那些不需要它的任务的上下文。三个坑:

  • description 太泛。 “用于一般编程。” 啥都用 = 啥都没用。
  • Skill 主体重叠。 两个都在"写代码"上触发 → 上下文膨胀。挑一个。
  • 本该是 Hook 的东西硬写成 Skill。 “做 Y 之前必须做 X” → 这是 Hook,不是 Skill。Skill 是建议,Hook 是强制。

系列的尾声

走完十篇,你手里有:

  • 一个配置好的 Claude Code,三层 settings 模型在脑子里(第 1、9 篇)。
  • 快捷键、模式、对话控制都顺手了(第 2 篇)。
  • 四种扩展机制——斜杠命令、MCP、Hooks、Skills——以及一棵选哪个的决策树(第 3、4、5、7、10 篇)。
  • 并发原语——子 Agent、worktree、计划模式——把一个 session 撑大去扛更大活的能力(第 8 篇)。
  • 一套能跑的 SDK + GitHub 集成方案,把 Claude 放进 CI(第 6 篇)。

这就是表面积。再往下,真正有意思的活已经不再是 Claude Code 自身——是你拿它做出来的东西。去做吧。

翻完了?

去 GitHub 关注一下,新一篇通常隔一周就到。

GitHub