🧠 别再让 AI 裸奔了！用 Skills 让 AI 秒变专属员工
摘要 ：你是不是每次打开 AI 对话框，第一句都在重复"我是谁、我在做什么、这次要做什么"？2026 年了，聪明人已经把重复的 Prompt 固化成了 Skills------一个
/skill-name就能让 AI 秒变你的专属员工。本文从概念到实战，带你彻底搞懂 Skills 技能系统。
适用范围 ：本文以 Claude Code 为主要示例平台，Skills 概念遵循 Anthropic 官方文档 定义的规范。部分高级特性（如动态上下文注入、子代理隔离）为 Claude Code 特有能力，其他 AI 平台的 Skill 实现可能有所不同。
📌 前言：AI 使用的三个阶段，你在哪一层？
先问一个问题：你每天是怎么用 AI 的？
| 阶段 | 行为 | 本质 |
|---|---|---|
| 第一阶段 | 打开对话框，问一个问题，得到答案，关掉 | 把 AI 当百度用 |
| 第二阶段 | 研究 Prompt Engineering，写复杂的提示词 | 开始"驯服" AI |
| 第三阶段 | 把 Prompt 固化成 Skills，打开就能干活 | 让 AI 成为你的员工 |
大多数人都卡在第二阶段------每次都要写一遍 Prompt，换个电脑又要重来，团队其他人更是无从复用。
而第三阶段的核心思想是 ：把你的专业能力"蒸馏"成一个 SKILL.md 文件，让 AI 在需要的时候自动加载，就像给 AI 装了一个个"技能包"。
💡 一句话理解 Skills：Skills 就是你把"我是谁、我擅长什么、我怎么做"这些信息，从临时的对话 Prompt 变成了永久的、可复用的、可组合的技能模块。
🎯 什么是 Skills？为什么你需要它？
定义
Skills（技能）是模块化的指令集。一个 Skill 就是一个文件夹，里面有一个 SKILL.md 入口文件，告诉 AI：
- 我是谁（name）
- 我什么时候该被调用（description）
- 我具体怎么做（Markdown 正文的指令）
为什么需要 Skills？
想象一个场景：
你是一个团队 leader，每周要开 3-4 次会。每次开完会，你要手动整理会议纪要：谁说了什么、要做什么、截止时间是什么。这个过程每次要花 30 分钟。
没有 Skills 的日子：
- 打开 AI
- 复制粘贴会议录音文本
- 写一段 Prompt："请帮我整理会议纪要，提取主题、负责人、截止时间..."
- AI 输出的格式每次都不一样
- 下次再开会，重复以上所有步骤
有了 Skills 之后：
- 打开 AI
- 输入
/meeting-minutes - 粘贴会议文本
- 完成。格式一致，结构专业，3 分钟搞定
这就是 Skills 的价值------把重复的、专业的、高频的操作固化下来。
我的实际体验
说实话，我一开始觉得 Skills "没必要"------不就是把 Prompt 存成文件吗？直到有一天我发现：
- 我每天要写 3 遍几乎相同的 Prompt（代码审查、会议纪要、日报生成）
- 换个项目又要重新写，因为 Prompt 存在聊天记录里找不到
- 团队其他人不知道我有一套好用的 Prompt，各写各的
封装成 Skill 之后的变化 ：代码审查从 15 分钟写 Prompt 变成了 3 秒输入 /code-review，输出格式统一，团队共用一套标准。
📁 Skills 的文件结构与存放位置
目录结构
bash
.claude/skills/
└── meeting-minutes/ # 技能文件夹
├── SKILL.md # ⭐ 入口文件（必须）
├── README.md # 说明文档（可选）
├── templates/ # 模板文件（可选）
│ └── template.html
├── scripts/ # 可执行脚本（可选）
│ └── generate.py
└── evals/ # 测试用例（可选）
└── evals.json核心规则：
SKILL.md是入口，必须有- 其他文件都是可选的，用于增强 Skill 的能力
- 通过在
SKILL.md中引用这些文件，AI 会在需要时加载它们
存放位置与优先级
Skills 可以放在多个位置，覆盖优先级如下：
| 位置 | 路径 | 作用域 | 优先级 |
|---|---|---|---|
| 企业级 | 通过 managed settings 分发 | 全组织 | 最高 |
| 个人级 | ~/.claude/skills/ |
你的所有项目 | 高 |
| 项目级 | 项目/.claude/skills/ |
当前项目 | 中 |
| 嵌套级 | 子目录/.claude/skills/ |
特定子模块 | 低 |
| 插件级 | 插件自带 skills | 插件作用域 | 独立命名空间 |
同名覆盖规则：企业 > 个人 > 项目 > 内置
Monorepo 支持：
bash
monorepo/
├── .claude/skills/deploy/ # 项目级 deploy skill
└── apps/web/.claude/skills/deploy/ # 嵌套级 deploy skill- 输入
/deploy→ 调用项目级 - 输入
/apps/web:deploy→ 调用嵌套级 - AI 自动选择与当前工作目录匹配的版本
SKILL.md 的标准模板
markdown
---
name: my-skill
description: 当用户需要 XXX 时使用此技能。适用于 YYY 场景。
---
# 技能标题
## 输入
用户会提供 [描述输入格式]
## 处理步骤
1. **第一步**：做什么
2. **第二步**：做什么
3. **第三步**：做什么
## 输出格式
[定义期望的输出结构]
## 注意事项
- [约束条件 1]
- [约束条件 2]⚠️ 关键点 ：
---之间的部分是 YAML frontmatter ，用于声明元数据；---之后是 Markdown 正文，用于写具体指令。
🔧 Frontmatter 详解：Skill 的"身份证"
Frontmatter 是 Skill 的配置中心，决定了 AI 什么时候调用、怎么调用你的 Skill。
核心字段一览
yaml
---
name: meeting-minutes # 技能名称（显示用，非调用名）
description: 生成结构化会议纪要。当用户提供会议录音文本、讨论记录时使用。
disable-model-invocation: false # 是否禁止 AI 自动调用
user-invocable: true # 是否允许用户通过 /skill-name 调用
context: inline # 执行上下文：inline 或 fork
allowed-tools: # 预授权的工具列表
- "Bash(git *)"
- "WebFetch"
disallowed-tools: # 禁用的工具列表
- "Bash(rm *)"
arguments: # 参数定义
- name: format
description: 输出格式（detailed 或 brief）
required: false
---各字段详解
| 字段 | 类型 | 说明 | 示例 |
|---|---|---|---|
name |
string | 技能显示名称 | meeting-minutes |
description |
string | 最重要的字段！ AI 靠它判断是否调用 | 生成结构化会议纪要 |
disable-model-invocation |
bool | true = 只能用户手动调用 |
用于部署、发布等有副作用的操作 |
user-invocable |
bool | false = 只有 AI 能调用 |
用于背景知识，不适合当命令 |
context |
string | fork = 在隔离的子代理中运行 |
需要独立上下文的任务 |
allowed-tools |
list | 调用时自动授权的工具 | ["Bash(git *)"] |
arguments |
list | 参数定义 | 见上表 |
description 的重要性
description 字段是 AI 判断"要不要用这个 Skill"的唯一依据。
好的 description：
makefile
description: 生成结构化会议纪要。当用户提供会议录音文本、讨论记录时使用。
适用于项目会议、团队讨论、客户电话、规划评审等场景。差的 description：
makefile
description: 会议相关💡 踩坑经验 ：description 要包含用户会怎么说 的关键词。我一开始写
description: 会议工具，结果 AI 从来不自动触发------因为用户说的是"帮我整理会议纪要"，而不是"帮我用会议工具"。改成生成结构化会议纪要之后，触发率直接从 0 到 90%。
📝 实战案例 1：会议纪要 Skill
这是一个真实在用的 Skill，解决"每次开完会都要手动整理纪要"的痛点。
SKILL.md（完整版）
markdown
---
name: meeting-minutes
description: 生成结构化会议纪要。当用户提供会议录音文本、讨论记录时使用。
适用于项目会议、团队讨论、客户电话、规划评审等场景。
---
# 会议纪要生成器
从原始会议文本中提取结构化纪要。
## 输入
用户提供会议录音转写文本或讨论记录文件。
## 处理步骤
1. **通读全文**：理解整体上下文后再提取
2. **过滤噪音**：剔除闲聊、跑题、重复内容
3. **结构化提取**：按下方模板组织信息
## 输出结构
# 会议纪要
## 一、会议基本信息
- **会议时间**：[从文本提取或留空]
- **参会人员**：[列出所有提到的参会人]
- **会议时长**：[如可判断]
## 二、会议目标
- **会议目的**：[为什么开这个会]
- **背景信息**：[相关上下文]
## 三、会议内容
### [议题 1 名称]
**讨论内容**：[要点]
**主要观点**：
- [观点 A - 某人]
- [观点 B - 某人]
**结论/决议**：[如有]
### [议题 2 名称]
...
## 四、行动项
| 序号 | 任务内容 | 负责人 | 截止时间 | 备注 |
|------|----------|--------|----------|------|
| 1 | [任务] | [人名] | [日期] | [备注] |
## 五、待确认事项
- [未解决的问题]
## 准则
- **准确性优先**：只提取文本中明确提到的信息
- **不确定就留空**：不要猜测或推断
- **保留原意**：忠实总结，不加个人解读
- **按主题组织**：按议题分类，而非按时间顺序
- **行动项要具体**：包含谁、做什么、什么时候使用效果
输入（会议录音转写文本，约 2000 字）：
makefile
发言人1: 今天咱们碰个头，主要是团建的事。公司小部门好久没团建了，二月份上班到现在八个月了...
发言人2: 我觉得有必要团建。应该去郊区，体验农家生活，爬山、篝火晚会...
发言人3: 我同意去郊区，有山有水的地方，多做一些对抗性活动增加凝聚力...
发言人4: 同意郊区方案。路程合适，一两天时间，参与性强，不像K歌有的人只能当旁观者...输出（结构化纪要，完整输出）：
markdown
# 会议纪要
## 一、会议基本信息
- **参会人员**：发言人1、发言人2、发言人3、发言人4
- **会议时长**：约 6 分钟
## 二、会议目标
- **会议目的**：讨论部门团建方案
- **背景信息**：部门自二月份以来八个月未团建，现疫情管控放松
## 三、会议内容
### 团建必要性
**讨论内容**：讨论是否需要组织团建
**主要观点**：
- 发言人2：有必要，能增加同事间友谊和信任
- 发言人3：工作压力大，需要劳逸结合
- 发言人4：同意，需要放松
**结论/决议**：全员同意组织团建
### 团建方案
**讨论内容**：讨论具体团建形式和地点
**主要观点**：
- 发言人2：反对K歌吃饭（太俗），建议去郊区农家体验
- 发言人3：同意郊区，要有山有水，做对抗性活动
- 发言人4：郊区参与性强，一两天时间合适
**结论/决议**：去北京郊区（门头沟/延庆/房山等），一两天行程
## 四、行动项
| 序号 | 任务内容 | 负责人 | 截止时间 | 备注 |
|------|----------|--------|----------|------|
| 1 | 向领导申请团建经费 | 发言人1 | 待定 | 公司报销 |
| 2 | 调研郊区团建场地 | 发言人2 | 待定 | 含农家、CS、水上乐园 |
## 五、待确认事项
- 具体出行日期待定
- 团建预算待领导审批踩坑提醒
- 输入文本质量很重要：录音转写如果有大量错别字或噪音，输出质量会下降。建议先用 ASR 工具做一次清洗。
- 多人发言识别：如果录音转写没有标注发言人，Skill 会尽力推断，但准确率会降低。
- 长会议分段处理：超过 30 分钟的会议文本建议分段输入，避免上下文过长导致遗漏。
📰 实战案例 2：AI 日报 Skill
这个 Skill 更有意思------它不只是处理文本，还能自动抓取网页、智能摘要、生成 HTML 页面。
核心思路
css
抓取新闻源 → 智能过滤 → 生成中文摘要 → 渲染为精美 HTML 页面SKILL.md 关键部分
markdown
---
name: tian-ai-daily
description: 甜甜每日AI新闻概览。当用户想要获取AI新闻、行业动态、
科技资讯时使用此技能。
---
# 甜甜AI日报
## 资讯源
- TechCrunch: https://techcrunch.com/category/artificial-intelligence/
- The Verge: https://www.theverge.com/ai-artificial-intelligence
- Hacker News: https://news.ycombinator.com/
## 工作流程
### 步骤1: 资讯抓取
使用 WebFetch 工具抓取各媒体网站
### 步骤2: 内容筛选
- 提取标题、链接、发布时间
- 评估文章质量（评论数、热度）
- 过滤非 AI 相关内容
### 步骤3: 摘要生成
- 每条资讯提炼 50-100 字核心要点
- 使用简洁的中文表达
- 标注关键词标签（#大模型 #融资 #开源 等）
### 步骤4: HTML 生成
运行脚本生成精美页面：
!`python ${CLAUDE_SKILL_DIR}/scripts/generate_html.py`亮点解析
- 动态上下文注入 ：
!command`` 语法在 Skill 加载前执行 shell 命令，将输出注入 prompt（⚠️ 这是 Claude Code 特有功能） - 脚本集成：Skill 不只是 Prompt，还能跑 Python 脚本生成可视化输出
- 路径变量 ：
${CLAUDE_SKILL_DIR}自动解析为当前 Skill 的目录路径（⚠️ Claude Code 特有变量）
关于 HTML 生成脚本
HTML 生成的核心逻辑是：用 Python 读取新闻数据 → 渲染卡片式 HTML → 输出为独立文件。脚本使用 Python 内置库（json、os、datetime），无需额外安装依赖。
💡 由于篇幅限制，完整的
generate_html.py脚本和 HTML 模板代码较长，建议直接参考项目仓库中的实际文件。核心思路是：定义卡片模板 → 遍历新闻数据填充 → 写入 HTML 文件。
🚀 高级技巧：让 Skill 更强大
技巧 1：动态上下文注入（Claude Code 特有）
在 Skill 加载前执行 shell 命令，把实时数据注入 prompt：
markdown
## 当前代码变更
以下是未提交的 git diff：
!`git diff HEAD`
请分析这些变更的风险点。原理 ：``!`command``` 在 Skill 发送给 AI 之前执行，AI 看到的是命令的输出，而不是命令本身。
实际应用场景：
- 代码审查：自动注入
git diff，AI 直接分析变更 - PR 总结：自动注入
gh pr diff，AI 生成 PR 描述 - 环境检查：自动注入
node --version、python --version等
技巧 2：参数传递（Claude Code 特有）
让 Skill 接受参数，变成通用工具：
markdown
---
name: fix-issue
description: 修复 GitHub Issue
---
修复 GitHub Issue #$ARGUMENTS，遵循我们的编码规范。
检查要点：
1. 问题根因分析
2. 最小化修复方案
3. 添加测试用例使用 ：/fix-issue 123 → AI 收到 "修复 GitHub Issue #123..."
索引参数 ：$0、$1、$2 可以获取各个位置的参数。
技巧 3：控制调用方
有些 Skill 不应该让 AI 自动触发：
yaml
---
name: deploy
description: 部署应用到生产环境
disable-model-invocation: true # 只能用户手动调用
allowed-tools:
- "Bash(kubectl *)"
- "Bash(docker *)"
---场景：部署、发布、删除数据等有副作用的操作，必须由人类显式触发。
💡 踩坑经验 ：我曾经把一个数据迁移的 Skill 没加
disable-model-invocation: true，结果 AI 在我讨论数据库方案的时候自动触发了它。幸好只是 dry-run 模式，但这个教训让我记住了：有副作用的 Skill 一定要加这个字段。
技巧 4：子代理隔离执行（Claude Code 特有）
yaml
---
name: research
description: 深度研究某个技术主题
context: fork # 在隔离的子代理中运行
agent: Explore # 使用内置的 Explore 代理
---优势：
- 不污染主对话上下文
- 使用专门优化过的代理（如 Explore 只读代理）
- 结果会被总结后返回主对话
技巧 5：支持文件组织复杂 Skill
markdown
---
name: code-review
description: 代码审查
---
# 代码审查
审查代码变更，关注以下维度：
1. **安全性** - 参考 ${CLAUDE_SKILL_DIR}/rules/security.md
2. **性能** - 参考 ${CLAUDE_SKILL_DIR}/rules/performance.md
3. **可维护性** - 参考 ${CLAUDE_SKILL_DIR}/rules/maintainability.md
输出格式参考：${CLAUDE_SKILL_DIR}/templates/report.md好处：主文件保持简洁，详细规则放在支持文件中，AI 只在需要时加载。
💡 设计模式：如何设计一个好的 Skill？
模式 1：单一职责原则
好的拆分：
meeting-minutes/→ 生成会议纪要code-review/→ 代码审查deploy/→ 部署changelog/→ 生成变更日志
坏的设计：
all-in-one-assistant/→ 会议 + 代码 + 部署 + 日报...
一个 Skill 只做一件事。如果你发现 description 里写了"当用户需要 A 或 B 或 C 时"，说明这个 Skill 需要拆分。
模式 2：参考内容 vs 任务内容
| 类型 | 特征 | 适合场景 | 调用方式 |
|---|---|---|---|
| 参考内容 | 添加知识，增强上下文 | 编码规范、架构文档、领域知识 | AI 自动加载 |
| 任务内容 | 执行具体操作的步骤 | 部署流程、发布检查、代码生成 | 用户手动 /skill |
参考内容示例：
markdown
---
name: coding-standards
description: 团队编码规范
user-invocable: false # 用户不需要手动调用
---
# 编码规范
- 使用 TypeScript strict 模式
- 函数命名使用 camelCase
- 组件命名使用 PascalCase任务内容示例：
markdown
---
name: deploy
description: 部署应用
disable-model-invocation: true # 必须手动触发
context: fork # 隔离执行
---
# 部署流程
1. 运行测试
2. 构建镜像
3. 推送 registry
4. 更新 k8s 部署模式 3：Skill 组合（乐高模式）
Skills 可以像乐高一样组合使用（Claude Code 支持同时加载多个 Skill）：
bash
/code-review /fix-issue 123这会同时加载 code-review 和 fix-issue 两个 Skill，123 作为参数传递给最后一个。
组合场景：
/summarize-changes+/code-review→ 先总结变更，再审查代码/research+/implement→ 先研究方案，再实现代码
🎯 Token 消耗与优化
这是一个容易被忽视但非常重要的知识点。
Skill 的生命周期
bash
用户调用 /skill-name
↓
SKILL.md 内容渲染（变量替换、命令执行）
↓
渲染后的内容作为一条消息进入对话上下文
↓
在后续所有对话轮次中持续存在
↓
上下文压缩时，每个 Skill 保留前 5000 tokens
↓
多个 Skill 共享 25000 tokens 的预算（优先保留最近使用的）⚠️ 以上数字基于 Claude Code 2026 年 7 月的文档，具体数值可能因版本更新而变化，请以官方文档为准。
这意味着：
- Skill 的每一行都是持续的 token 成本
- 要像写 CLAUDE.md 一样保持简洁
- 说"做什么"，而不是"为什么这么做"
- 大量参考资料放在支持文件中，按需加载
优化建议
| 策略 | 做法 | 效果 |
|---|---|---|
| 精简正文 | 删除冗余解释，只保留指令 | 减少 token 消耗 |
| 外置参考 | 大段参考内容放到支持文件 | 按需加载，不占常驻 token |
| 合理描述 | description 控制在 200 字以内 | 避免 Skill 列表被截断 |
| 控制数量 | 不常用 Skill 设为手动触发 | 减少自动加载的开销 |
🧪 评估与迭代：怎么知道 Skill 好不好用？
评估维度
| 维度 | 检查点 |
|---|---|
| 触发准确性 | AI 在该用的时候用了？不该用的时候没用？ |
| 输出质量 | 输出符合预期？格式正确？ |
| Token 效率 | Skill 加载后消耗的 token 是否合理？ |
手动评估方法
- 收集几个真实 prompt
- 在有 Skill 和无 Skill 的情况下分别运行
- 对比输出质量
- 用新会话测试（避免上下文干扰）
使用 skill-creator 插件（Claude Code）
Anthropic 官方提供了 skill-creator 插件，可自动化评估流程。安装后运行 evaluate my skill with skill-creator，它会：
- 编写测试用例 ：存储在
evals/evals.json - 隔离运行：每个用例在独立子代理中执行
- 自动评分：检查输出是否符合断言
- 基准对比：有 Skill vs 无 Skill 的效果对比
- 版本对比：A/B 测试两个版本
💡 插件的具体安装命令可能随版本更新，请参考 Anthropic 官方插件文档 获取最新安装方式。
常见问题排查
| 问题 | 可能原因 | 解决方案 |
|---|---|---|
| Skill 不触发 | description 缺少关键词 | 补充用户会说的关键词 |
| 触发太频繁 | description 太宽泛 | 使描述更精确，或加 disable-model-invocation: true |
| 输出不稳定 | 指令不够具体 | 添加更多约束和示例 |
| 描述被截断 | Skill 太多，超出预算 | 提升 skillListingBudgetFraction 设置 |
🔗 与 MCP、Memory 的关系
2026 年的 AI 工具生态中，有三个核心概念经常被混淆：
| 概念 | 定义 | 类比 |
|---|---|---|
| MCP (Model Context Protocol) | Anthropic 推出的开放协议，标准化 AI 与外部工具/数据源的连接方式 | AI 的"USB 接口" |
| Memory | 持久化记忆，跨会话记住你的偏好和上下文 | AI 的"长期记忆" |
| Skills | 可复用的指令集，封装专业能力 | AI 的"技能包" |
三者协同：
- MCP 让 AI 能访问数据库、API、文件系统（通过标准化的 Server/Client 架构）
- Memory 让 AI 记住你的项目背景、编码偏好
- Skills 让 AI 知道如何专业地完成特定任务
💡 一个完整的 AI 工作流：Memory 提供上下文 → Skills 提供方法论 → MCP 提供工具能力。
📊 总结：Skills 精华速查表
| 主题 | 核心要点 |
|---|---|
| 是什么 | 可复用的模块化指令集，SKILL.md 是入口 |
| 为什么 | 把重复 Prompt 固化，提升效率和一致性 |
| 怎么写 | YAML frontmatter（元数据）+ Markdown 正文（指令） |
| 关键字段 | description（触发依据）、disable-model-invocation（调用控制） |
| 高级技巧 | 动态注入、参数传递、子代理隔离（均为 Claude Code 特有） |
| 设计原则 | 单一职责、参考 vs 任务分离、乐高式组合 |
| 存放位置 | 企业级 > 个人级 > 项目级 > 嵌套级 |
| 优化要点 | 精简正文、外置参考、控制数量 |
🎬 最后的话
2026 年，用 AI 的人分成了两批：
- 第一批：每次打开对话框，第一句都在解释"我是谁、我在做什么"。AI 每次都像一个新来的实习生，什么都不知道。
- 第二批：打开就能干活。AI 知道你是谁，有你的工作技能（Skills），有你的记忆（Memory），有你的工具（MCP）。
Skills 就是从第一批人进化到第二批人的关键一步。
从今天开始，把你最常重复的那件事，封装成第一个 Skill 吧。
🔗 参考资料
- Anthropic 官方文档 - Skills
- Anthropic 官方文档 - Subagents
- Anthropic 官方文档 - Plugins
- Anthropic 官方文档 - Permissions
如果觉得有帮助，欢迎点赞收藏，后续会分享更多 AI Agent 实战内容。
💬 你在工作中最想把哪件事封装成 Skill？评论区聊聊，说不定下一篇就写你的需求！