Skill 到底是什么？从提示词、脚本到多智能体工作流的完整指南

从"提示词复读机"到 AI 工作流：读《图解 Skill》后，我总结了 7 章精华与 10 条实战方法

本文是对宝玉老师《图解 Skill：AI 提效实战指南》的阅读整理与实践思考。内容不是对原书的简单缩写，而是围绕"Skill 为什么有用、每章解决了什么问题、普通人和开发者如何真正用好 Skill"进行重新组织。

前言：我们可能不是在使用 AI，而是在给 AI 打工

很多人使用 AI 的方式，仍然停留在下面这个循环里：

1. 把材料复制到聊天框；
2. 重新说明格式、语气和步骤；
3. AI 输出不符合预期，再补充要求；
4. 下一次遇到同类任务，从头再来一遍。

表面上是 AI 在帮我们，实际上我们把大量时间花在重复粘贴提示词、解释规则和修正格式上，自己成了"提示词复读机"。

《图解 Skill：AI 提效实战指南》给出的解决方案是：不要只优化某一次对话，而要把一项任务中可复用的流程、规则、经验和工具使用方式，封装成 Skill，让智能体以后照着同一套方法稳定执行。

如果只用一句话概括全书，我认为是：

Skill 的价值，不是让模型突然变聪明，而是把人的隐性经验变成 AI 可以反复执行的显性流程。

一、先说清楚：Skill 到底是什么？

Skill 可以理解为写给 AI 智能体的"标准作业手册"。它通常是一个文件夹，至少包含一份 SKILL.md，复杂一些的 Skill 还会包含脚本、参考资料和模板。

my-skill/
├── SKILL.md          # 核心流程与规则
├── scripts/          # 确定性操作脚本，可选
├── references/       # 按需读取的参考资料，可选
└── assets/           # 模板、图片等静态资源，可选

它和普通提示词最大的区别，不是文件格式，而是定位不同：

方式	更适合解决什么问题
普通提示词	一次性、简单、变化较大的任务
脚本	规则固定、必须得到确定结果的任务
Skill	高频、多步骤，既有固定规则又需要模型判断的任务

例如，"把这段话改得更通顺"用一次提示词就够了；"将日期统一转为 YYYY-MM-DD"更适合脚本；"读取会议记录、识别决议和待办、按公司模板生成纪要并保存文件"则很适合做成 Skill。

---

二、全书 7 章精华：从第一次调用到工程化落地

第 1 章：先跑通第一个 Skill，建立最直观的体感

第 1 章没有急着解释概念，而是让读者用"周报生成"做一次对照实验：

• 不使用 Skill 时，每周都要重复说明表格列、语气和保存格式；
• 使用 Skill 后，只需提供本周完成的事项，智能体就会自动按既定标准生成周报。

这一章最重要的并不是学会写周报，而是理解 Skill 的第一层价值：

把"每次都要重新说"的要求，变成"只需要维护一次"的规则。

书中给出了两种很实用的创建方式：

1. 标准已经清楚：直接把格式、流程和交付要求告诉智能体，让它创建 Skill；
2. 标准还不清楚：先在一次对话中反复调试结果，满意后再让智能体根据完整对话，把最佳做法固化成 Skill。

第二种方式尤其适合真实工作。因为很多时候，我们并不能在开始前完整描述"好结果长什么样"，但看到成品后，很容易判断哪里不对。

本章还给出 Skill 不生效时的三步排查思路：

1. 确认 Skill 已经安装或启用；
2. 确认当前环境已经重新加载 Skill；
3. 检查 description 是否覆盖了用户真实的表达方式。

这三步也揭示了一个关键事实：一个 Skill 写得再好，如果没有被正确触发，就等于不存在。

第 2 章：理解 Skill 为什么比"大段提示词"更可靠

第 2 章用"厨房"类比智能体系统，降低了理解门槛：

