<!-- title: Skill设计五模式：原子到编排器实战 -->

# Claude Code Skill设计模式：原子化到编排器实战

本教程面向已有Claude Code基础使用经验、希望系统掌握Skill架构设计的开发者。通过Anthropic官方推荐的五大设计模式，结合原子化Skill原则与编排器（Orchestrator）架构，你将从零构建一套可组合、可测试、可维护的生产级Skill体系。适用于需要将团队知识系统化封装、或构建复杂自动化工作流的中高级开发者。

---

## 前置条件

| 条件 | 说明 |
|------|------|
| Claude Code版本 | ≥ 1.0.50（支持Skill发现与YAML Frontmatter） |
| Node.js | ≥ 18.x（用于运行辅助脚本） |
| 基础知识 | 熟悉Markdown语法、YAML格式、Bash命令行 |
| 项目环境 | 已有Claude Code项目，或新建一个空项目 |

---

## 一、Skill设计的核心问题

大多数开发者在创建Skill时，面临三个关键架构决策：

1. **粒度问题**：一个Skill应该做多少事？太大难以复用，太小又缺乏价值。
2. **组合问题**：多个Skill如何协同工作？谁来协调执行顺序？
3. **边界问题**：Skill之间如何传递上下文？如何处理失败？

Anthropic在其官方指南《The Complete Guide to Building Skills for Claude》中提炼了五种核心设计模式，本文将逐一实战。

```mermaid
graph TD
    A[Skill设计核心问题] --> B[粒度：原子化]
    A --> C[组合：编排器]
    A --> D[边界：契约接口]
    B --> B1[单一职责]
    B --> B2[自包含指令]
    C --> C1[顺序链]
    C --> C2[并行扇出]
    C --> C3[条件分支]
    D --> D1[输入输出契约]
    D --> D2[错误恢复]
```

---

## 二、模式一：原子Skill（Atomic Skill）

### 2.1 设计原则

原子Skill遵循**单一职责原则（SRP）**：每个Skill只做一件事，做好一件事。判断标准是——能否用一句话准确描述Skill的功能。如果需要"和"字连接，就说明它应该拆分。

### 2.2 实战：创建代码格式化Skill

创建项目目录结构：

```bash
mkdir -p .claude/skills/code-formatter
```

编写 `.claude/skills/code-formatter/SKILL.md`：

```yaml
---
name: code-formatter
description: 使用Prettier和ESLint自动格式化指定文件或目录
trigger: 当用户要求格式化代码、修复lint问题、统一代码风格时激活
tools:
  - Bash
  - Read
  - Edit
effort: 3
---

# 代码格式化Skill

## 执行流程

1. 确认目标路径（文件或目录）
2. 检测项目中的格式化配置：
   - `.prettierrc*` 或 `prettier.config.*`
   - `.eslintrc*` 或 `eslint.config.*`
3. 若无配置文件，使用以下默认规则：
   ```json
   {
     "semi": true,
     "singleQuote": true,
     "trailingComma": "es5",
     "printWidth": 100
   }
   ```
4. 执行格式化：
   ```bash
   npx prettier --write "<目标路径>"
   ```
5. 执行lint修复（如ESLint可用）：
   ```bash
   npx eslint --fix "<目标路径>"
   ```
6. 输出格式化报告：修改了哪些文件，修复了哪些问题

## 边界约束

- 只处理格式化，不做代码逻辑修改
- 不安装新的npm包，仅使用项目已有依赖或npx
- 如果格式化导致语法错误，立即回滚并报告

## 输出格式

```
✅ 格式化完成
📁 处理文件：12个
🔧 修改文件：5个
⚠️ 跳过文件：1个（原因：解析错误）
```
```

### 2.3 为什么这是原子Skill

| 检查项 | 结果 |
|--------|------|
| 能否一句话描述功能 | "格式化代码" ✓ |
| 是否需要"和"连接 | 不需要 ✓ |
| 是否自包含 | 不依赖其他Skill ✓ |
| 是否可独立测试 | 是，给定文件即可验证 ✓ |

---

## 三、模式二：编排器Skill（Orchestrator Skill）

### 3.1 设计原则

编排器Skill是"大脑型"Skill——它本身不执行具体任务，而是协调多个子Skill按流程执行。核心特征：

