以自然语言为载体，门槛低
写一个 Skill 不需要会写代码。你只要能用语言把"怎么做"讲清楚，就能写一个能用的 Skill。这是 Skill 和传统插件/工具最大的门槛差异，它把"给 Agent 扩展能力"这件事，从工程师的专利变成了每个业务专家都能做的事。
第 17 课 Skill
工具让 Agent 有能力，Skill 让 Agent 懂经验。
预计 20 分钟 · 系列：从 0 到 1 设计一个 Agent
本课要点
- 把做事经验打包成可发现、可加载、可复用的能力单元
- 用五层结构与渐进式披露管理指令和上下文
- 写清判断标准，并建立召回、评测与版本管理闭环
你有没有遇到过这种情况： 同一个需求，第一次让 Agent 做，效果好得想发朋友圈；第二天一模一样的话再说一遍，出来的东西完全不是那个味儿。改写提示词重试，结果更是离谱。
问题出在哪？不是模型变差了，而是 "怎么把这件事做好"的经验，从没离开过第一次对话。它没有被固化下来，所以每次都是重新尝试。
Skill 就是为了解决这件事而生的。工具让 Agent 有能力，Skill 让 Agent 懂经验。
1. Skill 是什么
1.1 定义
Skill（技能） 是把"某件事该怎么做"，包括流程、经验、判断标准、参考素材，打包成一个可被 Agent 发现、加载和复用的能力单元。
拆开看三个关键词：
| 关键词 | 含义 |
|---|---|
| 怎么做 | 不是"做什么"，而是做事的方法论：先干什么后干什么、什么叫做好、什么情况要停下来问 |
| 打包 | 有名字、有说明、有边界，是一个独立的、可被单独管理的单元 |
| 可被发现和复用 | Agent 能根据你的意图自己判断"该不该用这个"，而不是每次都要你手动贴一段提示词 |
Skill 的本质，是把隐性经验显性化、把一次性对话资产化。
1.2 Skill 的三个特点
有判断空间，不是死流程
Skill 里不仅有步骤，还有取舍标准：遇到 A 情况走这条路，遇到 B 情况先停下来问用户；什么算合格，什么必须返工。这部分是无法用代码写死的，也是 Skill 真正的价值所在。
可组合、可嵌套
一个 Skill 可以在内部调用多个工具，也可以调用另一个 Skill。比如"发布网站"是一个 Skill，它内部会调用命令行工具、Git 工具，必要时还会调用"代码检查"这个 Skill。
发布网站 Skill
命令行工具
Git 工具
代码检查 Skill
1.3 Skill 和工具的区别：剪刀 vs 剪窗花
工具：剪刀
剪刀是一个工具。它的作用很纯粹，用来切断某些物体。它可以被用在无数地方：剪纸、裁布、剪指甲、拆快递。。
Skill：剪窗花
剪窗花是一项技能。它要用到许多专业技巧（折法、纹样设计、留白、阴阳刻），也要用到工具（剪刀、刻刀、红纸）。剪刀只是这项技能需要用到的工具之一。
剪刀刻刀红纸
这是理解 Skill 最关键的一个类比：
把这个类比平移到 Agent 身上：
- "读取文件""执行命令行""搜索网页"是工具，它们是通用的、无场景的；
- "按公司规范做一次代码评审""写一篇面向大众的科普文章""设计一张活动海报"是 Skill，它们是有场景、有标准、有审美判断的；
- Skill 在执行的某个步骤上，会去调用工具。
核心原则：工具回答"我能做什么动作"，Skill 回答"这件事该怎么做成"。
1.4 工具和Skill的区别
| 维度 | 工具（Tool） | Skill（技能） |
|---|---|---|
| 抽象层级 | 一个原子动作（动词） | 一套做事方法（菜谱） |
| 输入 | 固定的参数、字段，有 schema 校验 | 自然语言驱动的需求，允许模糊表达 |
| 确定性 | 同输入 → 同输出，可预测 | 需要灵活判断，不同情境下结果可以不同 |
| 代码化程度 | 可以 100% 代码化 | 无法完全代码化，需要留出灵活判断空间 |
| 粒度 | 单次调用完成一件事 | 多步骤流程，内部可编排多个工具和其他 Skill |
| 作者 | 工程师写代码 | 领域专家写自然语言，谁都能写 |
| 迭代方式 | 改代码 → 测试 → 发版 | 改描述 / 补示例，即时生效 |
还有三个容易忽略的区别：
失败表现不同
工具失败是明确的，报错、返回码、超时；Skill 失败是暧昧的，流程能跑、文章也写出来了，但"不对劲"。所以 Skill 必须配套验收标准，否则根本不知道它做错了。
上下文占用不同
工具只占一段 schema 描述，几十个工具描述都塞入上下文也是可接受的（但是工具多了也要考虑上下文占用问题）；Skill 需要加载完整指令甚至参考资料，塞多了会撑爆上下文。这也是为什么 Skill 需要渐进式披露。
复用范围不同
工具追求通用，一个"读取文件"服务所有场景；Skill 天然是场景化、个性化的，同一个"写周报"skill，A 部门和 B 部门的标准可以完全不同。
1.5 Prompt、Skill、Workflow 三者关系
| 概念 | 形态 | 谁来控制流程 | 适合 |
|---|---|---|---|
| Prompt（提示词） | 一段话 | 人 | 一次性需求 |
| Skill（技能） | 结构化能力包 | Agent 参考执行，可自主判断 | 有标准的重复性任务 |
| Workflow（工作流） | 固定编排的流程图 | 人类提前设计好固定的流程 | 强合规、低容错的流程 |
判断标准很简单：这件事的"正确做法"能不能被说清楚？ 能说清楚且需要灵活判断的，做 Skill；一步都不能错的固定步骤，做 Workflow；只干一次的，写 Prompt 就够了。
这件事的正确做法能不能被说清楚？
Prompt只干一次的需求
Skill重复且需要灵活判断
Workflow一步不能错的固定步骤
2. Skill 的构成
2.1 最小 Skill：一个提示词
一个提示词就可以构成一个最小的 Skill。
比如你经常需要把长会议记录整理成纪要，那么下面这段保存下来，它就已经是一个 Skill 的雏形：
把这份会议记录整理成结构化纪要：先给一段不超过 100 字的结论摘要；然后按议题分节，每节写清"讨论要点 / 结论 / 待办（含负责人和时间）"；最后单独列出所有未决事项。语气客观，不添加原文没有的信息。
它有名字（会议纪要整理）、有适用场景、有步骤、有验收标准
名字
会议纪要整理
场景
会议记录整理
步骤
结论 / 议题 / 待办
验收标准
结构完整，信息准确
2.2 完整 Skill 的五层结构
一个成熟的 Skill 通常长这样：
skill-name/
├── SKILL.md # 核心：元信息 + 指令（必须）
├── reference/ # 参考资料：规范、术语表、知识库（按需加载）
├── scripts/ # 可执行脚本：确定性的活交给代码
└── assets/ # 模板、样例、素材
- 1元信息
name + description，决定是否正确召回
- 2指令
步骤、判断标准、停止条件、常见坑
- 3参考资料
规范、术语、优秀案例，外置按需读
- 4脚本与工具
确定性的操作交给代码
- 5示例
输入 / 输出，锚定质量与风格
第一层：元信息（决定能不能被正确召回）
name: 技术科普文章撰写
description: 把专业技术内容改写成面向大众的科普文章。
适用于：技术博客、产品原理介绍、内部技术分享对外发布。
不适用于：学术论文、营销软文、新闻稿。
这是整个 Skill 最重要的信息。Agent 判断"要不要用这个 Skill"，读的就是这段描述。描述写得含糊，Skill 写得再好也召不回来。
第二层：指令（Instructions）
主体部分：分步骤的工作流、每步的判断标准、什么情况下需要停下来问用户、常见坑和规避方法。
第三层：参考资料（Reference）
规范文档、术语表、历史优秀案例、风格样例。这部分的正确做法是不塞进主指令，而是单独放文件，让 Agent 需要时自己去读。
第四层：脚本与工具（Scripts）
凡是确定性、可复用的操作，都应该写成脚本而不是让模型一步步现做，既省 token 又不出错。比如"按模板生成 Word 文件""批量替换术语""校验输出格式"，这些交给代码。
第五层：示例（Examples）
一两组完整的输入/输出对照。示例是锚定"风格"最有效的手段，一段好例子胜过五百字形容。
描述写得含糊，Skill 写得再好也召不回来。
2.3 渐进式披露：能不加载就不加载
第一层：name + description
常驻，成本极低
判定相关
第二层：SKILL.md 主指令
命中后才加载
执行需要
第三层：reference / scripts
执行中用到才读取
Skill 的加载应该分三层，按需逐级展开：
为什么要这样？因为 Skill 的价值之一是省上下文，如果每个 Skill 都把全部内容灌进来，几十个 Skill 就能把上下文吃光。省上下文的前提，是 Skill 自己也要省着用上下文。
判断准则：凡是"这次任务大概率用不上"的内容，一律外置成文件；凡是"每次都要遵守"的规则，才放进主指令。
每次都要遵守 → 放进主指令
必须始终遵守的规则、风格与约束，放在 SKILL.md 中。
本次大概率用不上 → 外置成文件
不常用的示例、脚本与参考资料，需要时再读取。
省上下文的前提，是 Skill 自己也要省着用上下文。
2.4 例子：把"网站发布部署"做成 Skill
这个例子能同时体现 Skill 的四个价值：
SKILL.md完整示例
---
name: 网站部署发布
description: 将本地静态站点构建并部署到沙箱环境，返回可访问链接。
适用于：前端项目构建产物（dist/build/out）的预览与发布。
不适用于：后端服务部署、数据库迁移。
---
工作流程
- 确认构建产物目录，检查其中必须包含 index.html；
- 执行构建命令（若项目未构建）；
- 上传整个目录到沙箱工作区并启动静态服务；
- 把访问链接返回给用户，并说明可在设置中管理已发布应用。
判断标准
- 目录中没有 index.html → 停下来告诉用户，不要猜测入口文件；
- 构建失败 → 展示完整错误信息，先排查再重试，不要连续盲试 3 次以上；
- 用户已有同名应用 → 先询问是覆盖还是新建。
注意事项
- 部署前不要对项目源码做任何破坏性修改；
- 每次部署成功后必须把链接和"如何删除"的路径一并告知用户。
真正有价值的不是那 4 个步骤，而是 "判断标准"和"注意"。这些才是经验的载体，也是纯代码工作流很难表达的部分。
3. Skill 的作用
1. 节约上下文空间
这是最直接的收益。没有 Skill 时，你要每次粘贴几百字的长提示词。有了 Skill，这些内容平时不占上下文，用时才加载，而且是加载"刚好够用的那一部分"。
一个直观的对比：
| 方式 | 上下文占用 |
|---|---|
| 每次手贴长提示词 | 全量常驻，且每次重复 |
| 全部规则写进系统提示词 | 全量常驻，挤占所有任务的公共空间 |
| Skill + 渐进式披露 | 平时只有一行描述，命中后按层加载 |
2. 给 Agent 提供更多能力选项
没有 Skill 的 Agent，能力上限约等于"模型自带能力 + 挂载的工具"。有了 Skill，你可以像装 App 一样给它加能力：装了"财报分析"它就会看财报，装了"海报设计"它就会做海报。
更关键的是：能力可以按需扩张，而不增加常态负担。挂 50 个 Skill 和挂 3 个，平时的上下文成本差别极小，因为模型平时只看见它们的名字和描述。
3. 固化 SOP，减少试错和重头再来
任何一件"每次做都要重新踩一遍坑"的事，都值得做成 Skill：
- 网站发布与部署流程；
- 代码评审清单；
- 需求文档评审流程；
- 数据报表的固定口径与生成步骤；
- 上线前的检查清单。
收益不只是省时间，更重要的是消除随机性：谁来问、什么时候问，得到的都是同一套标准动作。试错成本从"每次重新开始"变成"一次性沉淀"。
4. 传播个人 / 专家经验
这是 Skill 最有想象力的一点。以前，一个资深编辑的审稿标准、一个设计师的配色直觉、一个老销售的报价策略，这些东西存在人脑里，带不走、复制不了。
Skill 让这些经验第一次有了可存储、可传输、可继承的载体：
- 把撰写科普文章的经验做成 Skill → 全团队都能产出接近资深编辑水准的稿子；
- 把海报设计的经验做成 Skill → 设计规范不用靠口头传达；
- 把某个行业的尽调方法做成 Skill → 新人的产出下限被整体拉高。
5. 其他：拉升质量下限与组织资产
抬高"质量下限"：Skill 未必能让产出更好，但能保证产出不会更差。它把"偶尔做出 90 分"变成"稳定做出 75 分以上"。对企业来说，下限往往比上限更重要。
把个人能力变成组织资产：Skill 是可以入库、可以评审、可以版本管理、可以交接的。它让"某个人很会做这件事"，变成"整个组织很会做这件事"。
从个人会做，走向组织可复用。
4. 编写 Skill 的注意事项
1. 把 description 当成"召回关键词"来写
这是容易出问题的地方，Skill 写得再好，描述不清楚就永远不会被用到。
写法要点：说清楚三件事，做什么、什么时候用、什么时候不要用。
| 写法 | 评价 |
|---|---|
| "帮助用户处理文档相关任务" | 差：太宽泛 |
| "把会议记录整理成结构化纪要，输出结论摘要+议题分节+待办清单" | 好：动作明确、产出明确 |
| "…（同上）。不适用于访谈录音转写、不适用于学术论文" | 更好：有边界 |
2. 一个 Skill 只做一件事
职责单一，既是召回准确率的要求，也是复用性的要求。如果你发现一个 Skill 的名字里出现了"和"、"及"、"与"，大概率该拆了。
3. 少即是多：指令不是越长越好
长指令有两个副作用：挤占上下文、稀释模型注意力。经验判断：主指令控制在能被快速读完的长度，细节外置到 reference 文件。
每写一条规则前问自己：这条规则每次都会用到吗？如果不是每次都用，就别放进主指令。
4. 写判断标准，而不只是写步骤
只会写步骤的 Skill 是"流程文档"，会写判断标准的 Skill 才是"经验"。
优先补充这三类内容：
- 分支判断：遇到 X 情况怎么办，遇到 Y 情况怎么办；
- 停止条件：什么情况下必须停下来问用户，不要硬猜；
- 验收清单：做完了拿什么标准自检，不合格就返工。
5. 用示例锚定风格，而不是用形容词
"语言要生动活泼"是无效指令，"参考下面这段的语气"才是有效指令。风格类要求（语气、排版、详略）用示例表达，别用抽象词描述。
6. 确定性的活，交给脚本
凡是能用代码一步到位的操作，不要写成让模型手工执行的步骤。既省 token，又避免模型"发挥"出错。Skill 里应该只保留需要判断的部分。
7. 别硬编码易变信息
绝对路径、具体人名、临时 URL、会过期的版本号，这些一旦写死，Skill 很快就会失效。该参数化的参数化，该运行时获取的运行时获取。
8. 明确"不要做什么"
负面约束比正面描述更能防止跑偏，尤其是涉及不可逆操作时：不要删除某某、不要未经确认就发送、不要编造数据来源。
9. 写完必须用真实需求跑几遍
Skill 不是写完就完事。用 3~5 个真实需求（包括边界情况）实测，观察：它会不会被误召回？执行到哪一步会卡住？产出哪里不对味？然后回头改描述和指令。Skill 是迭代出来的，不是一次写出来的。
10. 像管理代码一样管理Skill版本
做好版本和变更记录。Skill 改坏了要能回滚，多人协作时要知道"现在生效的是哪一版"。
真实需求 → 观察失败 → 修改描述与指令 → 回归验证
5. 管理 Skill
Skill的数量 多了以后，最大的问题从"怎么写"变成 "怎么在需要的时候找到对的那个skill"。
这个问题要分4层解决。
5.1 工程层：让设计从一开始就"可检索"
创建之初就说清楚用途
在创建环节强制要求填写 name、description、适用场景、不适用场景，把"说不清用途"挡在入库之前；
主动检测重复与冲突
新建 Skill 时自动比对已有库，提示"你的'周报生成'与已存在的'工作汇报撰写'重叠度 80%，建议合并或明确区分"；
定期体检
对长期零调用、误召率高、产出被频繁返工的 Skill 发出预警，该合并的合并，该下架的下架；
命名规范统一
避免"写文章 / 文章撰写 / 撰稿"三个 Skill 指同一件事。
示例：检测到相似的 Skill
周报生成工作汇报撰写合并或明确边界
5.2 产品设计层：给用户确认权和知情权，把控制权交给用户
交互示例 · 仅演示选择与确认
把会议记录整理成纪要。
准备使用：会议纪要整理
输出摘要、议题结论、待办与未决事项。
中途可以更换或纠正，确认后再开始任务。
任务结束时展示本次引用的 Skill
- 召回后先确认：Agent 检索到 Skill 后，第一句话先告诉用户"我准备用 XX 这个技能来完成，对吗？"。这一步给用户缓冲和反应的时间，但能避免大量"方向错了还跑到底"的浪费；
- 任务结束时展示引用：每次任务结束，明确列出"本次引用了哪些 Skill"。这既是透明度，也是让用户理解 Agent 行为、进而学会正确使用 Skill 的教育过程；
- 允许用户中途换：发现用错了，用户能打断和纠正。
召回不能只依赖模型判断，还要留人工通道：
- 直接检索：让用户能搜索、浏览自己的 Skill 库；
- 显式指定：允许用户直接说"用 XX 技能来做这件事"，或界面上选中某个 Skill 再发起任务；
- 常用置顶 / 场景分组：按使用频率、项目、部门组织 Skill 列表。
直接检索
搜索、浏览 Skill 库
显式指定
选中 Skill 后发起任务
常用置顶 / 场景分组
按项目、部门和频率组织
5.3 模型层：提升意图识别与召回能力
意图识别
训练/微调模型根据用户意图识别正确 Skill 的能力，尤其是处理模糊表达、口语化表达、跨语言表达的能力；
区分相似 Skill
对相似 Skill 的区分性训练：让模型能抓住"科普文章"和"技术博客"的差别，而不是一看到"写文章"就随机抓一个；
无匹配时不硬套
提供拒答能力：当没有任何 Skill 匹配时，应该诚实地不使用，而不是硬套一个相近的。
5.4 指标监控与专项评测
没有度量就没有优化。至少要盯住这几个指标：
| 指标 | 含义 | 用途 |
|---|---|---|
| 接受率 | 被召回后用户确认使用的比例 | 衡量召回准确度 |
| 拒绝率 | 被召回后被用户否掉的比例 | 高拒绝率 = 描述写歪了或库里有干扰项 |
| 漏召率 | 应该用但没被召回的比例 | 高漏召 = 描述覆盖不足 |
| 一次通过率 | 用该 Skill 后无需返工的比例 | 衡量 Skill 本身的质量 |
| 零调用率 | 长期无人使用的 Skill 占比 | 判断该不该下架 |
评测与优化的闭环流程
创建针对 Skill 召回的专项评测数据集
覆盖正例（明确该用）、负例（明确不该用）、易混淆例（两个 Skill 都像）；
A/B 验证
改了描述或加了新 Skill 之后，跑一遍评测集，看接受率和漏召率是否真的改善，而不是凭感觉判断"好像变好了"；
闭环归因
拒绝率高的 Skill 单独分析，是描述问题、能力问题，还是库里存在更合适的替代品。
6. 本课小结
Skill 是什么
把"怎么做"打包成可复用能力单元；工具是剪刀，Skill 是剪窗花
Skill 的构成
最小是一个提示词，成熟形态是"元信息+指令+资料+脚本+示例"五层，按需加载
Skill 的作用
省上下文、扩能力、固化 SOP、传播专家经验、抬高质量下限
编写注意
描述是召回的命门；一个 Skill 一件事；写判断标准而不是只写步骤；写完必须实测
管理注意
工程层防重复、产品层给确认权、模型层练召回、用户层留主动入口、指标层做专项评测
Skill 的本质，是把"人脑子里的经验"变成"系统里的能力"。写 Skill 是技术活，管 Skill 是产品活。
7. 课后思考题
结合你的实际工作，思考并完成以下问题。它们没有标准答案，重在把所学应用到真实场景。
你手头有没有那件"每次做都要重新讲一遍怎么做"的事？把它按 2.2 的五层结构写出来。
产出：元信息、指令、参考、脚本、示例
翻一遍你已经写好的 Skill（或提示词），它的 description 能不能让一个陌生 Agent 判断出"该不该用"？
检查：做什么 / 适用 / 不适用
如果你有 100 个 Skill，你打算怎么防止它们互相打架？从工程层、产品层、模型层各说一条措施。
检查：重复、控制、区分
想一想：你所在的团队里，谁的经验最值得被做成 Skill？如果不做，这个人离开后损失的是什么？
思考：隐性经验如何成为组织资产
素材来源与延伸阅读
Anthropic：Equipping agents for the real world with Agent Skills（2025-10），提出 SKILL.md 结构与渐进式披露机制
Agent Skills 开放标准（agentskills.io，2025-12 起由 Anthropic 推动标准化）
Anthropic：Writing effective tools for agents（工具与技能的设计原则）
本课第 1.3 节"剪刀与剪窗花"类比为课程原创，第 3、4、5 节实践建议结合工程与产品经验整理