导语
"我明明教了 AI 怎么做，它偏不按套路来。"如果你写过 Agent Skill，大概率经历过这种抓狂时刻——让它写文档，每次格式都不一样；让它做 Code Review，说了一堆但没有重点；让它规划项目，需求还没搞清就开始输出方案。问题不在 AI 笨，而在于你给它的"说明书"缺了结构。今天聊 5 种经过实战验证的 Skill 设计模式，每种解决一类"AI 不听话"的问题。
正文
1. 格式已经不是问题，内容设计才是
上一篇文章我们介绍了 Agent Skills 的基本概念——它是 AI 的"活的员工手册"，通过渐进式披露（Progressive Disclosure，按需加载）来省 Token、提专注度。
但当你真正开始写 Skill 的时候，会发现一个尴尬的事：格式规范已经很清楚了（YAML 怎么写、目录怎么放），30 多个 Agent 工具达成了标准化。可到了"里面写什么"这一步，完全没有指导。
打个比方：菜谱的格式都是"材料 + 步骤"，但炒菜和炖汤的做法完全不同。你不能用炖汤的思路去炒菜，即使它们写在同样格式的菜谱上。
一个教 AI 写 FastAPI 代码的 Skill，和一个让 AI 跑文档生成流水线的 Skill，虽然外壳一样，但内部逻辑天差地别。内容设计（content design）才是决定 Skill 好不好用的关键。
社区通过系统研究 Anthropic、Google ADK、Vercel 等团队的 Skill 仓库，提炼出了 5 种反复出现的设计模式。我们先用一张表做全局预览，再逐个拆解。
2. 五种模式速查
| 模式 | 一句话概括 | 典型场景 | 关键目录 |
|---|---|---|---|
| Tool Wrapper | 按需注入框架知识 | 内部 SDK、编码规范 | references/ |
| Generator | 模板填空，统一输出 | 文档生成、commit message | assets/ + references/ |
| Reviewer | 清单打分，分级输出 | Code Review、安全审计 | references/ |
| Inversion | 先采访，再干活 | 项目规划、需求分析 | 无特殊目录 |
| Pipeline | 多步骤 + 检查点 | 文档流水线、质量检查 | 所有目录按需 |
3. 对症下药：每种模式解决什么问题
"AI 用我的框架总写错代码" → Tool Wrapper（工具封装）
AI 的训练数据是通用的。它可能认识 FastAPI，但不认识你公司上周刚发布的 billing-lib v3.2。Tool Wrapper 把框架约定、API 文档、常见坑点打包进 references/ 目录。SKILL.md 只做"导航"——告诉 AI 什么时候去读哪份文档，而不是把文档内容硬塞进指令里。
设计要点：
- 延迟加载：让 AI 在写代码时才通过 bash 读取
references/conventions.md - 关键词触发：在 description 中列出框架名、库名等触发词
- 双场景指令：分别写清"Review 代码时怎么做"和"写代码时怎么做"
这是最容易落地的模式。如果你的团队有一份内部编码规范，5 分钟就能包成一个 Tool Wrapper Skill。
"每次输出的文档格式都不一样" → Generator（生成器）
如果你苦恼 AI 每次生成的文档结构不一致，Generator 的解题思路是：给 AI 一张填空卷，而不是一道作文题。
执行流程固定为四步：
- 读取
references/style-guide.md了解语气和排版规则 - 读取
assets/report-template.md获得输出结构 - 向用户询问缺失信息（主题、数据、目标受众）
- 按模板填写——模板中的每个章节都不能少
关键在于 SKILL.md 本身不包含模板内容和风格规则，它只负责协调这些资源的读取，并强制 AI 一步一步执行。适用场景：API 文档、标准化 commit message、项目脚手架。
"Code Review 只说'代码不错'，没有干货" → Reviewer（审阅者）
问题出在哪？AI 不知道该按什么标准打分。Reviewer 的聪明之处在于"分离"——把评审标准从指令中独立出来，放进单独的 references/review-checklist.md。SKILL.md 只写通用流程：加载清单 → 逐条对照代码 → 标注行号和严重程度（error > warning > info）→ 分组输出。
这种分离带来一个额外好处：清单可以热替换。把 Python 代码规范换成 OWASP 安全清单，框架不用改，就得到了一个全新的安全审计 Skill。同一套"骨架"，换一份"标准"就能应对完全不同的评审场景。
"需求没搞清就开始瞎做" → Inversion（反转）
AI 有个天性：给它一个模糊指令，它不会说"我需要更多信息"，而是直接猜一个答案出来。这在项目规划和架构设计中尤其致命。
Inversion 通过"闸门指令"强制打断这种行为。核心设计有三个要素：
- 分阶段提问：Phase 1 问业务问题、Phase 2 问技术约束、Phase 3 才综合方案
- 硬性闸门：明确写 "DO NOT start building until all phases are complete"
- 等待回答：每个问题问完必须等用户回答，不能自己跳过
AI 从"猜测 → 执行"变成了"采访 → 理解 → 执行"，输出质量大幅提升。
"偷偷跳过关键步骤" → Pipeline（流水线）
Pipeline 是五种模式里最"重"也最严格的。它把工作流拆成多个步骤，每步之间设置"闸门条件"。比如文档生成流水线：解析代码接口 → 生成 docstring（用户确认后才能进入下一步）→ 组装文档 → 质量检查。
设计上还有个精妙之处：每步只加载那一步需要的参考文件。第二步才加载 docstring 风格指南，第三步才加载文档模板。上下文窗口始终保持干净，不会被无关内容稀释。
4. 进阶：模式可以组合
这 5 种模式不是互斥的，而是像乐高积木——可以自由拼装。
实际组合案例：
- Generator + Inversion：先用 Inversion 采集变量（"报告类型？读者是谁？"），再用 Generator 填模板
- Pipeline + Reviewer：流水线最后一步嵌入 Reviewer 自检，用清单验证输出质量
- Tool Wrapper + Pipeline：Pipeline 某个步骤需要特定库知识，就在那步触发 Tool Wrapper
Anthropic 在构建 Claude Code 的 Skills 时总结了一条经验：最好的 Skill 能清晰落在一个主模式里，横跨多个模式反而容易让人困惑。建议做法是：先确定主模式，再在关键步骤嵌入辅助模式。
5. 选择合适的 agent skills 模式
总结
5 种设计模式不是教条，而是社区从大量实践中提炼出来的"起跑线"。Tool Wrapper 注入知识、Generator 统一输出、Reviewer 标准化评审、Inversion 先问后做、Pipeline 严格编排——每种模式回答的是不同层面的问题。选对模式，就像给 AI 装上了"做事的骨架"——它知道什么时候该查资料、什么时候该问你、什么时候该动手。
别再把所有指令一股脑塞进系统提示词了。把工作流拆开，选对结构化模式，你的 AI 会靠谱得多。
行动建议
- 今天就动手：选一个你正在用但效果不理想的 Skill，对照速查表判断它属于哪种模式，用对应的设计原则重构它
- 新手起步：从 Tool Wrapper 开始——把团队的一份编码规范打包成 Skill，5 分钟就能搞定，立刻感受效果
我是草捏子，一只热爱技术和生活的草鱼，我们下期见！
