Claude Skills：把提示词升级成可复用的 AI 员工能力

如果你招过人或带过新人，你一定知道：一个岗位的能力不是几句口号，而是一套可复制的流程——输入是什么、怎么做、做到什么程度算合格、什么情况要停下来问人。

Skills 做的其实是同一件事：把员工的能力抽象成 AI 的能力。你不再“每次都重新教一遍”，而是把规则写成文件，像 SOP 一样迭代、复用、共享。

2025 年 10 月，Anthropic 为 Claude Code 推出了一个功能：Agent Skills。它看起来不起眼，就是一堆 Markdown 文件，但我认为它代表了提示词管理的终极形态。

最近，OpenAI 的 Codex CLI 也宣布兼容 Skills 格式，把 Skills 放到 ~/.codex/skills/ 目录下即可使用。这说明 Skills 正在成为 AI 编程工具的事实标准。

我会按我自己的顺序聊：先把 Skills 跑起来；再讲为什么它比提示词库/模板更好；最后聊聊怎么让 AI 自己复盘长技能、以及你如何用 Skills 组装出一个能替代工作流的 Agent。

先把它跑起来：Skills 快速上手

Skills 是什么

简单说，Skills 就是你写给 AI 的「工作手册」。

传统的方式是每次对话都告诉 AI 应该怎么做。有了 Skills，你把这些指令写成文件，AI 会自动加载并遵循。

每个 Skill 是一个目录，里面必须有一个 SKILL.md 文件。这个文件定义了这个 Skill 做什么、什么时候触发、具体的行为规则。

Skills 存放在哪里

Skills 可以放在两个位置：

关键区别：

• 全局 Skills 放在 ~/.claude/skills/，这是你的个人 Skills 库，独立于任何项目，在任何地方都能用
• 项目 Skills 放在项目根目录的 .claude/skills/，只在这个项目里生效，可以提交到 Git 和团队共享

对于 Codex CLI 用户，全局 Skills 放在 ~/.codex/skills/，格式完全一样。

创建你的第一个 Skill

让我们一步步创建一个真正能用的 Skill。

场景：假设你经常需要写技术博客，每次都要提醒 AI 遵循特定的写作风格。

第一步：创建目录

# 创建全局 Skill（在任何项目都能用）
mkdir -p ~/.claude/skills/tech-blog-writing

第二步：创建 SKILL.md 文件

在 ~/.claude/skills/tech-blog-writing/ 目录下创建 SKILL.md：

---
name: tech-blog-writing
description: Writes technical blog posts with specific formatting. Use when the user asks to write a blog post, article, or tutorial about technical topics.
---

# 技术博客写作规范

## 结构要求

1. **标题**：简洁有力，包含核心关键词
2. **开头**：用反直觉的观点或问题抓住读者，不要用「首先让我们来了解...」这种无聊开头
3. **正文**：
   - 每个段落不超过 5 句话
   - 专业术语首次出现时解释
   - 代码示例必须可运行
4. **结尾**：总结要点 + 下一步行动建议

## 写作风格

- 口语化，像和朋友聊天
- 不用「首先」「其次」「最后」这种连接词
- 多用具体数字，少用「很多」「一些」

## 格式规范

- 使用 Markdown 格式
- 代码块要标注语言
- 重要观点用粗体强调

第三步：验证 Skill 已加载

启动 Claude Code，输入：

What Skills are available?

Claude 会列出所有可用的 Skills，你应该能看到 tech-blog-writing。

第四步：测试 Skill

输入一个会触发这个 Skill 的请求：

帮我写一篇关于 WebSocket 实时通信的技术博客

Claude 会自动识别这个请求匹配 tech-blog-writing Skill 的 description，加载并应用里面的规则。

SKILL.md 的完整格式

SKILL.md 由两部分组成：

可用的元数据字段：

