5.1 七种设计模式——从检查清单到子代理编排
📋 多工具适用说明
本节的设计模式是通用概念，适用于所有 AI 编程工具：
- 检查清单、工作流编排、知识库、模板生成器、护栏模式——所有工具都可实现
- 子代理编排、动态注入——概念通用，实现方式各异（Claude Code 特有语法）
示例代码以 Claude Code 语法展示，但模式本身可迁移到 Cursor、Windsurf 等工具。
引言
写了几十个技能包之后，小王发现有些模式反复出现。他开始给它们起名字：检查清单、工作流编排、知识库……
给模式命名不是为了炫技，而是为了更快地设计新技能包。 当你识别出"这是一个检查清单模式"，你就知道该用有序步骤和"失败则停止"语义。
七种模式概览
检查清单
有序步骤 + 失败停止
工作流编排
条件分支 + 人工确认
知识库
纯信息 + 自动加载
模板生成器
固定输出格式
护栏
硬性禁止 + 工具限制
子代理编排
隔离执行 + 只返回摘要
动态注入
实时数据预处理
模式一：检查清单（Checklist）
编码确定性步骤，必须按序执行，不可跳步。
markdown
---
name: verify
description: 提交代码前验证变更
disable-model-invocation: true
---
按顺序执行：
1. 运行 `npm run lint`（失败则停止）
2. 运行 `npm run type-check`（失败则停止）
3. 运行 `npm run test`（失败则停止）
全部通过则输出 ✅ 验证通过。适用：代码审查、发布流程、CI 门控
模式二：工作流编排（Workflow Orchestrator）
多步工作流，步骤间有条件分支，需要人工确认。
markdown
---
name: maintainer
description: 项目维护助手
---
1. 检查当前项目状态
2. 报告状态摘要
3. 根据条件推荐操作：
- 有卡住的 PR？→ 建议 /review-pr
- 有未分类 Issue？→ 建议 /triage-issue
4. 等待用户选择适用：项目管理、需要人工确认的多步操作
模式三：知识库（Knowledge Base）
注入领域知识，Claude 在相关任务中参考使用。纯信息，无操作。
markdown
---
name: feature-flags
description: 当 feature flag 测试失败或需要更新 flag 时使用
user-invocable: false
---
| 文件 | 用途 |
|------|------|
| flags.js | 默认 flag |
| flags.www.js | www 渠道覆盖 |适用：API 规范、配置映射、领域知识
关键：user-invocable: false——不需要人手动调用，Claude 自动加载为背景知识
模式四：模板生成器（Template Generator）
指导 Claude 按特定格式生成输出。
markdown
---
name: wiki-query
description: 研究并生成 Wiki 综合页面
---
生成页面格式：
---
title: "问题标题"
type: synthesis
tags: []
---
（页面内容……）适用：文档生成、标准格式输出
模式五：护栏（Guard Rail）
约束 Claude 的行为——定义什么不能做。
markdown
---
name: triage-issue
description: 分流 GitHub Issue
---
IMPORTANT：不要在 Issue 上发布任何评论或消息。
只使用 ./scripts/gh.sh label list 中的标签——绝不创建或猜测标签名。适用：安全约束、合规要求
注意：如果规则必须每次成立，用 Hook 而非技能包。技能包是建议，Hook 是法律。
模式六：子代理编排（Subagent Orchestrator）
委派工作给子代理，实现并行执行或上下文隔离。
markdown
---
name: dedupe
description: 检查 GitHub Issue 重复
context: fork
agent: general-purpose
---
1. 查看目标 Issue 详情
2. 搜索代码库中可能的重复
3. 过滤和排序结果
4. 返回重复报告适用：大型研究任务、需要并行处理的工作
模式七：动态注入（Dynamic Context Injection）
用 !command`` 预注入实时数据。
markdown
---
name: commit-push-pr
description: 提交变更并创建 PR
allowed-tools: Bash(git *), Bash(gh pr create *)
---
## 上下文
- 当前状态：!`git status`
- 当前 diff：!`git diff HEAD`
- 当前分支：!`git branch --show-current`
基于以上变更创建提交和 PR。适用：需要实时项目状态的任何技能包
模式速查表
| 模式 | 核心特征 | 关键配置 |
|---|---|---|
| 检查清单 | 有序步骤 + 失败停止 | disable-model-invocation: true |
| 工作流编排 | 条件分支 + 人工确认 | 按需 |
| 知识库 | 纯信息 + 自动加载 | user-invocable: false |
| 模板生成 | 固定输出格式 | 辅助模板文件 |
| 护栏 | 硬性禁止 | allowed-tools 限制 |
| 子代理编排 | 隔离执行 | context: fork |
| 动态注入 | 实时数据 | !command`` |
本节小结
📌 本节核心要点
- 七种模式覆盖了绝大多数技能包场景
- 给模式命名是为了更快设计——识别模式后直接套用最佳配置
- 知识库用
user-invocable: false——自动加载为背景知识 - 护栏 vs Hook：技能包是建议，Hook 是强制
- 动态注入是最常用的增强——几乎所有技能包都可以加
思考题
- 你日常工作中最常用的操作属于哪种模式？如果写成技能包，你会怎么设计？
- 检查清单模式和工作流编排模式的区别是什么？什么时候用哪个？
- 能否在一个技能包中组合多种模式？举个例子。
下一节预告
知道了怎么写好，还要知道怎么写坏。下一节讲七种反模式——这些是比"不知道怎么写"更危险的"以为自己写对了"。