- **声明式流程**：用步骤列表定义执行顺序
- **子Skill委托**：通过`subagent`配置声明依赖
- **上下文传递**：在步骤间传递结构化数据

### 3.2 实战：构建代码审查编排器

创建目录结构：

```bash
mkdir -p .claude/skills/code-review-orchestrator
```

编写 `.claude/skills/code-review-orchestrator/SKILL.md`：

```yaml
---
name: code-review-orchestrator
description: 编排完整的代码审查流程，串联格式检查、安全扫描、逻辑审查三个阶段
trigger: 当用户提交代码审查请求、创建PR、或要求review代码变更时激活
tools:
  - Task
  - Read
  - Bash
  - Grep
  - Glob
subagents:
  - code-formatter
  - security-scanner
  - logic-reviewer
effort: 5
---

# 代码审查编排器

你是一个代码审查流程的编排器。你不直接执行审查任务，而是协调子Skill完成工作。

## 编排流程

### 阶段一：格式检查
- 委托 `code-formatter` Skill检查目标代码的格式合规性
- 收集格式问题报告
- 如果存在严重格式问题，询问用户是否先修复再继续

### 阶段二：安全扫描
- 委托 `security-scanner` Skill扫描以下风险：
  - SQL注入、XSS、命令注入（OWASP Top 10）
  - 硬编码密钥、凭证泄露
  - 不安全的依赖版本
- 收集安全报告，标记风险等级

### 阶段三：逻辑审查
- 委托 `logic-reviewer` Skill审查：
  - 代码逻辑正确性
  - 边界条件处理
  - 错误处理完整性
  - 性能隐患
- 收集逻辑审查报告

## 输出汇总

将三个阶段的结果汇总为结构化报告：

```markdown
# 代码审查报告

## 📋 概览
- 审查文件：X个
- 发现问题：Y个（严重：A，警告：B，建议：C）

## 🔧 格式问题（阶段一）
[格式化报告摘要]

## 🔒 安全问题（阶段二）
[安全扫描摘要，按风险等级排列]

## 🧠 逻辑问题（阶段三）
[逻辑审查摘要，按严重程度排列]

## ✅ 推荐操作
[按优先级排列的修复建议]
```

## 错误处理

- 任一阶段失败时，记录错误并继续下一阶段
- 最终报告中标注失败阶段和原因
- 不因单个阶段失败而中断整个流程
```

### 3.3 编排器架构流程图

```mermaid
sequenceDiagram
    participant U as 用户
    participant O as 编排器Skill
    participant F as 格式检查
    participant S as 安全扫描
    participant L as 逻辑审查

    U->>O: 请求代码审查
    O->>F: 阶段一：格式检查
    F-->>O: 格式报告
    O->>S: 阶段二：安全扫描
    S-->>O: 安全报告
    O->>L: 阶段三：逻辑审查
    L-->>O: 逻辑报告
    O-->>U: 汇总审查报告
```

---

## 四、模式三：条件分支Skill（Conditional Skill）

### 4.1 设计原则

条件Skill根据运行时上下文动态选择执行路径。关键在于**在Skill指令中明确分支条件**，让Claude理解"如果...则..."的逻辑。

### 4.2 实战：智能部署Skill

```bash
mkdir -p .claude/skills/smart-deploy
```

编写 `.claude/skills/smart-deploy/SKILL.md`：

```yaml
---
name: smart-deploy
description: 根据项目类型和目标环境智能选择部署策略
trigger: 当用户要求部署应用、发布到生产/预发环境时激活
tools:
  - Bash
  - Read
  - Glob
  - Grep
effort: 5
---

# 智能部署Skill

## 第一步：识别项目类型

检查项目根目录文件，判断技术栈：

| 检测文件 | 项目类型 | 部署目标候选 |
|----------|----------|-------------|
| `next.config.*` | Next.js | Vercel / Docker |
| `Dockerfile` | 容器化 | AWS ECS / GCP Cloud Run |
| `serverless.yml` | Serverless | AWS Lambda |
| `fly.toml` | Fly.io | Fly.io |
| `vercel.json` | Vercel | Vercel |

## 第二步：确认部署环境

根据用户指定或分支名推断环境：
- `main`/`master` 分支 → 生产环境（production）
- `staging`/`develop` 分支 → 预发环境（staging）
- 其他分支 → 开发环境（preview）

## 第三步：执行部署

### 分支A：Vercel部署（Next.js项目）
```bash
# 检查Vercel CLI
npx vercel --version
# 部署到对应环境
if [环境 = "production"]; then
  npx vercel --prod
