原文作者：AI架构师汤师爷，2026年5月12日
最近 Skill 这个词在 AI 圈里出现的频率越来越高。你打开 Claude Code、Cursor、Codex，甚至 Gemini CLI，到处都在聊「Agent Skill」。
传统写 Prompt 是什么逻辑？一股脑把所有规则、所有例子、所有边界情况塞进 system prompt，生怕模型漏看了哪一条。结果上下文窗口被吃掉一大半，模型还经常该看的没看，不该看的反复强调。
Skill 的处理方式完全不一样——它把信息分成三层。
| 层级 | 内容 | 时机 |
|---|---|---|
| 第一层 | name + description（50-100 token/个） | 启动时始终加载 |
| 第二层 | 完整 SKILL.md 正文 | 任务匹配时按需调出 |
| 第三层 | 脚本、参考文档、模板资源 | 正文引用时再加载 |
这套逻辑像图书馆：进门先看目录，找到要看的那本书才取下来翻，需要附录再去翻附录。而不是把整个图书馆搬进你脑子里。
这个设计解决了 Agent 时代最头疼的问题——上下文膨胀。Skill 让能力的「拥有」和「使用」彻底解耦了。
Skill 怎么被触发的？没有关键词硬匹配，没有规则引擎，全靠模型自己读 description 判断「当前这个任务是不是该用这个 Skill」。
反例：Helps with PDFs——模型根本没法判断什么时候触发它。
正例：提取 PDF 文本和表格、填充 PDF 表单、合并多个 PDF 文件。当用户处理 PDF 文档，或提到 PDF、表单、文档抽取时使用。
好的 description 做三件事：
重要原则：description 只应该写触发条件，绝对不要总结 Skill 的工作流程。如果你在 description 里把工作流写出来了，模型可能直接照着 description 干活，根本不去读完整的 SKILL.md。
description 是钩子，不是说明书。 钩子的作用是把模型勾过来读正文，不是替代正文。
Anthropic 官方做的「用来写 Skill 的 Skill」，它把 Prompt Engineering 当成机器学习来做。
Skill-Creator 适合做严肃的、长期复用的、对质量要求高的 Skill。简单工具封装别用这么重的家伙。
核心方法论：RED-GREEN-REFACTOR
Writing-Skills 把 Skill 分成四种类型：
| 类型 | 测试难度 |
|---|---|
| 纪律执行型 | 最难（要顶住模型「自作聪明」） |
| 技术指导型 | 中等 |
| 思维模式型 | 中等 |
| 参考资料型 | 最简单 |
| 模式 | 适用场景 |
|---|---|
| Tool Wrapper（装技能包） | 封装框架/库的最佳实践，告诉 Agent 去哪加载规则 |
| Generator（填空生成） | 一致结构化输出，缺信息主动问不瞎编 |
| Reviewer（审查自动化） | 代码审查、PR 检查，「查什么」和「怎么查」分开 |
| Inversion（先问再做） | 需求不明确时，Agent 先采访用户再动手 |
| Pipeline（多步流水线） | 复杂任务，用户没确认不准进下一步 |
这 5 种模式还能组合：Pipeline + Reviewer、Generator + Inversion、Pipeline + Tool Wrapper。
不知道选哪个的时候，从 Tool Wrapper 开始，错不了。
Skill 就是 AI 应用开发的「模块化革命」：
软件工程的演进：一锅炖代码 → 模块化 → 面向对象 → 设计模式 → 测试与 CI/CD
AI 应用的演进：长 Prompt → Skill 模块 → 设计模式 → 自动评估 → Skill-Creator 工程化
如果你打算开始写自己的第一个 Skill：先用 Google 的 5 种设计模式选一个，手写一个最小版本，跑通再说。等写过 5 个以上 Skill 再上 Skill-Creator 这种工程化工具。工具是给有手感的人加速用的，不是给新手当拐杖用的。