智能体概念	厨房类比	作用
提示词	顾客点菜	告诉 AI 当前目标
大模型	厨师	负责理解、判断和规划
上下文	厨房台面	存放当前任务所需信息，容量有限
工具	刀具和厨具	让智能体读文件、联网、执行代码
Skill	菜谱	告诉智能体怎样稳定完成任务
MCP 等连接机制	通用插座	让外部系统以统一方式接入

作者认为，Skill 相比充当"操作手册"的长提示词有四个进化：

1. 按需加载：不必每次把所有规则全部塞进上下文；
2. 文件化工作台：中间结果可以保存、恢复和局部修改；
3. 工作流协作：多个 Skill 可以串联、并联或循环执行；
4. 经验复利：规则只有一个稳定来源，修改一次后持续生效。

Skill 的三层加载机制

这一章最值得掌握的是"渐进式加载"思想：

1. 智能体先看到所有 Skill 的 name 和 description；
2. 判断任务匹配后，再读取对应的 SKILL.md 正文；
3. 只有执行到特定场景时，才继续读取 references/，或运行 scripts/。

因此，description 不是普通简介，而是 Skill 的路由入口。一个实用公式是：

description = 功能定义 + 触发场景/常见说法 + 必要的排除场景

例如：

description: 分析 Git 分支之间与指定业务模块相关的代码差异。当用户要求评估分支合并影响、筛选相关提交或生成迁移风险报告时使用。不用于直接执行合并或推送代码。

这段描述同时回答了三件事：能做什么、什么时候触发、什么事情不做。

第 3 章：不是所有任务都值得做成 Skill

学会创建 Skill 后，人很容易把所有任务都 Skill 化。第 3 章就是负责"踩刹车"的一章。

作者建议先把任务拆成三类操作：

• 执行规则：格式转换、字段校验、固定计算等；
• 做判断：提炼重点、判断风险、选择表达方式等；
• 调外援：访问数据库、搜索网页、读取代码仓库等。

拆解以后，分工会变得清楚：

• 需要语义理解和业务判断的，交给模型；
• 规则固定且要求准确的，交给脚本；
• 智能体本身没有的能力，通过工具或外部连接补充。

一件事值不值得做成 Skill？

可以先问三个问题：

1. 这件事是否会反复做？
2. 是否要求结果具有一致性？
3. 当前流程是否已经相对稳定？

满足得越多，越适合做成 Skill。

反过来说，以下三类内容通常不需要做成 Skill：

• 永远生效的个人偏好，更适合放全局配置；
• 一个工具或一条命令就能稳定完成的操作，直接使用工具；
• 只做一次的临时任务，直接对话即可。

这一章还强调了安全：安装第三方 Skill 前，应检查它读取什么、写入什么、是否联网、是否包含删除和发布等高风险动作。Skill 是能让智能体"动手"的操作手册，因此能力越强，越需要边界。

第 4 章：三种典型 Skill，三种设计方式

第 4 章通过三个案例展示了三种常见设计：

类型	主要控制什么	书中案例
约束型	语气、风格、禁用表达	写作风格 Skill
模板型	固定结构、字段、输出格式	会议纪要 Skill
流程型	先后步骤、工具调用、中间产物	文章配图 Skill

现实中的 Skill 往往是混合型。例如，会议纪要既需要固定模板，也可能需要语气约束；文章配图既有流程，也有文件命名和输出格式要求。

为什么复杂任务要"先做计划，再执行"？

文章配图案例有一个很值得借鉴的细节：不要让智能体边分析文章边生成图片，而应先输出完整配图计划，确认插图位置、目的、视觉内容和文件名，再逐张生成。

这不是增加形式，而是在对抗模型"做到后面忘了前面"的问题。对于代码迁移、数据治理、批量文件处理等复杂任务，也适合先生成执行计划和影响清单，再进入实际操作。

Skill 迭代的两个原则

• 一次只改一个问题，避免多个规则同时变化后无法定位影响；
• 底线写成硬规则，偏好尽量解释原因，让模型能举一反三。

修改后做三类验证：

