Skill 不是 Prompt——
它是结构化的行为设计。
围绕任务、工具、流程、输出边界的可复用提示词增强包。 这页面把分散在 Anthropic 官方仓库、Superpowers 框架和 Google ADK 团队总结里的内容整合起来—— 读完之后你会知道什么时候该用 Skill-Creator 的工程化套路,什么时候 Writing-Skills 的 TDD 思路更合适, 以及面对一个新需求该选哪种设计模式。
规范标准
SKILL.md 文件结构、YAML frontmatter 字段、三层渐进式加载机制、命名与触发约束。
agentskills.io构建方法论
Skill-Creator 的工程化生命周期 vs Writing-Skills 的 TDD 红绿重构循环——两套思路的取舍。
Anthropic / Superpowers设计模式
Tool Wrapper · Generator · Reviewer · Inversion · Pipeline——五种内部结构原型与组合策略。
Google ADK什么是Agent Skill
在 AI Agent 生态中,Skill 是一种可复用的提示词增强包,通过渐进式加载 机制为 Agent 注入领域知识与工作流。2025 年 12 月 Anthropic 把它作为开放标准发布,目前 已被 33+ 个 Agent 产品采纳——Claude Code、OpenAI Codex、Cursor、Gemini CLI、Kiro 等。
最小形态
一个 Skill 的最小形态只需要一个文件:
SKILL.md 由两部分构成:YAML frontmatter(元数据,告诉 Agent 这是什么、何时用)和 Markdown body(指令正文,告诉 Agent 怎么做)。
三层渐进式加载
这是 Skills 规范最精妙的设计——借鉴 UI/UX 领域的渐进式信息披露策略。 即使安装了 20 个 Skill,初始加载也仅 1000-2000 tokens。 相比单体式提示词,上下文使用量减少约 90%。下面这个交互演示了 Agent 如何按需逐层展开。
关键价值在于分层激活的时机判断:Skill 的触发完全依赖 description 字段, 由模型自主判断当前任务是否匹配,而非关键词硬编码。这意味着写好 description 比写好指令主体更关键。
SKILL.md 的字段约束
YAML frontmatter 有两个必填字段、四个可选字段。命名规则比想象中严格——下面是完整的字段表与 最容易踩的坑。
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 是按需加载的,文件越小消耗越少。
Skill-Creator——把 ML 工程搬进 Prompt Engineering
Anthropic 官方"用来创建 Skill 的 Skill"。设计哲学一句话:像做机器学习一样做 Prompt Engineering—— 有训练集、测试集、评估指标、迭代循环、防过拟合机制。 它把软件工程中的 CI/CD、A/B 测试、性能基准这套实践完整移植过来了。
三个核心思想
六阶段生命周期
点击下面任一阶段查看详情。注意:3 → 5 是一个迭代回路,不是线性过程。
三个专业化子 Agent
各司其职,形成完整评估链。最精妙的是 Grader 的"自我批评"机制——它不仅打分,还质疑断言本身的合理性。
JSON 数据流——7 种 Schema 的级联管道
references/schemas.md 定义了 7 种 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 工作原理...对非技术用户认知负担高
Writing-Skills——把 TDD搬进 Skill 开发
Superpowers 框架里的元技能。它和 Skill-Creator 目标相似但方法论截然不同—— 不是统计基准,是 RED → GREEN → REFACTOR 的测试驱动循环。核心理念:测试先行、系统化优于随机化、 复杂度缩减、证据优于声明。
RED-GREEN-REFACTOR 循环
这是 TDD 的经典三段,搬到 Skill 开发场景里。
四种 Skill 类型 · 对应不同测试策略
不是所有 Skill 都需要压力测试。先识别类型,再选测试方法。
关键差异:纪律执行型需要最严格的测试(压力 + 借口反驳),参考资料型主要测信息可发现性。 用错测试方法,要么过度工程,要么漏洞百出。
最重要的发现——Description 只描述触发条件
为什么?测试发现,当 description 总结了工作流程时,Agent 可能直接按 description 执行,跳过阅读完整 Skill 内容。 这是个反直觉但关键的洞察。
description: Use when executing plans - dispatches subagent per task with code review between tasks
description: Use when executing implementation plans with independent tasks in the current session
Anthropic 官方最佳实践要点
简洁是关键——上下文是公共资源。默认假设 Claude 已经很聪明,只添加它不知道的信息。
## Extract PDF text
Use pdfplumber for text extraction:
import pdfplumber
with pdfplumber.open("file.pdf") as pdf:
text = pdf.pages[0].extract_text()
## 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...
设置合适的自由度
Google 总结的5 种内部结构
规范告诉我们"Skill 长什么样",但没告诉我们"Skill 内部逻辑该怎么设计"。Google ADK 团队研究了 Anthropic 仓库、Vercel 和 Google 内部指南后,归纳出 5 种反复出现的设计模式。点击下面任一模式查看 它的可视化、内部代码与适用场景。
适用场景
- 封装框架/库的编码规范
- 团队内部代码风格指南
- 特定技术栈的最佳实践
- 多套规则需要切换使用
关键洞察
适用场景
- 标准化技术文档生成
- API 文档自动生成
- 项目脚手架
- 固定格式的报告生产
关键洞察
适用场景
- 自动化 PR 审查
- 安全漏洞扫描
- 代码风格检查
- 合规性审查
关键洞察
适用场景
- 新项目规划
- 系统架构设计
- 需求不明确时的需求澄清
- 需要"多轮采访"才能动手的任务
关键洞察
适用场景
- 从代码生成文档
- 多阶段内容生产
- 需要人工检查点的自动化流程
- 错误代价高、需要逐级验证的任务
关键洞察
哪种模式适合你?
面对一个新需求,按主问题选模式,必要时考虑组合。下面是交互式选择器——点击你的诉求,看推荐结果。
你需要什么?
组合策略——单一模式不够时
5 种模式不是互斥的。下面是社区里被验证过有效的组合方式。
方法论选择——Skill-Creator vs Writing-Skills
两种方法论都有其位置——不是非此即彼,而是看场景。
用 Skill-Creator 当...
- Skill 有客观可验证的成功标准(数据分析、代码审查)
- 需要量化的 A/B 对比证明价值
- 团队多人协作,需要可追踪的版本历史
- 有充足的 token 预算(请注意成本)
- 愿意投入时间走完整迭代流程
用 Writing-Skills 当...
- Skill 是纪律执行型(强制 TDD、要求验证)
- 主观判断为主,难以量化打分
- 个人开发,重视开发速度
- 预算敏感(避免 60 个并发 Opus 子会话)
- 遇到 Agent 钻规则空子时——TDD 红绿循环最直接