else
  npx vercel
fi
```

### 分支B：Docker部署（容器化项目）
```bash
# 构建镜像
docker build -t <项目名>:<版本> .
# 推送镜像
docker push <仓库地址>/<项目名>:<版本>
# 更新部署
kubectl set image deployment/<项目名> <项目名>=<仓库地址>/<项目名>:<版本>
```

### 分支C：Serverless部署
```bash
npx serverless deploy --stage <环境名>
```

### 分支D：未知项目类型
提示用户选择部署方式，或提供手动部署步骤。

## 部署后验证

1. 检查部署URL是否可访问
2. 验证健康检查端点 `/health` 或 `/api/health`
3. 输出部署摘要

## 回滚策略

如果部署后验证失败：
1. 保留前一个版本的镜像/函数
2. 提示用户是否回滚
3. 执行回滚命令
```

---

## 五、模式四：渐进披露Skill（Progressive Disclosure）

### 5.1 设计原则

渐进披露是最核心的Skill设计哲学。Skill内容不应一次性全部暴露给Claude，而是按需加载——先给摘要，需要时再展开细节。这能显著减少上下文占用，提高响应质量。

### 5.2 渐进披露的三层结构

```mermaid
graph TB
    L1[第一层：Frontmatter摘要<br/>name + description] --> L2[第二层：Skill主体<br/>核心指令与流程]
    L2 --> L3[第三层：参考资源<br/>脚本/模板/示例]
    L1 -->|"Skill发现阶段"| Claude
    L2 -->|"Skill激活阶段"| Claude
    L3 -->|"执行时按需加载"| Claude
```

### 5.3 实战：三层渐进披露的数据库迁移Skill

```bash
mkdir -p .claude/skills/db-migration
```

**第一层**——Frontmatter（始终可见，控制在50字以内）：

```yaml
---
name: db-migration
description: 安全执行数据库Schema迁移，支持PostgreSQL/MySQL，含回滚策略
trigger: 当用户提及数据库迁移、schema变更、alter table时激活
tools:
  - Bash
  - Read
  - Edit
effort: 4
---
```

**第二层**——核心指令（激活时加载）：

```markdown
# 数据库迁移Skill

## 安全检查清单（每次必须执行）

1. **备份确认**：执行前确认是否已有数据库备份
2. **影响评估**：分析迁移SQL影响的表和行数
3. **回滚准备**：为每个迁移步骤生成对应的回滚SQL

## 迁移类型决策树

- 添加列 → 直接执行，风险低
- 修改列类型 → 先添加新列 → 迁移数据 → 删除旧列
- 删除列 → 先标记废弃 → 确认无引用 → 延迟删除
- 重命名表 → 先创建视图别名 → 迁移代码 → 删除视图
```

**第三层**——详细模板和脚本（按需加载）：

```markdown
## PostgreSQL迁移模板

<details>
<summary>点击展开完整迁移脚本模板</summary>

```sql
-- 迁移：添加用户头像字段
-- 创建时间：2026-05-26
-- 回滚SQL：ALTER TABLE users DROP COLUMN avatar_url;

BEGIN;
  ALTER TABLE users ADD COLUMN avatar_url VARCHAR(512);
  CREATE INDEX idx_users_avatar ON users(avatar_url) WHERE avatar_url IS NOT NULL;
COMMIT;
```

</details>

## 常见陷阱参考

<details>
<summary>点击展开常见迁移陷阱</summary>

1. **大表ALTER TABLE锁表**：使用 `pg_repack` 或分批迁移
2. **外键约束失败**：先迁移父表再迁移子表
3. **索引创建阻塞**：使用 `CREATE INDEX CONCURRENTLY`

</details>
```

### 5.4 渐进披露的效果对比

| 指标 | 无渐进披露 | 有渐进披露 |
|------|-----------|-----------|
| 初始上下文消耗 | ~2000 tokens | ~200 tokens |
| 激活时消耗 | ~2000 tokens | ~800 tokens |
| 按需加载 | 无 | ~1200 tokens（仅加载所需部分） |
| 响应延迟 | 较高（上下文冗长） | 较低（指令精准） |