1. 触发测试：该触发时是否触发，不该触发时是否误触发；
2. 功能测试：同一个输入多跑几次，结构和关键信息是否稳定；
3. 对比测试：与不使用 Skill 相比，质量是否真的明显提升。

第 5 章：从单个 Skill 走向多 Skill 工作流

复杂任务不应该塞进一个"万能 Skill"。第 5 章提出一个重要原则：

一个 Skill 尽量只负责一项有独立价值、可单独复用的能力。

例如，会议纪要中的"分析讨论内容"和"按模板生成纪要"可以拆成两个 Skill。前者还能用于项目复盘、客户访谈和聊天记录提炼，拆开后复用价值更高，也更容易测试和维护。

三种组合方式

• 串联：A 的输出是 B 的输入，如素材分析 → 大纲 → 写作 → 润色；
• 并联：基于同一份输入同时探索多个方案，如按三份大纲生成三版文章；
• 循环：质检不通过后，带着问题返回上一步重做。

文件是多 Skill 协作时非常重要的媒介。大段数据和中间结果应保存为文件，工作流只传递路径和摘要，避免主对话被大量内容挤满。

子智能体不是 Skill 的替代品

Skill 解决的是"怎么做"，子智能体解决的是"由谁在独立上下文中做"。

当任务较轻、需要主智能体了解过程时，直接调用 Skill 即可；当任务耗时较长、需要并行探索，或中间过程会占用大量上下文时，再考虑交给子智能体。

给子智能体派任务时，应说清四个要素：

目标：最终要完成什么
约束：什么能做，什么不能做
输入：数据或文件在哪里
验收：完成前必须检查什么

其中"验收"最容易被忽略。没有验收条件，子智能体只知道何时开始，不知道怎样才算完成。

第 6 章：把 Skill 当成一个小型软件产品来开发

第 6 章把 Skill 开发提升到工程化层面，完整流程可以概括为：

需求分析 → 设计 → 实现 → 测试 → 发布 → 持续迭代

先填一张需求卡

创建 Skill 前，至少回答六个问题：

1. 它解决什么具体问题？
2. 用户通常会在什么场景下使用？
3. 输入是什么？
4. 输出是什么？
5. 必须遵守哪些规则？
6. 明确禁止什么？

这六个答案，基本就是 SKILL.md 的骨架。

四种提高可靠性的设计

1. 记录踩坑点：将真实使用中反复出现的错误沉淀下来；
2. 增加容错：开始前检查输入，关键节点人工确认，中间结果及时保存；
3. 预留扩展：把稳定流程与变化配置分离，避免每加一个需求就重写主文件；
4. 跨对话记忆：把进度、历史处理范围等写入稳定文件，而不是期待模型永久记住。

用 Eval 替代"感觉还行"

一个成熟 Skill 不能只凭一次输出判断好坏。书中给出的评测循环非常接近软件测试：

1. 准备真实测试用例，包括正例、边界情况和容易混淆的反例；
2. 提前定义可判断的检查项；
3. 对比有 Skill、无 Skill，或新旧版本的结果；
4. 根据失分点修改，再跑完整回归测试。

需要特别注意：

• 失败案例保存在测试题库中；
• 从失败中提炼出的通用经验，才写进 SKILL.md；
• 不要为了通过某一个案例而加入过窄的"答案型规则"。

这就是 Skill 工程中最重要的防退化机制。

第 7 章：用 V1、V2、V3 完成一次真实迭代

第 7 章以数据分析 Skill 为例，展示了三个版本的演进：

版本	核心目标	解决的问题
V1 基础版	能稳定运行	读取数据、基础统计、输出固定结论
V2 增强版	具备分析深度	引入分析框架、异常检测和业务解释
V3 生产版	可以正式交付	结合模板和设计指引，生成可视化报告

最值得学习的不是最终那份报告，而是迭代顺序：

• V1 不追求漂亮，只验证核心链路；
• V2 根据 V1 暴露的问题，专门补"怎么思考"；
• V3 在分析质量稳定后，再补交付形式。

