Skill 是 Claude Code 最被低估的能力之一。它不是插件，不是 MCP，而是一套轻量级的"按需领域专家"机制------让 Claude 在特定任务上从通用助手摇身变成专业工作流。
一、Skill 是什么
一句话定义：Skill 是一段预定义的提示词（prompt），在特定条件下被加载到对话上下文中，让 Claude 临时获得某个领域的专业知识和工作流指导。
它和外挂系统（MCP、插件、API 集成）有本质区别：Skill 不增加新的工具，不连接外部系统，不改变 Claude 的能力边界。它改变的，是 Claude"怎么思考"和"怎么做事"。
打个比方：
- MCP 是给 Claude 装上了新的手和眼睛------能访问新的数据源、调用新的 API
- Skill 是给 Claude 换了大脑的思考框架------同样的工具，更好的决策
一个 Skill 的结构非常简单，本质上就是一个 markdown 文件：
markdown
---
name: my-skill-name
description: 一句话描述，用来判断什么时候触发这个 skill
---
# Skill 的实际内容
这里写详细的提示词，告诉 Claude 在面对某类任务时：
- 应该遵循什么流程
- 应该注意哪些陷阱
- 应该产出什么格式的结果
- ...就是这些。没有代码，没有配置，没有依赖。一个 markdown 文件就是一个 Skill。
二、Skill 的工作原理
触发机制
Skill 有两种触发方式：
1. 显式触发------用户主动调用
用户在对话中输入 /<skill-name>，Claude Code 立即加载对应 Skill 的完整提示词到当前对话中。
bash
/add-tests
/security-review
/khazix-writer 帮我把这段素材写成公众号文章这是最直接的方式，用户明确知道自己在调用哪个 Skill。
2. 隐式触发------Claude 自动匹配
每个 Skill 的 description 字段不仅是给人看的说明，更是给 Claude 用来做语义匹配 的。当用户的请求和某个 Skill 的描述高度相关时，Claude 会自动调用 Skill 工具加载它。
这就是为什么有时候你只是说了一句「帮我写篇文章」，Claude 就自动触发了 khazix-writer skill------因为它的 description 里写了触发条件。
加载机制
Skill 被触发后，它的完整内容（markdown 文件全文）会被注入到 Claude 的系统提示中。这意味着：
- Skill 的内容是 Claude 的"临时思考框架"，不是对话的一部分
- 它对用户不可见（除非用户去翻 Skill 文件），但对 Claude 接下来的所有决策生效
- Skill 的指导会覆盖 Claude 的默认行为------比如 Skill 说"不要写注释"，Claude 在这个任务中就不会写注释
生命周期
一个 Skill 的生效范围是当前对话回合 。每次被触发都是一次新的加载。Skill 之间不会互相干扰------如果你先调用了 clair-api skill 写了一段 API 代码，然后调用 security-review 审查它，两次调用各自独立加载各自的领域知识。
三、内置 Skill 一览
Claude Code 预置了一批官方 Skill，覆盖了常见的工作场景：
| Skill 名称 | 功能 | 典型使用场景 |
|---|---|---|
init |
为新仓库生成 CLAUDE.md 文档 | 刚 clone 一个项目，想让 Claude 理解代码结构 |
review |
审查 Pull Request | 收到同事的 PR，让 Claude 帮忙过一遍 |
security-review |
对当前分支做安全审查 | 上线前的安全检查 |
simplify |
审查代码的复用性、质量、效率 | 重构前让 Claude 扫一遍代码 |
update-config |
管理 settings.json 配置 | 设置权限、环境变量、hooks |
keybindings-help |
自定义键盘快捷键 | 修改提交快捷键、添加新的键位绑定 |
fewer-permission-prompts |
分析历史对话，生成权限白名单 | 某些命令每次都要点确认，想一劳永逸 |
loop |
按固定间隔重复执行某个任务 | 每 5 分钟检查一次部署状态 |
claude-api |
Claude API / Anthropic SDK 开发助手 | 写 API 集成代码、迁移模型版本、调优缓存 |
khazix-writer |
中文公众号长文写作 | 写文章、续写、按风格扩写 |
四、实战案例
案例 1：用 simplify 做重构前的代码审查
你在分支上写了一堆代码，准备提 PR，但不确定代码质量。调用 simplify：
bash
/simplifyClaude 会以"审查代码复用性、质量和效率"的视角扫一遍你的改动，告诉你可以提取哪些公共逻辑、哪里可以合并重复代码、哪个函数复杂度太高。
它不是直接帮你改，而是给你一个审查报告------像是一个有经验的同事 review 了一遍。
案例 2：用 fewer-permission-prompts 减少操作摩擦
你每天都在用 npm install 和 git status，但 Claude Code 每次都要你点确认。调用一次 fewer-permission-prompts：
bash
/fewer-permission-promptsClaude 会扫描你的历史对话记录，找出那些你反复批准的只读命令（如 git status、npm ls），生成一个权限白名单加到 settings.json 里。以后这些命令就不再弹确认框了。
案例 3：隐式触发------你甚至不需要知道 Skill 存在
这是一个用户体验上最精妙的设计。
你新 clone 了一个 Go 项目的仓库，对 Claude 说：「帮我看看这个项目的代码结构，告诉我怎么启动。」
Claude 可能会自动触发 init skill，因为它识别到"新项目、需要了解代码结构"这一场景和 init 的 description 匹配。然后 Claude 会自动使用 init 中定义的流程------先探索目录结构、检查关键配置文件、生成 CLAUDE.md------而不是随意地翻几个文件就给你一个模糊的结论。
隐式触发的意义在于：你不必知道有哪些 Skill，系统会自动选择最合适的那个。
五、Skill vs MCP vs Hook：三者的边界
这是最容易混淆的三个概念，用一张表说清楚：
| Skill | MCP Server | Hook | |
|---|---|---|---|
| 本质 | 一段提示词 | 一个外部服务 | 一段 shell 脚本 |
| 作用对象 | Claude 的思考方式 | Claude 的能力边界 | Claude Code 客户端本身 |
| 加载时机 | 用户调用 / 自动匹配 | 会话启动时连接 | 特定事件发生时 |
| 典型例子 | /review 审 PR |
Postgres MCP 让 Claude 直接查数据库 | before-tool-use 在 Claude 操作前留日志 |
| 文件位置 | .claude/skills/*.md |
settings.json 中的 mcpServers |
settings.json 中的 hooks |
| 代价 | 零------就是文本 | 需要启动和运行外部进程 | 每次事件触发一次 shell 调用 |
一句话区分：
- Skill 管的是「怎么想」
- MCP 管的是「能碰什么」
- Hook 管的是「什么时候做什么」
六、如何写一个自己的 Skill
最小可用的 Skill
在项目根目录下创建 .claude/skills/ 目录（如果还不存在），然后新建一个 markdown 文件。比如 .claude/skills/add-tests.md：
markdown
---
name: add-tests
description: 为新代码添加单元测试。当用户说"加测试"/"写测试"/"add tests"时触发。要求覆盖正常路径、边界情况和异常路径。
---
# 测试编写规范
你是一个测试专家。当用户要求为代码添加测试时，请遵循以下规范：
## 优先级
1. 先覆盖核心业务逻辑的测试
2. 再覆盖边界条件
3. 最后考虑异常路径
## 风格要求
- 使用 describe/it 结构组织测试
- 每个测试只验证一个行为
- 测试命名要描述被测行为，而不是方法名
- 不 mock 数据库，使用真实测试库
## 输出格式
- 先列出你要添加的测试清单，让用户确认
- 确认后再逐个文件修改写完保存后，你就可以：
- 显式调用：输入
/add-tests然后说「给 user.service.ts 加测试」 - 或者：直接说「帮我给这个模块写测试」，Claude 会自动匹配到这个 Skill
插件级 Skill
Skill 还支持通过插件分发。插件通过命名空间隔离，调用格式为 plugin-name:skill-name。如果你安装了一个名为 deploy-helper 的插件，它提供的 aws skill，你可以通过 /deploy-helper:aws 来调用。
这意味着一套标准化的 Skill 可以在团队中共享------一个整理了 CI/CD 流程的 Skill，团队里所有人都能复用它来排查线上问题。
七、Skill 设计的核心原则
从使用和观察中，我总结出几个写好 Skill 的关键点：
1. Description 是"匹配引擎"
Description 不光给人看，更是给 Claude 做语义路由的。要写清楚触发场景而不是抽象定义：
- 好：
当用户提到"部署"/"上线"/"deploy"/"release"时触发，指导发布流程 - 不好：
一个发布助手
2. 告诉 Claude "如何思考"，而不是"做什么"
Skill 的价值不是重复 Claude 已经知道的事情，而是给它一套在特定领域的思考框架 。比如 security-review 不是告诉 Claude "检查安全问题"，而是给它一份 OWASP Top 10 的 checklist 和每项的审查方法。
3. 保持精简
Skill 越短越容易被完整加载和执行。一个 Skill 如果有 3000 字，Claude 不一定能完整消化。控制在 500-800 字，让 Claude 能一次性完整理解。
4. 一个 Skill 只做一件事
不要写一个"前后端全栈助手" Skill。拆成"前端测试规范""后端 API 设计规范""数据库迁移规范"三个独立的 Skill，让 Claude 在正确的场景加载正确的那一个。
八、总结
Skill 是 Claude Code 里最轻量、最优雅的扩展机制。它不增加复杂度，不引入外部依赖，唯一需要的就是一段好的提示词。但正是这种简单性，让它成为了一个随时可用的"专家分身"。
如果把 Claude Code 的能力体系比作一个操作系统：
- MCP 是驱动程序------让系统看得见新的硬件
- Hook 是 cron 任务------到时间了就执行
- Skill 是用户配置------你告诉系统"这类事情你就这样处理"
而 Skill 的妙处在于：你不需要是运维、不需要会配置服务器、不需要写一行代码。你需要的，只是把你脑子里的经验写成一段文字，然后 Claude 就学会了你的工作方式。
这可能是 AI 工具中最接近"让机器理解你的思维方式"的能力。