---

## 六、模式五：错误边界Skill（Error Boundary Skill）

### 6.1 设计原则

错误边界Skill将容错逻辑封装在Skill内部，而不是让调用者处理。核心设计：

- **预检（Pre-check）**：执行前验证前置条件
- **降级（Degradation）**：主要方案失败时提供备选方案
- **报告（Reporting）**：结构化输出错误信息

### 6.2 实战：带错误边界的依赖安装Skill

```bash
mkdir -p .claude/skills/safe-install
```

编写 `.claude/skills/safe-install/SKILL.md`：

```yaml
---
name: safe-install
description: 安全安装npm/pip依赖，含版本锁定、漏洞检查、回滚机制
trigger: 当用户要求安装新的依赖包时激活
tools:
  - Bash
  - Read
  - Edit
effort: 3
---

# 安全依赖安装Skill

## 预检阶段

执行安装前，必须依次验证：

1. **包存在性检查**
   ```bash
   npm view <包名> version
   ```
   若404，建议替代包名并询问用户确认。

2. **许可证兼容性**
   ```bash
   npx license-checker --production | grep <包名>
   ```
   标记GPL类许可证，提示用户风险评估。

3. **包大小评估**
   ```bash
   npm view <包名> dist.unpackedSize
   ```
   若超过5MB，提示用户确认是否必要。

## 安装阶段

### 首选方案：精确版本安装
```bash
# 锁定具体版本，避免语义版本陷阱
npm install <包名>@<具体版本> --save-exact
```

### 降级方案A：宽松版本
如果首选方案因版本不存在失败：
```bash
npm install <包名> --save
```

### 降级方案B：替代包建议
如果包本身不可用，基于功能描述推荐替代品：
| 需求 | 首选 | 降级替代 |
|------|------|---------|
| HTTP客户端 | axios | node-fetch / got |
| 日期处理 | dayjs | date-fns / luxon |
| 表单验证 | zod | yup / joi |

## 验证阶段

安装后执行：
```bash
# 检查已知漏洞
npm audit
# 验证包可正常导入
node -e "require('<包名>'); console.log('✅ 导入成功')"
```

## 回滚机制

如果安装导致现有功能异常：
```bash
# 恢复package-lock.json
git checkout package-lock.json
# 重新安装原始依赖
npm ci
```

## 输出格式

```
📦 安装报告
─────────────
包名：<name>@<version>
大小：<size>
许可证：<license>
漏洞：<count>个
状态：✅ 安装成功 / ❌ 安装失败
回滚命令：npm uninstall <name>
```
```

---

## 七、五大模式的完整Skill体系架构

下面展示如何将五种模式组合成一个完整的开发工作流Skill体系：

```mermaid
graph TB
    subgraph "编排层（Orchestrator）"
        ORC[dev-workflow<br/>开发工作流编排器]
    end

    subgraph "业务层（Conditional + Progressive）"
        DEPLOY[smart-deploy<br/>智能部署]
        REVIEW[code-review-orchestrator<br/>代码审查编排器]
        MIGRATE[db-migration<br/>数据库迁移]
    end

    subgraph "基础层（Atomic + Error Boundary）"
        FMT[code-formatter<br/>格式化]
        SEC[security-scanner<br/>安全扫描]
        INSTALL[safe-install<br/>安全安装]
        LOGIC[logic-reviewer<br/>逻辑审查]
    end

    ORC -->|"开发完成"| REVIEW
    ORC -->|"审查通过"| DEPLOY
    ORC -->|"需要迁移"| MIGRATE

    REVIEW --> FMT
    REVIEW --> SEC
    REVIEW --> LOGIC

    DEPLOY -->|"依赖安装"| INSTALL
    MIGRATE -->|"安全检查"| SEC

    style ORC fill:#6366f1,color:#fff
    style DEPLOY fill:#8b5cf6,color:#fff
    style REVIEW fill:#8b5cf6,color:#fff
    style MIGRATE fill:#8b5cf6,color:#fff
    style FMT fill:#06b6d4,color:#fff
    style SEC fill:#06b6d4,color:#fff
    style INSTALL fill:#06b6d4,color:#fff
    style LOGIC fill:#06b6d4,color:#fff
```