每一版只解决一个核心问题，因此能清楚判断改动是否有效。更重要的是，用户始终只需要上传文件并说"帮我分析一下"，复杂度全部留在 Skill 内部。

这体现了一条产品原则：

好 Skill 应该不断增强后台能力，而不是不断增加用户的学习成本。

---

三、如何更好地使用 Skill：10 条可以直接照做的建议

1. 从真实的重复劳动开始，不要从"我要做个 Skill"开始

先观察一周：哪些任务你重复做了三次？哪些要求你向 AI 解释了三次？哪些错误你纠正了三次？这些才是最值得 Skill 化的候选项。

2. 一个 Skill 尽量只解决一个稳定问题

判断是否应该拆分，可以问：其中某一步是否能产生独立交付物？是否会在其他场景单独复用？如果答案是肯定的，就值得拆出来。

3. 把 description 当成路由规则，而不是宣传文案

至少包含"功能 + 触发场景"，存在相似 Skill 时再补一句排除场景。完成后使用两种不同说法测试触发，并增加一条容易混淆的反例测试误触发。

4. 保持 SKILL.md 克制，把大块知识按需拆出去

主文件只保留核心步骤、边界、输出要求和检查清单。详细规范、领域知识、长示例和 API 说明放进 references/，并在主文件中明确写出什么情况下读取哪个相对路径。

只把文件放进 references/ 并不等于智能体一定会读取它。

5. 模型负责判断，脚本负责确定性

可以用一个问题判断：相同输入是否必须得到完全相同的输出？

• 必须相同：优先脚本，例如日期转换、字段校验、哈希计算；
• 允许因语境变化：交给模型，例如风险判断、内容取舍、建议生成。

6. 用文件做外部记忆，不要把所有内容堆在聊天记录里

原始材料、中间结果、评测报告和最终交付物分别保存。复杂流程中尽量传文件路径和短摘要，而不是反复复制全文。

7. 在高成本或高风险步骤前设置人工检查点

例如批量修改代码、生成几十张图片、写数据库、发消息或发布内容之前，先暂停并展示计划、影响范围或预览结果。自动化不是取消人的决策，而是把人的精力集中到关键决策上。

8. 建立自己的测试题库

每发现一次真实问题，就把当时的输入保存为回归用例。修改 Skill 后，不只重测当前案例，还要重跑旧案例，防止解决新问题的同时让旧功能退化。

9. 全局 Skill 少而精，项目 Skill 跟着项目走

写作风格、通用翻译等高频能力适合全局启用；薪酬系统代码审查、特定数据库规范等业务能力更适合放在项目范围。启用的 Skill 不是越多越好，重叠越多，误触发和上下文消耗越明显。

10. 让 Skill 记录你的业务经验，而不是复制网上的通用常识

真正有价值的内容通常包括：团队约定、字段含义、审批边界、容易误判的场景、历史事故和验收标准。这些才是通用模型无法凭空知道、也是 Skill 最有复利价值的部分。

---

四、一个适合开发者的实战例子：代码合并影响分析 Skill

以 Java 项目中常见的"把测试分支某个功能迁移到生产分支"为例。这个任务往往不是简单执行 git merge，而是要先回答：

• 哪些提交与目标功能有关？
• 相关代码是否已通过其他提交进入生产？
• 一个公共类的差异究竟属于目标功能，还是其他需求遗留？
• 迁移会不会连带带入不相关改动？

这类工作很适合做成一个"合并影响分析 Skill"，但不应让它直接合并代码。

推荐职责边界

输入：源分支、目标分支、目标功能、相关路径、已知提交

确定性操作：
- 执行 git log、git diff、git cherry 等只读命令
- 按提交和文件生成差异清单
- 保存原始 diff 证据

模型判断：
- 判断每处差异是否与目标功能相关
- 识别公共代码中的交叉需求
- 给出直接迁移、手工摘取或放弃迁移的建议

输出：
- 相关提交清单
- 文件级影响矩阵
- 高风险公共文件
- 缺失依赖与验证建议
- 推荐迁移方案

