规范 · 方法论 · 设计模式

Skill 不是 Prompt——
它是结构化的行为设计。

围绕任务、工具、流程、输出边界的可复用提示词增强包。 这页面把分散在 Anthropic 官方仓库、Superpowers 框架和 Google ADK 团队总结里的内容整合起来—— 读完之后你会知道什么时候该用 Skill-Creator 的工程化套路,什么时候 Writing-Skills 的 TDD 思路更合适, 以及面对一个新需求该选哪种设计模式。

01

规范标准

SKILL.md 文件结构、YAML frontmatter 字段、三层渐进式加载机制、命名与触发约束。

agentskills.io
02

构建方法论

Skill-Creator 的工程化生命周期 vs Writing-Skills 的 TDD 红绿重构循环——两套思路的取舍。

Anthropic / Superpowers
03

设计模式

Tool Wrapper · Generator · Reviewer · Inversion · Pipeline——五种内部结构原型与组合策略。

Google ADK
Chapter 01

什么是Agent Skill

在 AI Agent 生态中,Skill 是一种可复用的提示词增强包,通过渐进式加载 机制为 Agent 注入领域知识与工作流。2025 年 12 月 Anthropic 把它作为开放标准发布,目前 已被 33+ 个 Agent 产品采纳——Claude Code、OpenAI Codex、Cursor、Gemini CLI、Kiro 等。

最小形态

一个 Skill 的最小形态只需要一个文件:

skill-name/
├── SKILL.md # 必需:YAML 元数据 + Markdown 指令
├── scripts/ # 可选:可执行脚本
├── references/ # 可选:按需加载的参考文档
└── assets/ # 可选:模板、资源文件

SKILL.md 由两部分构成:YAML frontmatter(元数据,告诉 Agent 这是什么、何时用)和 Markdown body(指令正文,告诉 Agent 怎么做)。

SKILL.md · 最小示例 --- name: pdf-processing description: Extract PDF text, fill forms, merge files. Use when handling PDFs. license: Apache-2.0 metadata: author: example-org version: "1.0" --- # PDF Processing ## When to use this skill Use this skill when the user needs to work with PDF files... ## How to extract text 1. Use pdfplumber for text extraction...
Chapter 02 · 核心机制

三层渐进式加载

这是 Skills 规范最精妙的设计——借鉴 UI/UX 领域的渐进式信息披露策略。 即使安装了 20 个 Skill,初始加载也仅 1000-2000 tokens。 相比单体式提示词,上下文使用量减少约 90%。下面这个交互演示了 Agent 如何按需逐层展开。

L1 · 目录层 ~ 50–100 tokens / Skill
name + description
会话启动时自动加载。Agent 只知道"有哪些 Skill 可用",以 XML 格式注入系统提示词。
L2 · 指令层 建议 < 5000 tokens
完整 SKILL.md body
用户任务匹配某个 Skill 的描述时,模型自主判断加载完整指令——这就是 Model-driven Activation。
L3 · 资源层 视文件大小
scripts/ · references/ · assets/
指令引用时按需加载。例如:"当 API 返回非 200 时,读取 references/api-errors.md"
点击「演示」查看 L1 → L2 → L3 的逐层激活

关键价值在于分层激活的时机判断:Skill 的触发完全依赖 description 字段, 由模型自主判断当前任务是否匹配,而非关键词硬编码。这意味着写好 description 比写好指令主体更关键。

Chapter 03 · 规范

SKILL.md 的字段约束

YAML frontmatter 有两个必填字段、四个可选字段。命名规则比想象中严格——下面是完整的字段表与 最容易踩的坑。

字段
必填
说明与约束
name
必填
最多 64 字符。仅小写字母、数字、连字符。不能以连字符开头/结尾,不能连续连字符,必须与所在文件夹名一致
description
必填
最多 1024 字符。描述功能与适用场景。这是唯一的触发凭据,应该包含帮助 Agent 识别相关任务的关键词。
license
可选
许可证名称或指向许可证文件的引用。
compatibility
可选
最多 500 字符。说明运行环境或依赖。
metadata
可选
键值对映射,存储规范之外的自定义属性(如 author、version)。
allowed-tools
可选
空格分隔的预授权工具列表(实验性功能)。

