一篇关于《图解 Skill》的读书笔记，梳理 Skill 的结构、写法、测试方法与实践技巧。
原文标题：读书笔记 | 理解 Skill，读《图解 Skill》
原文作者：图灵编辑部
冷月清谈：
怜星夜思：
2、如果 Skill 写得很好，但新模型已经不用它也能完成任务，这个 Skill 还要继续维护吗？
3、做 Skill 对比测试时，你更相信人工盲评，还是让另一个模型来评？
4、你会把多个小 Skill 串成工作流，还是更喜欢写一个大而全的 Skill？
原文内容
最近读完了宝玉的《图解 Skill —— AI 提效实战指南》，这是一本难得的 Skill 入门好书。趁着记忆还热乎，把心得整理成这篇读书笔记，分享给大家。
一、关于作者宝玉
宝玉是国内 AI 圈非常活跃的分享者，常年在推特（X，账号 @dotey）、微博和 GitHub 上输出大量实用的 AI 技巧和 Skill。他在 GitHub（用户名 JimLiu）开源的 baoyu-skills 仓库，目前已经积累了约 1.8 万 star，覆盖内容创作、配图生成、自媒体发布等一整套工作流，被很多自媒体作者日常使用。
这本《图解 Skill》系统讲解了如何设计、编写、安装和迭代 Skill，并配有完整示例和章节配套资源（官方示例仓库为 JimLiu/Illustrated-Agent-Skills），属于「边读边能上手」的那一类书。
二、Skill 长什么样
先从最基础的问题说起：一个 Skill 到底长什么样？
一个 Skill 就是一个文件夹，里面有一个 SKILL.md 文件。
展开 SKILL.md，可以看到它分成两部分：
-
第一部分是 YAML 格式的文件头，里面包含 Skill 的名字和描述。
-
第二部分是 Skill 的正文，包含这个 Skill 的具体内容。
除此之外，Skill 还有一个可选的第三部分——配套资源包。如果你的 Skill 需要一些参考文档或静态资源，可以放进资源包里。资源包没有严格的命名规则，也没有数量限制，比较自由。
书中举了一个稍微复杂一点的例子：一个带有脚本、参考文档和静态资源的 Skill，把这三类内容分成三个文件夹，统一放在 Skill 文件夹下面。如下图所示：
三、怎么写好 description
description 是 Skill 里非常关键的一部分，因为它直接决定了模型在什么时候会调用这个 Skill。
一个好的 description 应该包含两样东西：功能定义和触发场景。
举个例子：
-
「生成工作周报」——这是功能定义。
-
「当用户要求写周报、总结或汇报等内容时使用」——这是触发场景。
description 需要尽可能简洁，最好控制在 100 个字左右，最多不超过 200 个字。写得太长，反而会稀释关键信息。
四、正文怎么写
正文长度
关于正文长度，官方建议不超过 5000 token，对应大概是 3800 个字，行数不超过 500 行。换句话说，Skill 正文要克制，不要把它写成一篇长篇大论。
正文的内容框架
书中给出了一个具体的、可直接套用的内容框架，分成四步：
-
角色定位：先说清楚这是谁给谁用的。
-
核心要点：列出关键的要点。
-
禁止清单：列出绝对不能做的事情。
-
参考资料：最后附上相关参考资料。
书中以「写作风格 Skill」作为例子，把上面这套框架完整展开了一遍，是个很好的范例，建议对照原书细读。
五、怎么验证 Skill 写得好不好
书里还提出了一个我很认同的观点：技能写得好不好，应该做对比测试。
不过书中没有展开讲具体怎么测——核心思路是让模型一次加载 Skill、一次不加载 Skill，跑同一个任务做对照，看效果差异。这一节我顺着这个思路，补一套可以直接上手的做法，供大家参考。
核心逻辑：加载 vs 不加载
对比测试要回答的其实只有一个问题：有了这个 Skill，模型的输出到底变好了没有，还是只是多了一堆噪音？
所以最朴素的做法是这样三步：
-
准备一组真实的任务提示词（强烈建议用你日常工作里真实出现过的需求，而不是凭空编的例子）。
-
同一组提示词跑两遍：一遍加载 Skill，一遍不加载 Skill。
-
把两边的输出摆在一起对比，看加载之后是否真的更好。
怎么判断"更好"：先定验收标准
光靠"感觉好像更好了"是不够的，容易自我欺骗。更靠谱的做法是事先写下验收标准（断言）——也就是一条条明确、可判断的检查项。比如做一个"周报 Skill"，验收标准可以是：
-
是否包含了"本周完成 / 下周计划 / 风险项"三个固定板块？
-
语气是否符合团队对外汇报的口吻？
-
是否控制在规定字数内？
标准越客观、越可验证越好。但要注意：写作风格、设计美感这类主观的东西，不适合硬套断言，更适合人工定性判断，别为了"可量化"而扭曲它。
一个降低偏见的技巧：盲评
人在评判时容易有先入为主的偏见——知道哪份是"带 Skill 的"，就会下意识觉得它更好。一个解决办法是盲评：把两份输出隐去身份，交给另一个模型实例（或另一个人）来判断哪个更好、并说明理由，评判者并不知道哪份来自哪个版本。这样得到的结论更可信。
好消息：这件事现在可以自动化
值得一提的是，Anthropic 在 2026 年 3 月已经把这整套对比测试能力做进了官方的 skill-creator 工具里，而且全程不需要写代码。它能帮你：
-
自动写 eval（测试用例）：你给几个真实提示词、描述清楚"好的输出长什么样"，它就能生成测试。
-
自动跑加载 / 不加载对比：内置 comparator agent（对比智能体），自动对"有 Skill vs 无 Skill"两份输出做盲评，告诉你这个改动到底有没有用。
-
benchmark 基准模式：跑一轮标准化评测，记录通过率、耗时和 token 消耗，方便你在模型升级或修改 Skill 后回归测试。
-
优化 description 触发：自动生成"应该触发 / 不该触发"的样例，测量命中率，帮你调描述，减少误触发和漏触发。
这也呼应了我前面的延伸想法：对比测试的框架本身，完全可以交给 AI 来自动设计和执行。 书里点出了"要做对比测试"这个方向，而官方工具已经把它落地成了开箱即用的能力。
“顺带一提，官方还提到一个很有意思的观察：如果某天你发现不加载 Skill、模型也能通过全部 eval，那不是 Skill 坏了，而是模型自身能力已经进化到把这个 Skill 的技巧内化了——这个 Skill 可以"功成身退"了。这对判断一个 Skill 还有没有维护价值，是很实用的信号。
六、实用使用技巧
书的最后还给出了不少落地的使用技巧，几个我印象比较深的：
-
单一职责：每个 Skill 只做一件简单的事，再用一个工作流把多个 Skill 串起来。
-
按需加载：把一些更细粒度的 Skill 放在别的 Skill 下面，需要的时候再让它加载，避免一次性占用过多上下文。
-
配置外置：把可配置的参数放进扩展文件里，这样修改配置时不会动到原始的 Skill 文件。
七、小结
整体读下来，我认为《图解 Skill》是一本很好的 Skill 入门书。它把 Skill 的结构、写法、测试到使用技巧讲得清晰又系统，配图和示例也很到位，能帮助读者对 Skill 的设计和使用建立起一个全面的认识。
如果你正打算开始用 Skill、或者想把手头的 Agent 用得更顺手，这本书很值得一读，推荐给大家。