description 字段的写法很关键。Claude 通过语义匹配来判断用户的请求是否应该触发某个 Skill。写得越清楚，触发越精准。

好的 description 示例：

description: Explains code with visual diagrams and analogies. Use when explaining how code works, teaching about a codebase, or when the user asks "how does this work?"

这个 description 说明了：

1. 这个 Skill 做什么（用图表和类比解释代码）
2. 什么时候触发（解释代码工作原理、教学、用户问「这是怎么工作的」）

多文件 Skill：渐进式加载

对于复杂的 Skill，你可以把内容分散到多个文件里。Claude 会先加载 SKILL.md，然后根据需要动态加载其他文件。这叫渐进式加载（Progressive Disclosure）。

目录结构示例：

~/.claude/skills/api-design/
├── SKILL.md              # 必需，主入口
├── reference.md          # 详细 API 文档
├── examples.md           # 使用示例
└── scripts/
    └── validate.py       # 辅助脚本

在 SKILL.md 里这样引用其他文件：

---
name: api-design
description: Helps design RESTful APIs following best practices.
---

# API 设计指南

## 快速参考
[核心规则写在这里]

## 详细资源
- 完整 API 规范见 [reference.md](reference.md)
- 使用示例见 [examples.md](examples.md)

## 验证脚本
用这个脚本验证 API 设计：
```bash
python scripts/validate.py api-spec.yaml

好处：
- 不会一次性把所有内容都塞进上下文
- 节省 Token，提高响应速度
- 只在需要时加载详细内容

### 实战案例：代码审查 Skill

让我给你一个更完整的实战案例。

**场景**：你希望 Claude 在审查代码时遵循特定的检查清单。

创建 `~/.claude/skills/code-review/SKILL.md`：

```markdown
---
name: code-review
description: Reviews code for quality, security, and best practices. Use when the user asks to review, check, or audit code.
---

# 代码审查规范

当审查代码时，按以下顺序检查：

## 1. 安全性检查 🔒

- [ ] 是否有硬编码的密钥或凭证？
- [ ] 用户输入是否经过验证和清洗？
- [ ] SQL 查询是否使用参数化？
- [ ] 是否有不安全的依赖版本？

## 2. 性能检查 ⚡

- [ ] 是否有 N+1 查询问题？
- [ ] 大数据集是否分页处理？
- [ ] 是否有不必要的内存分配？
- [ ] 异步操作是否正确处理？

## 3. 可维护性检查 🧹

- [ ] 函数是否过长（超过 50 行）？
- [ ] 是否有重复代码可以抽取？
- [ ] 命名是否清晰表达意图？
- [ ] 是否有足够的错误处理？

## 输出格式

审查结果使用以下格式：

### 问题等级
- 🔴 严重：必须修复才能上线
- 🟡 中等：建议修复
- 🟢 建议：可选优化

### 每个问题包含
1. 问题位置（文件:行号）
2. 问题描述
3. 建议的修复方案
4. 修复后的代码示例（如适用）

这样，每次你让 Claude 审查代码，它都会按照这个清单来检查，输出格式也会保持一致。

管理 Skills 的最佳实践

1. 命名规范：使用小写字母和连字符，如 code-review、api-design

2. 一个 Skill 一件事：每个 Skill 专注于一个具体任务，不要写万能 Skill

3. description 要具体：写清楚触发条件，避免误触发

4. 定期维护：像代码一样对待 Skills，根据实际使用效果迭代优化

5. 版本控制：把 Skills 放到 Git 仓库，追踪哪些改动有效

为什么我说 Skills 是提示词管理的终局

现在你知道怎么把 Skills 写出来了。下面聊聊为什么我觉得它比提示词库/模板更好用。

传统提示词管理的痛点

以前管理提示词有几种方式：

方式一：复制粘贴 把好用的提示词存在笔记软件里，每次用的时候复制粘贴。

问题：

• 上下文丢失
• 无法追踪哪个版本有效
• 维护成本高