name 字段——容易踩的坑

合法
name: pdf-processing
name: data-analysis
name: code-review
非法
name: PDF-Processing    # 不允许大写
name: -pdf              # 不能以连字符开头
name: pdf--processing   # 不允许连续连字符

description——决定触发率的字段

触发完全依赖 description,不要把它当成"装饰说明"来写。三个写作要点: 使用祈使语气(Use this skill when...)、聚焦用户意图(而非 Skill 内部机制)、 包含可能的关键触发词

好的写法
Analyze CSV and tabular data files —
compute summary statistics, add derived
columns, generate charts, and clean
messy data. Use this skill when the
user has a CSV, TSV, or Excel file and
wants to explore, transform, or
visualize the data, even if they don't
explicitly mention "CSV" or "analysis."
覆盖了用户可能的各种表述,包含具体动作动词,给出明确的触发场景。
差的写法
Helps with PDFs.
过于抽象,没有触发词,没有场景描述。Agent 几乎不可能在合适的时刻激活它。

三个可选目录的分工

三个目录承担不同角色——记住一条:每个文件保持聚焦,因为 Agent 是按需加载的,文件越小消耗越少。

scripts/
可执行代码。脚本应该自包含或明确说明依赖,包含有用的错误信息,妥善处理边界。常见 Python、Bash、JavaScript。
references/
补充文档。如 REFERENCE.md(详细技术参考)、FORMS.md(表单结构)、特定领域文档(finance.md、legal.md)。
assets/
静态资源——文档模板、配置模板、示意图、查找表、Schema 定义等。
Chapter 04 · 方法论 A

Skill-Creator——把 ML 工程搬进 Prompt Engineering

Anthropic 官方"用来创建 Skill 的 Skill"。设计哲学一句话:像做机器学习一样做 Prompt Engineering—— 有训练集、测试集、评估指标、迭代循环、防过拟合机制。 它把软件工程中的 CI/CD、A/B 测试、性能基准这套实践完整移植过来了。

三个核心思想

泛化而非过拟合
Skill 要面对无数种 prompt。如果只为测试用例做针对性修改,skill 就废了。遇到顽固问题,换隐喻,而不是堆死板约束。
解释"为什么"而非堆"必须"
今天的 LLM 有良好的心智理论。与其写满 ALWAYS / NEVER,不如解释清楚为什么某件事重要。
提取重复模式
如果所有测试中 Agent 都独立写了类似辅助脚本(比如都写 create_docx.py),这是强信号——把它放进 scripts/ 让 skill 直接调用。
自举式架构
用 Skill 框架管理 Skill 生命周期。三个专业化子 Agent + 7 种 JSON Schema + 浏览器评审界面,闭环。

六阶段生命周期

点击下面任一阶段查看详情。注意:3 → 5 是一个迭代回路,不是线性过程

01
需求捕获
理解意图、明确触发场景
02
编写 Skill
YAML 元数据 + 指令主体
03
测试执行
A/B 并行子 Agent
04
评估评审
Grader + Eval Viewer
05
迭代改进
分析反馈,泛化方向
06
优化发布
Description 调优 + 打包
需求捕获
通过对话明确:触发场景("review my code"、"check this PR"等用户表述)、 输出格式(结构化报告?JSON?文档?)、是否客观可验证(决定能否量化测试)。 客观可验证 vs 主观创意型决定后续测试策略——前者用断言,后者用盲比较。
阶段 3 → 5 是迭代回路。每一轮迭代都会创建新的 iteration 目录,保留完整的版本追踪(history.json)。

三个专业化子 Agent

各司其职,形成完整评估链。最精妙的是 Grader 的"自我批评"机制——它不仅打分,还质疑断言本身的合理性。