安全边界：
- 默认只读
- 不自动 cherry-pick、merge、commit 或 push
- 真正变更前必须由人确认

这个例子把全书的方法串了起来：Git 命令负责确定性取证，模型负责业务相关性判断，文件保存证据，人负责最终迁移决策；后续每次遇到遗漏提交或误判，再把真实案例加入测试题库。

---

五、一个最小可用的 SKILL.md 结构

不同平台的扩展字段可能存在差异。起步时保持最小结构，通常只保留 name 和 description，更容易迁移和维护。

---
name: merge-impact-analyzer
description: 分析两个 Git 分支之间与指定功能相关的提交和代码差异。当用户要求评估分支合并影响、筛选功能相关提交或生成迁移风险报告时使用。不执行合并、提交或推送。
---

# 合并影响分析

## 输入

- 源分支与目标分支
- 目标功能说明
- 相关目录或文件
- 已知提交，可选

## 工作流程

1. 确认分析范围；范围不清时先询问。
2. 使用只读 Git 命令收集提交和文件差异。
3. 将原始命令结果与 diff 保存为证据文件。
4. 按"直接相关、间接依赖、无关、无法确认"分类。
5. 对公共类和公共配置单独进行交叉需求检查。
6. 生成迁移建议与测试清单。

## 输出

- 提交清单
- 文件影响矩阵
- 风险与依赖
- 推荐操作方案
- 上线前验证项

## 安全规则

- 默认只读，不执行 merge、cherry-pick、commit、push。
- 无证据时不得断言某处差异属于目标功能。
- 涉及生产分支的任何修改必须先请求人工确认。

## 验收清单

- 是否覆盖全部指定路径？
- 每个结论是否能追溯到提交或 diff？
- 是否区分目标功能和其他需求？
- 是否给出可执行的验证方案？

## 踩坑点

- 持续记录真实使用中出现的漏判、误判和跨需求耦合案例。

第一版不用追求复杂。先选择一个真实分支差异跑通，根据结果缺什么再补什么，比一开始写几百行规则更有效。

---

六、最容易误解的 6 件事

1. Skill 不是"更长的提示词"

它的核心是可复用流程、按需资源、工具调用、文件化中间产物和持续迭代，而不是把所有知识塞进一个 Markdown 文件。

2. Skill 不能替代业务判断

模型能执行你写下的经验，却不能替你发明尚未形成的标准。你自己都说不清怎样算好，Skill 也很难稳定做好。

3. Skill 不等于永久记忆

需要跨对话保留的状态，应写入文件或可靠的数据系统，而不是依赖模型"记得上次聊过什么"。

4. Skill 越多不代表能力越强

大量功能重叠的 Skill 会带来路由冲突、误触发和上下文浪费。质量、边界和组合能力比数量更重要。

5. 子智能体不一定更高效

子智能体具有独立上下文，但也会产生信息交接成本。一个上下文能完成的轻任务，没有必要强行拆出去。

6. 自动执行不等于无人负责

代码修改、数据库写入、文件覆盖、消息发送和线上发布等操作，都应保留权限控制、预览、备份和人工确认。

---

结语：真正值得积累的，不是提示词，而是你的做事方法

读完这本书后，我最大的感受是：Skill 的真正壁垒从来不在 Markdown 语法，也不在会不会写脚本，而在一个人是否真正理解自己的工作。

你是否知道一项任务为什么这样做？哪些步骤不能错？哪些地方需要判断？什么样的结果才能交付？过去踩过哪些坑？

这些经验平时散落在人的脑子里、聊天记录里和一次次返工中。Skill 做的事情，就是把它们逐步变成可执行、可验证、可组合、可持续升级的数字资产。

所以，不必从设计一个"万能 AI 助手"开始。挑一件你本周已经重复做过三次的小事，先做一个二三十行的 Skill，真实运行一次。哪里不满意，哪里就是下一版的需求。

当 Skill 越用越准，你积累的不只是一份提示词，而是一套可以被 AI 放大的个人工作方法。