方式二：Prompt 模板库 用专门的工具管理提示词模板，支持变量替换。

问题：

• 与工作流程割裂
• 还是需要手动复制粘贴
• 不支持条件触发

方式三：System Prompt 配置 在 AI 工具里设置系统提示词。

问题：

• 不支持版本控制
• 难以分享和协作
• 所有场景用同一套规则

Skills 的核心优势

Skills 解决了所有这些问题：

提示词终于可以像代码一样维护

我觉得这里是 Skills 最值钱的一点。

传统的提示词是「一次性」的。你写了一个提示词，用了，结束。下次用的时候，可能又重新写一个。

Skills 把提示词变成了「可迭代的资产」。你可以：

1. 持续优化：根据实际效果不断改进 Skill 的规则
2. A/B 测试：用 Git 分支测试不同版本的 Skill
3. 知识积累：好的规则沉淀下来，不会随对话结束而丢失

这就像从「口头约定」进化到「书面合同」，从「即兴演讲」进化到「标准流程」。

当 Skills 多了：工作方式会翻过来

然后你会发现：当 Skills 足够多，AI 就不只是“帮你写”，而是开始接管一段完整流程。

Agent 的根本问题

AI Agent 有一个致命问题：不可预测。

同样的 prompt，运行十次可能得到十个不同的结果。这种不确定性意味着你不敢把关键任务完全交给 Agent。

你可以让 Agent 当助手，帮你做探索性工作。但你不敢让它替代一个岗位。

Skills 解决了可控性问题

Skills 让 Agent 变得可控：

• 可审计：每个 Skill 都是明文写的规则，你能看到 AI 收到了什么指令
• 可版本化：Git 追踪每次修改，知道哪个版本有效
• 可测试：可以用特定输入验证输出是否符合预期
• 可修正：出了问题改 Skill 就行，不需要祈祷模型变聪明

每份工作都会变成 N 个 Skills

想想你的日常工作。

你做的事情，大概可以分解成若干个重复的「模式」：

• 写周报有固定格式
• 代码审查有固定检查清单
• 回复客户邮件有固定话术
• 新员工培训有固定流程

每个「模式」都可以变成一个 Skill。

当你把工作中的关键模式都转化为 Skills 之后，你的角色就变了：从「执行者」变成「监督者」。

从 Human Loop 到 Agent Loop

今天的工作范式是 Human Loop：

事件发生 → 人类注意到 → 人类决策 → 人类执行

AI 只是人类调用的工具，你在环路中间，是瓶颈也是控制点。

有了足够可靠的 Skills，范式会转变为 Agent Loop：

事件发生 → Agent 检测 → Skill 执行 → 人类审核（可选）

人类从「操作者」变成「监督者」。你不再需要亲自做每件事，而是审核 Agent 的输出，只在必要时介入。

让 AI 自己编排 Skills：从“会用”到“会调度”

如果你把 Skills 当成一堆“提示词文件”，你只能省一点复制粘贴。

但把它当成“技能库”，玩法就变了：一个复杂任务，不是让模型凭感觉输出，而是让 Agent 先把任务拆成步骤，然后按需触发/加载对应的 Skills，最后再统一验收。

最简单的编排套路是：

1. 先让 Agent 列出它觉得会用到的 Skills（不确定就问：What Skills are available?）
2. 输出一个执行计划（每一步对应一个 Skill + 明确输入/输出）
3. 边做边自检（如果有 checklist/审查类 Skill，直接让它来验收）
4. 最后复盘：本次哪些步骤值得沉淀成新 Skill，哪些旧 Skill 需要迭代

如果你想更彻底一点，可以专门写一个“编排器”Skill：它不负责具体执行，而是负责拆解任务、选择技能、安排顺序、最后给验收清单。你以后只要说“从头到尾搞定 X”，它就会按这套流程跑。