评分者
Grader
8 步流程:读 transcript → 检查输出文件 → 评估断言 → 提取隐含声明 → 读笔记 → 评价评估本身 → 写结果 → 读指标。关键不是打分,是自我批评。
"对一个薄弱断言给出'通过',比毫无用处更糟——它会制造虚假信心。"
盲比较者
Comparator
借鉴医学双盲实验。Comparator 只看 A 和 B,不知道哪个来自 with_skill / without_skill。双维度评分:内容(正确性、完整性、准确性)+ 结构(组织性、格式、可用性)。
"去偏见化的核心是不让评估者知道源信息。"
分析者
Analyzer
双重角色。事后分析:揭盲后对比指令差异和执行模式,生成按优先级的改进建议(high / medium / low)。基准分析:找聚合数据中的隐藏模式——哪些断言一直 100% 通过?哪些方差大?
"统计聚合层面的洞察,往往比单次评测更有价值。"

JSON 数据流——7 种 Schema 的级联管道

references/schemas.md 定义了 7 种 JSON 结构,形成完整的数据管道。每一步的输出是下一步的输入。

1evals.json
测试定义(prompt + expectations)。这是整个流程的起点。
2timing.json
运行计时。来自子 Agent 的完成通知。
3metrics.json
执行指标(工具调用次数、文件数、token 用量等)。
4grading.json
评分结果(断言通过/失败 + 证据)。Grader 的产出。
5benchmark.json
聚合基准(mean ± stddev,with_skill vs without_skill 的 delta 对比)。
6comparison.json
盲比较结果(A/B 评分 + 赢家)。Comparator 的产出。
7analysis.json
事后分析(改进建议 + 执行模式洞察)。Analyzer 的产出。
+history.json
版本追踪(迭代历史 + 当前最佳)。贯穿整个生命周期。

客观评价

优势

  • 方法论完整——把 ML 工程实践引入 Prompt Engineering,目前最系统化的 Skill 开发框架
  • 评估体系严谨——三 Agent 协作 + 量化基准,远超"凭感觉改 Prompt"的传统方式
  • 零依赖可移植——纯 Python stdlib + claude CLI,任何环境都能跑
  • 人机协作设计——Eval Viewer 让人判断质量,自动化处理重复工作
  • 自举式架构——用 Skill 管理 Skill 生命周期,本身就是范例