---

## 八、SKILL.md Frontmatter完整字段速查

以下是目前支持的YAML Frontmatter字段及其用途：

```yaml
---
# === 必需字段 ===
name: string              # Skill唯一标识，用于发现和引用
description: string       # 一句话功能描述，出现在Skill列表中

# === 触发控制 ===
trigger: string           # 激活条件描述，告诉Claude何时使用此Skill

# === 工具控制 ===
tools:                    # 限制Skill可使用的工具列表
  - Bash
  - Read
  - Edit
  - Write
  - Glob
  - Grep
  - Task

# === 子Agent委托 ===
subagents:                # 声明此Skill依赖的子Skill
  - skill-name-a
  - skill-name-b

# === 模型控制 ===
model: sonnet | opus | haiku  # 指定Skill使用的模型
effort: 1-5               # 思考努力级别，5为最深入

# === 高级控制 ===
disable-model-invocation: boolean  # 禁止自动调用（用于手动触发）
max_tokens: number        # 限制最大token输出
---
```

### 字段选择决策树

```mermaid
graph LR
    A[创建Skill] --> B{需要限制工具？}
    B -->|是| C[添加 tools 字段]
    B -->|否| D[使用默认全部工具]
    C --> E{需要子Skill？}
    D --> E
    E -->|是| F[添加 subagents 字段]
    E -->|否| G{需要特定模型？}
    F --> G
    G -->|是| H[添加 model 字段]
    G -->|否| I[使用默认模型]
    H --> J[完成配置]
    I --> J
```

---

## 九、实战案例：构建完整的代码质量守护Skill体系

本节将上述五种模式整合为一个实际可用的项目。目标是在任何Node.js项目中，通过一个命令触发完整的质量检查流程。

### 步骤1：创建基础层原子Skill

```bash
# 创建三个原子Skill
mkdir -p .claude/skills/{lint-checker,type-checker,test-runner}
```

**lint-checker/SKILL.md**：

```yaml
---
name: lint-checker
description: 执行ESLint检查并输出结构化报告
trigger: 当需要检查代码质量、运行lint时激活
tools: [Bash, Read, Glob, Grep]
effort: 2
---

# Lint检查Skill

## 执行步骤

1. 检测ESLint配置文件位置
2. 对指定路径执行检查：
   ```bash
   npx eslint "<目标路径>" --format json 2>/dev/null
   ```
3. 解析JSON输出，统计错误和警告数量
4. 按文件分组输出结果

## 输出格式

```
📊 Lint报告
错误：X个 | 警告：Y个 | 可忽略：Z个

❌ src/auth.ts (3 errors)
  - Line 12: 'password' is defined but never used
  - Line 45: Unexpected any. Specify a different type
  - Line 67: Missing return type annotation
```
```

**type-checker/SKILL.md**：

```yaml
---
name: type-checker
description: 执行TypeScript类型检查并报告类型错误
trigger: 当需要检查类型安全性、运行tsc时激活
tools: [Bash, Read]
effort: 2
---

# 类型检查Skill

## 执行步骤

1. 检测 tsconfig.json 位置
2. 运行类型检查：
   ```bash
   npx tsc --noEmit --pretty 2>&1
   ```
3. 解析输出，按错误码分类
4. 标注可快速修复的问题（如缺失类型注解）

## 输出格式

```
🔍 类型检查报告
通过：❌ | 错误数：X

📁 src/api/handler.ts
  TS2322: Type 'string' is not assignable to type 'number' (Line 34)
  TS2304: Cannot find name 'Response' (Line 56)
```
```

**test-runner/SKILL.md**：

```yaml
---
name: test-runner
description: 运行项目测试套件并分析测试结果
trigger: 当需要运行测试、检查测试覆盖率时激活
tools: [Bash, Read, Glob]
effort: 3
---

# 测试运行Skill

## 执行步骤

1. 检测测试框架（Jest / Vitest / Mocha）
2. 运行测试：
   ```bash
   # Jest/Vitest
   npx jest --coverage --json 2>/dev/null
   # 或
   npx vitest run --coverage --reporter=json 2>/dev/null
   ```
3. 解析测试结果
4. 计算覆盖率摘要

## 输出格式

```
🧪 测试报告
套件：X个通过 / Y个失败 / Z个总计
用例：A个通过 / B个失败 / C个跳过
覆盖率：XX%

