Claude Code Skill 完全指南：用 Markdown 文件创建专属 AI 专家

你可能已经习惯了让 AI 帮你写代码、查文档、解释报错。但你是否遇到过这种情况：每次让 AI 做同一类任务，都要把相同的规范重新说一遍？“记得用这个框架”、“别写那种注释”、“输出格式按上次那个来”。

Claude Code 的 Skill 机制，就是为解决这个问题而生的。它不是插件，不是外挂工具，而是一种更优雅的方案——让你把经验和规范“教会”给 AI，然后用一个文件固化下来。

要理解 Skill，需要先理解它不是什么。

Skill 不是 MCP（Model Context Protocol）。MCP 连接外部系统，让 AI 能查数据库、调 API、操作文件——这是在扩展 AI 的能力边界。Skill 不做这些。Skill 不给 AI 任何新工具，它只做一件事：改变 AI 面对特定任务时的思考方式和工作流程。

一个类比：

MCP 是给 AI 配了一副新的眼睛和手——看得更多，做得更多
Skill 是给 AI 换了一套内功心法——工具还是那些工具，但出招顺序和内功运转方式完全不同

用更直白的话说：Skill 是一段预定义的提示词，在满足条件时被注入到对话上下文中，让 Claude 临时变成一个“领域专家”。

而它最让人惊讶的地方在于：一个 Skill 就是一个 Markdown 文件。没有配置文件，没有依赖安装，没有服务启动。你创建一个 <code>.md</code> 文件，Skill 就生效了。

方式一：主动调用

你想让 AI 按照某个规范来做安全审查，直接输入：

/security-review

Claude Code 会立刻加载对应的 Skill 内容，对话随即进入“安全专家模式”。

这是最直接的用法——你知道有哪些 Skill，按需取用。

方式二：自动匹配

这才是 Skill 机制真正精妙的地方。每个 Skill 文件头部都有一个 <code>description</code> 字段，这个字段不只是给人类看的说明，更是 Claude 用来做语义路由的依据。

当你对 Claude 说“帮我检查下这段代码有没有安全漏洞”，它可能自动触发 <code>security-review</code> Skill——因为你这句话的语义和该 Skill 的 description 高度吻合。你甚至不需要知道这个 Skill 存在。

这意味着什么？意味着你团队里的新人，不需要培训、不需要看文档，只要正常说出他的需求，系统就会自动匹配最佳的工作流。

Skill 被触发后，其 Markdown 全文会被注入到 Claude 的系统指令层。用户看不到这个过程，但 Claude 后续的所有决策都会受到这份“专业守则”的约束。

Skill 的内容会覆盖 Claude 的默认行为。比如 Skill 里写“使用 async/await 而不是 .then()”，那么在这次对话中，Claude 就不会再产出 <code>.then()</code> 风格的异步代码。

每次触发都是独立加载，互不污染。你先用“API 开发规范” Skill 写了一段代码，再用“安全审查” Skill 审查它——两次加载各自独立，各司其职。

Skill 最适合的场景有一个共同特征：有明确规范、需要反复执行、希望保持一致性。

代码审查：上线前把改动过一遍，检查安全隐患、代码复用度、复杂度
测试编写：确保每次加的测试都覆盖边界条件、异常路径，风格统一
文档生成：按照团队约定的结构生成 README、API 文档
配置优化：扫描历史操作记录，把反复批准的只读命令加入白名单，减少操作摩擦
重复性任务：每隔一段时间自动检查某些状态，按固定格式输出报告

这些场景的共性在于：不是“能不能做”的问题，而是“能不能每次都按同一套标准做”的问题。Skill 解决的就是这个“标准化”的问题。

这三者很容易混淆，但它们各管一摊：

	Skill	MCP	Hook
管什么	怎么思考	能碰什么	什么时候做
本质	一段提示词	外部服务连接	Shell 脚本
加载时机	用户调用 / 语义匹配	会话启动时连接	特定事件触发
改变什么	AI 的行为模式	AI 的能力范围	客户端的执行逻辑
成本	几乎为零	需要运行外部进程	每次事件触发执行一次脚本

一句话区分：

你想让 AI 换个方式思考某个问题 → 用 Skill
你想让 AI 能访问某个数据源 → 用 MCP
你想让 Claude Code 客户端在某个时机自动做某件事 → 用 Hook

创建一个 Skill 的门槛低到令人意外。你只需要在项目中创建 <code>.claude/skills/</code> 目录，然后新建一个 Markdown 文件。

举个例子，创建一个“测试编写规范” Skill：

在 <code>.claude/skills/add-tests.md</code> 中写入：

---
name: add-tests
description: 当用户要求添加测试时触发。覆盖正常路径、边界值和异常情况，使用 describe/it 结构。
---

# 测试编写规范

你是一名测试专家。为用户代码编写测试时，遵循以下规范：

## 执行流程
1. 先分析目标代码的输入输出和依赖关系
2. 列出所有待测场景清单，让用户确认
3. 确认后再动手写测试代码

## 编写原则
- 使用 describe/it 结构
- 一个测试只验证一个行为
- 测试名称描述行为，而不是方法名
- 边界条件和异常路径必须有覆盖

## 输出格式
- 先输出测试清单
- 再逐文件修改

保存。完成。

然后你可以显式调用 <code>/add-tests</code>，或者直接说“帮我给这个模块加测试”，Claude 会自动匹配到它。

一个 Markdown 文件，几段清晰的结构化指令，你就给 AI 教会了一套工作流。这份 Skill 可以提交到 Git 仓库，全团队共享——新人 clone 项目后，Claude Code 就会自动继承所有的团队规范。

根据实际使用经验，好用的 Skill 通常遵循以下几个原则：

1. Description 决定触发准确度

Description 不是摘要，是“匹配引擎”的输入。要写清楚触发场景而非抽象定义。

好：<code>当用户提到“部署”、“上线”、“发布”时触发，指导发布检查清单</code>
差：<code>一个发布助手</code>

2. 教“思考方式”，而非“操作步骤”

Claude 已经知道怎么写代码。Skill 的价值在于告诉它：在这个项目里，什么算“好代码”、先做什么后做什么、要注意哪些坑。

3. 保持精炼

Skill 内容太长，Claude 不一定能完整消化。控制在 500–800 字以内，确保一次性加载、完整执行。

4. 单一职责