---
name: skill-orchestrator
description: Orchestrates other Skills to complete an end-to-end task. Use when the user asks to "从头到尾搞定/全自动处理" a task.
---

# 技能编排器

- 把任务拆成 3-7 步，并为每一步写清楚输入/输出/验收
- 优先复用已存在的 Skills；缺的就先生成草稿 Skill，再标注需要你确认的边界
- 过程输出必须可追踪：做了什么、为什么这么做、下一步是什么

最省事的 Skill 生成法：做一遍 → 复盘 → 固化

你不需要坐在那儿“规划我要写哪些 Skill”。最省事的方法其实是：先把一次真实任务做完，然后让 AI 把刚刚的做法抽象成一套可复用的 Skills。

你可以用这个复盘提示词（做完任何事务都适用）：

我们刚刚完成了【任务】。请把你刚刚采用的方法抽象成一套可复用的 Skills（可以拆成多个 Skill），并输出：
1) 每个 Skill 的 name / description（description 要包含触发条件，给 3 个正例 + 3 个反例）
2) 目录结构（.claude/skills/... 或 ~/.codex/skills/...）
3) 每个 SKILL.md 的完整内容（目标、适用/不适用、步骤、决策点、风险边界、验收清单、输出格式）
4) 最小测试用例：如何触发 + 期望输出
约束：一个 Skill 只做一件事；优先复用现有 Skills；不要把一次性信息写进 Skill。

你会发现，Skills 最强的地方不是“写得多漂亮”，而是“每做一次就多一份复利”。

Skills 会快速增长

App Store 用了 15 年积累 200 万个 App。

Skills 可能在 2-3 年内达到这个数量。

为什么？因为创建 Skill 的门槛极低：

1. 一个 Skill 就是一个 Markdown 文件
2. 几分钟就能创建
3. AI 可以帮你生成和优化

更重要的是，AI 可以观察你的工作并生成 Skill。

你做一遍某个任务，让 Claude 观察你的操作过程，它就能总结出一个 Skill。然后你微调几分钟，这件事从此自动化了。

自动化模式：三大的「放飞自我」的AI员工

如果你想要有几个完全自主的 AI 员工，可以试试这样：

# Claude Code：跳过权限检查
claude --dangerously-skip-permissions

# Codex CLI：沙箱内自动执行
codex --sandbox workspace-write --ask-for-approval never

# Gemini CLI：YOLO 模式
gemini -m gemini-3-flash-preview --yolo

这些「放飞自我」的模式之所以可行，正是因为有了 Skills。

当你把规则写清楚了，AI 就会按规则执行。你不需要每次都盯着它，担心它会做出意外的事情。

Skills 让自动化成为可能。

Skill 的本质，是把“岗位能力”写成文件

把 Skills 可以作为提示词管理工具，但我更喜欢把它理解成：把员工的能力抽象成 AI 的能力。

你写的每个 Skill，本质上都在回答四个问题：

• 输入是什么？
• 期望输出长什么样？
• 中间的步骤/决策点是什么？
• 哪些风险要停下来问人，怎么验收？

当这些东西变成文件、能被版本控制、能被复用，你就不是在“调模型”，而是在“写员工”。

我越来越相信，2026 年 AI Agent 真正替代人的方式，大概率也不是靠模型再聪明一点，而是靠这套能力工程：把岗位拆成一组 Skills，再把 Skills 编排成工作流。模型负责推理，工具负责行动，Skills 负责稳定性和可控性。

最现实的起步方式也很朴素：从一个你每周都会做的重复事务开始，做一遍，然后让 AI 复盘并把流程固化成 Skills。下一次直接让它跑，遇到问题就迭代 Skill，而不是换 prompt 碰运气。

从那一刻开始，你积累的不是“灵感”，而是一支会越来越能干的数字员工队伍。

最后提醒一句，直接复制网上公开的Skills, 也要谨防一下是否有放权过度，Key泄露等风险。