❌ 失败用例：
  ● auth.test.ts > login > should reject expired tokens
    Expected: 401
    Received: 200
```
```

### 步骤2：创建编排器Skill

```bash
mkdir -p .claude/skills/quality-gate
```

编写 `.claude/skills/quality-gate/SKILL.md`：

```yaml
---
name: quality-gate
description: 编排代码质量门禁，串联lint、类型检查、测试三道关卡
trigger: 当用户要求质量检查、运行CI、提交前检查时激活
tools: [Task, Bash, Read]
subagents:
  - lint-checker
  - type-checker
  - test-runner
effort: 5
---

# 质量门禁编排器

## 编排流程

### 第一关：Lint检查
委托 `lint-checker` Skill执行代码风格检查。
- 如果错误数 > 0：标记为 ❌，但继续下一关
- 收集错误列表

### 第二关：类型检查
委托 `type-checker` Skill执行类型安全检查。
- 如果有类型错误：标记为 ❌，但继续下一关
- 收集错误列表

### 第三关：测试运行
委托 `test-runner` Skill执行测试套件。
- 如果有失败用例：标记为 ❌
- 收集失败详情

## 门禁判定

| 关卡 | 权重 | 通过条件 |
|------|------|---------|
| Lint | 30% | 错误数 = 0 |
| 类型 | 30% | 错误数 = 0 |
| 测试 | 40% | 全部通过 |

### 判定规则
- 三关全部通过 → ✅ 质量门禁通过
- 任一关失败 → ❌ 质量门禁未通过
- 输出修复优先级列表

## 最终输出

```markdown
# 🚪 质量门禁报告

| 关卡 | 状态 | 详情 |
|------|------|------|
| Lint | ✅/❌ | X错误 Y警告 |
| 类型 | ✅/❌ | X错误 |
| 测试 | ✅/❌ | X失败 Y通过 |

**结论：✅ 通过 / ❌ 未通过**

### 🔧 修复优先级
1. [最高优先级修复项]
2. [次高优先级修复项]
```

## 错误处理
- 某关工具不可用时（如无ESLint配置），跳过该关并标注"跳过"
- 不因单关失败而中止后续检查
```

### 步骤3：验证完整体系

```bash
# 验证Skill已被发现
claude skills list

# 预期输出应包含：
# quality-gate      - 编排代码质量门禁
# lint-checker      - 执行ESLint检查
# type-checker      - 执行TypeScript类型检查
# test-runner       - 运行测试套件
# code-formatter    - 代码格式化
```

在Claude Code中触发质量门禁：

```bash
claude "请对 src/ 目录执行质量门禁检查"
```

预期Claude的行为：
1. 识别到 `quality-gate` Skill匹配当前意图
2. 按顺序激活三个子Skill
3. 收集各关结果
4. 输出汇总报告

---

## 十、常见问题与解决方案

### Q1：Skill之间如何传递数据？

Skill之间不直接传递数据。编排器通过读取子Skill的输出（文件、Bash输出）来获取结果。推荐方式：

```
子Skill → 写入临时文件/输出到stdout → 编排器读取
```

### Q2：Skill应该放在什么位置？

| 位置 | 作用域 | 适用场景 |
|------|--------|---------|
| `.claude/skills/` | 当前项目 | 项目特定Skill |
| `~/.claude/skills/` | 全局用户 | 个人通用Skill |
| npm包（`claude-skill-*`） | 可分享 | 团队/社区共享 |

### Q3：如何调试Skill不触发的问题？

```bash
# 方法1：检查Skill发现列表
claude skills list

# 方法2：手动指定Skill
claude --skill code-formatter "格式化 src/"

# 方法3：在trigger字段中使用更具体的关键词
# 原来可能太宽泛的trigger：
#   trigger: 当需要格式化时激活
# 改为更具体的：
#   trigger: 当用户要求格式化代码、修复lint、运行prettier时激活
```

### Q4：编排器Skill和普通Skill的区别是什么？

| 维度 | 原子Skill | 编排器Skill |
|------|-----------|------------|
| 工具使用 | 直接操作 | 主要用Task委托 |
| subagents字段 | 无 | 列出依赖的子Skill |
| 指令内容 | 具体操作步骤 | 流程协调逻辑 |
| 上下文消耗 | 低 | 中等（自身）+ 子Skill |
| 可复用性 | 高（单一职责） | 中等（流程特定） |