已知局限

  • Token 消耗极高——20 个评估 × 3 次 = 60 个 Opus 子会话,单轮可消耗 5 小时配额的 ~69%(GitHub Issue #514)
  • 流程冗长——多次确认 + 浏览器评审,简单 Skill 的开销远超价值
  • 子任务并发管理复杂——3 个测试就有 10 个子 Agent,多轮线性增长
  • 对操作型 Skill 优化无效——某些 Skill 触发率始终 0%,与 description 质量无关
  • Skill 膨胀风险——5KB Skill 可能膨胀到 50KB,违背"保持精简"
  • 学习曲线陡峭——三层加载、7 种 Schema、子 Agent 工作原理...对非技术用户认知负担高
Chapter 05 · 方法论 B

Writing-Skills——把 TDD搬进 Skill 开发

Superpowers 框架里的元技能。它和 Skill-Creator 目标相似但方法论截然不同—— 不是统计基准,是 RED → GREEN → REFACTOR 的测试驱动循环。核心理念:测试先行、系统化优于随机化、 复杂度缩减、证据优于声明。

RED-GREEN-REFACTOR 循环

这是 TDD 的经典三段,搬到 Skill 开发场景里。

RED · 基线
让它失败
不带 Skill 跑压力场景
时间压力 + 沉没成本 + 疲劳组合施压。记录 Agent 的违规行为和合理化借口。"我已经手动测过了"、"先写后测也行"——这些就是后续要堵的漏洞。
GREEN · 通过
让它通过
编写最小 Skill
针对基线中发现的具体失败编写 Skill。不要为假设的情况添加额外内容。最小、聚焦、刚好让测试通过。
REFACTOR · 重构
堵住漏洞
明确反驳每个借口
Agent 找到新的合理化借口?逐一添加明确反驳。"保留作为参考再写测试" → 你会改编它,那就是事后测试,删除就是删除
循环回到 RED:用新场景再次施压,发现新的合理化借口,继续重构 ——直到 Agent 在最大压力下也无法绕过规则

四种 Skill 类型 · 对应不同测试策略

不是所有 Skill 都需要压力测试。先识别类型,再选测试方法。

类型
定义
测试方法
成功标准
纪律执行型
强制遵守规则(如 TDD、验证要求)
压力场景:时间 + 沉没成本 + 疲劳组合
最大压力下仍遵守规则
技术指导型
具体方法操作指南(条件等待、根因追踪)
应用场景:能否正确应用?边界情况?
技术成功应用到新场景
思维模式型
解决问题的心智模型(降低复杂度)
识别场景:能否判断何时适用 / 不适用?
正确判断模式适用范围
参考资料型
API 文档、命令参考、库指南
检索场景:能否找到正确信息?
找到并正确应用参考

关键差异:纪律执行型需要最严格的测试(压力 + 借口反驳),参考资料型主要测信息可发现性。 用错测试方法,要么过度工程,要么漏洞百出。

最重要的发现——Description 只描述触发条件

CRITICAL DISCOVERY
Description 只应描述触发条件,绝不要总结 Skill 的工作流程。

为什么?测试发现,当 description 总结了工作流程时,Agent 可能直接按 description 执行,跳过阅读完整 Skill 内容。 这是个反直觉但关键的洞察。

总结了工作流
description: Use when executing
  plans - dispatches subagent per
  task with code review between
  tasks
Agent 看到这段就觉得"够用了",直接走捷径,跳过 Skill 正文里的细节。
只有触发条件
description: Use when executing
  implementation plans with
  independent tasks in the current
  session
只描述"什么时候该激活",正文细节必须读完才能执行——保证 Skill 内容真正起作用。

Anthropic 官方最佳实践要点

简洁是关键——上下文是公共资源。默认假设 Claude 已经很聪明,只添加它不知道的信息。

简洁(~50 tokens)
## Extract PDF text
Use pdfplumber for text extraction:
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
    text = pdf.pages[0].extract_text()
冗余(~150 tokens)
## Extract PDF text
PDF (Portable Document Format) files
are a common file format... To extract
text from a PDF, you'll need to use
a library... There are many libraries
available...
Claude 已经知道 PDF 是什么、有哪些库——重复这些只是浪费上下文。

设置合适的自由度

高自由度
多种方法都有效,如代码审查流程。让 Agent 灵活组合。
中自由度
有首选模式但允许变化,如带参数的脚本模板。
低自由度
操作脆弱、一致性关键,如数据库迁移命令。强约束。
迭代开发模式
Claude A(专家)设计 Skill → Claude B(测试者)执行任务 → 观察行为发现问题 → 回 A 改进。重复直到满意。
Chapter 06 · 设计模式

Google 总结的5 种内部结构

规范告诉我们"Skill 长什么样",但没告诉我们"Skill 内部逻辑该怎么设计"。Google ADK 团队研究了 Anthropic 仓库、Vercel 和 Google 内部指南后,归纳出 5 种反复出现的设计模式。点击下面任一模式查看 它的可视化、内部代码与适用场景。

01
TOOL WRAPPER
技能包
让 Agent 在需要时才加载特定领域知识——而不是把所有东西塞进 system prompt。
解决的痛点:知识太多塞不进 prompt。SKILL.md 本身不包含完整规范,而是告诉 Agent "去哪里加载规范"
Agent CORE conventions.md style-guide.md api-spec.md OUTPUT 按需加载 ON-DEMAND
api-expert SKILL.md --- name: api-expert description: FastAPI 开发最佳实践与规范。适用于构建、审查或调试 FastAPI 应用程序时使用。 --- ## 核心规范 加载 'references/conventions.md' 获取完整规范列表。 ## 审查代码时 1. 加载规范参考文件 2. 对照每条规范逐一检查用户代码 3. 针对每处违规,引用具体规则并给出修改建议
适用场景
  • 封装框架/库的编码规范
  • 团队内部代码风格指南
  • 特定技术栈的最佳实践
  • 多套规则需要切换使用
关键洞察
SKILL.md 自己不是知识库——它是指挥棒,告诉 Agent 该去哪里取知识。
02
GENERATOR
填空题式生成
用模板 + 风格指南强制输出一致性——把"生成"变成"填空"。
解决的痛点:每次输出格式都不一样。Agent 不会瞎猜,缺什么直接问
TEMPLATE {{ TITLE }} {{ AUDIENCE }} {{ DATA }} STYLE GUIDE FILLED OUTPUT
report-generator SKILL.md --- name: report-generator description: 以 Markdown 格式生成结构化技术报告。 --- 第一步:加载 'references/style-guide.md',获取语气和格式规范。 第二步:加载 'assets/report-template.md',获取所需的输出结构。 第三步:向用户询问缺失信息: - 主题或议题 - 关键发现或数据要点 - 目标受众 第四步:按照风格指南规范填写模板。 第五步:返回已完成的报告。
适用场景
  • 标准化技术文档生成
  • API 文档自动生成
  • 项目脚手架
  • 固定格式的报告生产
关键洞察
Step 3 的主动提问是核心——Agent 不会瞎编缺失字段,强制走"采访"流程。
03
REVIEWER
审查者
把"查什么"和"怎么查"分离。检查清单独立维护,Agent 只负责执行打分。
解决的痛点:审查标准不统一。检查清单独立维护,输出结构化
CODE def func(): query = ... for i in ... db.save() CHECKLIST ☐ N+1 query ☐ SQL inject ☐ Naming ☐ Type hints ☐ Docstring ☐ Error hand Reviewer scoring REPORT ERROR · L4 N+1 WARN · L2 inject INFO · naming
code-reviewer SKILL.md --- name: code-reviewer description: 审查 Python 代码的质量、风格与常见错误。 --- 第一步:加载 'references/review-checklist.md'。 第二步:仔细阅读用户的代码。 第三步:逐一应用清单中的每条规则。针对每处违规: - 记录行号 - 划分严重等级:错误 / 警告 / 提示 - 解释问题的原因,# WHY not WHAT - 给出具体的修改建议 第四步:按严重等级分组,输出结构化的审查报告。
适用场景
  • 自动化 PR 审查
  • 安全漏洞扫描
  • 代码风格检查
  • 合规性审查
关键洞察
"WHY not WHAT"——不只指出问题,还要解释为什么是问题。这才能让被审查者真正学到东西。
04
INVERSION
反转
翻转传统交互——不是用户驱动,是 Agent 先采访用户,需求收集完再动手。
解决的痛点:需求不明确就开干。Agent 主动"分阶段采访",不到下一阶段不进。
PHASE 1 · 问题探索 Q1. 解决什么问题? Q2. 主要用户? Q3. 使用规模? PHASE 2 · 技术约束 Q4. 部署环境? Q5. 技术栈偏好? Q6. 硬性需求? PHASE 3 · 综合整理 · 开始构建 综合所有信息 · 加载模板 · 填写内容 · 呈现 · 迭代 DO NOT proceed until previous phase complete
project-planner SKILL.md --- name: project-planner description: 通过结构化提问收集需求,为新软件项目制定规划。 --- ## 在所有阶段完成之前,请勿开始构建。 ## 第一阶段 — 问题探索(每次只提一个问题) - 问题1:"这个项目解决什么问题?" - 问题2:"主要用户群体是哪些?" - 问题3:"预期的使用规模是多少?" ## 第二阶段 — 技术约束(仅在第一阶段全部回答完毕后进行) - 问题4:"部署环境是什么?" - 问题5:"是否有技术栈偏好?" - 问题6:"哪些是不可妥协的硬性需求?" ## 第三阶段 — 综合整理 收集所有信息 → 加载模板 → 填写内容 → 呈现结果 → 迭代优化
适用场景
  • 新项目规划
  • 系统架构设计
  • 需求不明确时的需求澄清
  • 需要"多轮采访"才能动手的任务
关键洞察
"DO NOT start building until all phases are complete" 是硬性门控——不是建议,是约束。
05
PIPELINE
流水线
把复杂任务拆成严格顺序的步骤——每步都有明确输入/输出和通过条件,Agent 不能跳步
解决的痛点:复杂任务容易丢三落四。分步执行,每步有检查点
STEP 1 解析清点 enumerate ? CONFIRM STEP 2 生成 docstr generate ! HARD GATE STEP 3 组装文档 assemble ? CONFIRM STEP 4 质检 verify FAILED · FIX AND REPEAT FEEDBACK LOOP PATTERN 运行验证器 → 修复错误 → 重复,直到通过 错误信息要具体:not "validation failed", but "Field X not found, available: Y, Z"
doc-pipeline SKILL.md --- name: doc-pipeline description: 通过多步骤流水线,从 Python 源代码生成 API 文档。 --- ## 按顺序执行每个步骤,不得跳过任何步骤。 ## 第一步 — 解析与清点 分析代码,提取所有公开 API,以清单形式呈现。 询问:"这是完整的公开 API 列表吗?" ## 第二步 — 生成文档字符串 针对每个缺少文档字符串的函数,生成内容并提交用户确认。 ## 在用户确认之前,不得进入第三步。 ## 第三步 — 组装文档 加载模板,将所有内容汇编为统一的 API 参考文档。 ## 第四步 — 质量检查 对照清单进行审查,在呈现最终文档之前修复所有问题。
适用场景
  • 从代码生成文档
  • 多阶段内容生产
  • 需要人工检查点的自动化流程
  • 错误代价高、需要逐级验证的任务
关键洞察
Step 2 → Step 3 的 "Do NOT proceed" 是硬性约束——用户不点头,Agent 不能继续。验证器的错误信息要具体
Chapter 07 · 决策指南

哪种模式适合你?

面对一个新需求,按主问题选模式,必要时考虑组合。下面是交互式选择器——点击你的诉求,看推荐结果。

你需要什么?

点击下面任一选项查看推荐模式
特定技术栈的专家知识(FastAPI 规范、内部代码风格)
一致的结构化输出(标准格式的报告、文档)
自动化代码 / 内容审查(PR 审查、安全扫描)
需求不明确,需先收集信息(项目规划、架构设计)
复杂多步骤任务(带检查点、不能跳步)
不确定从哪开始
推荐模式
查看模式详情 ↗

组合策略——单一模式不够时

5 种模式不是互斥的。下面是社区里被验证过有效的组合方式。

Pipeline + Reviewer
流水线最后一步加自动审查 → 文档生成后自动质量检查
Generator + Inversion
先收集信息再填模板 → 需用户输入的结构化文档生成
Pipeline + Tool Wrapper
流水线某些步骤加载专家知识 → 多步骤代码生成
Inversion + Pipeline
先完成需求收集再进流水线 → 复杂项目全流程

方法论选择——Skill-Creator vs Writing-Skills

两种方法论都有其位置——不是非此即彼,而是看场景。

用 Skill-Creator 当...

  • Skill 有客观可验证的成功标准(数据分析、代码审查)
  • 需要量化的 A/B 对比证明价值
  • 团队多人协作,需要可追踪的版本历史
  • 有充足的 token 预算(请注意成本)
  • 愿意投入时间走完整迭代流程

用 Writing-Skills 当...

  • Skill 是纪律执行型(强制 TDD、要求验证)
  • 主观判断为主,难以量化打分
  • 个人开发,重视开发速度
  • 预算敏感(避免 60 个并发 Opus 子会话)
  • 遇到 Agent 钻规则空子时——TDD 红绿循环最直接