### Q5：如何控制Skill的上下文消耗？

三个关键策略：

1. **精简description**：控制在30字以内
2. **使用渐进披露**：详细内容用折叠块或外部文件
3. **限制tools字段**：只声明实际需要的工具

```yaml
# ❌ 过于详细的description
description: 这个Skill帮助开发者执行代码格式化，包括JavaScript、TypeScript、CSS、HTML等多种文件类型，使用Prettier和ESLint...

# ✅ 精简的description
description: 使用Prettier和ESLint自动格式化代码
```

---

## 十一、设计模式速查卡

| 模式 | 核心原则 | 适用场景 | effort推荐 |
|------|---------|---------|-----------|
| 原子Skill | 单一职责，一句话描述 | 可独立复用的单一功能 | 1-3 |
| 编排器Skill | 声明式流程，委托执行 | 多步骤工作流协调 | 4-5 |
| 条件分支 | 运行时动态选择路径 | 需要根据环境/类型适配的场景 | 3-5 |
| 渐进披露 | 按需加载，减少上下文 | 指令内容较长的复杂Skill | 2-4 |
| 错误边界 | 预检-降级-报告 | 涉及外部依赖或不可控操作 | 3-4 |

---

## 延伸阅读

- [Extend Claude with skills — Claude Code官方文档](https://code.claude.com/docs/en/skills)：Skill的官方技术规范和API参考
- [The Complete Guide to Building Skills for Claude — Anthropic](https://claude.com/blog/complete-guide-to-building-skills-for-claude)：Anthropic发布的32页Skill构建完整指南，涵盖规划、结构化和优化
- [Anthropic's 33-Page Official Guide Distilled — 5 Claude Skills Design Patterns](https://smartscope.blog/en/generative-ai/claude/claude-skills-design-patterns-official-guide/)：从Anthropic官方指南中提炼的五大设计模式详解，含调试与测试方法论
- [SKILL.md Specification — DeepWiki](https://deepwiki.com/anthropics/skills/2.2-skill.md-format-specification)：SKILL.md格式的完整技术规范，涵盖YAML字段、Markdown结构和命名约定
- [Agent Orchestration — Multi-Skill Coordination Protocol](https://alirezarezvani.github.io/claude-skills/orchestration/)：多Skill协调协议的社区实践，包含跨域编排模式

---

## 参考来源

1. [The Complete Guide to Building Skills for Claude — Anthropic Official](https://claude.com/blog/complete-guide-to-building-skills-for-claude) — Anthropic发布的32页官方Skill构建指南，本文五种设计模式的核心来源
2. [SKILL.md Format Specification — anthropics/skills](https://deepwiki.com/anthropics/skills/2.2-skill.md-format-specification) — SKILL.md格式的完整规范文档，包含所有YAML Frontmatter字段定义
3. [5 Production Patterns From Anthropic's Claude Skills Guide — claw0x](https://claw0x.com/blog/claude-skills-5-production-patterns-with-code) — 对Anthropic五大设计模式的工程化实现，含可运行代码示例
4. [Architecture and Design Patterns — levnikolaevich/claude-code-skills](https://deepwiki.com/levnikolaevich/claude-code-skills/2-architecture-and-design-patterns) — Claude Code Skill的架构设计模式深度分析，涵盖组合与委托模式
5. [Agent Skills in the SDK — Claude Code Docs](https://code.claude.com/docs/en/agent-sdk/skills) — Claude Code SDK中Agent Skill的官方技术参考

---

## 训练营适用性评估

| 维度 | 评估 |
|------|------|
| 适合训练营类型 | AI辅助开发训练营（中高级班）、DevOps自动化训练营 |
| 教学时长 | 3-4小时（含动手实操） |
| 学员基础要求 | 熟悉命令行、有Claude Code使用经验、了解基本软件设计模式 |
| 实操比重 | 70%实操 + 30%理论 |
| 分组建议 | 2-3人一组，每组选择不同的编排器场景（如：部署编排、测试编排、文档编排） |
| 考核方式 | 每组提交一个可运行的编排器Skill + 3个以上原子子Skill，并通过质量验证 |

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)