IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

理解 Skill —— 读《图解 Skill》

唐巧的博客 2026-06-27 17:10:36 累计浏览 3 次
本机暂存

最近读完了宝玉的《图解 Skill —— AI 提效实战指南》,这是一本难得的 Skill 入门好书。趁着记忆还热乎,把心得整理成这篇读书笔记,也分享给同样在折腾 AI Agent 的朋友。

一、关于作者宝玉

宝玉是国内 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 正文要克制,不要把它写成一篇长篇大论。

正文的内容框架

书中给出了一个具体的、可直接套用的内容框架,分成四步:

  1. 角色定位:先说清楚这是谁给谁用的。
  2. 核心要点:列出关键的要点。
  3. 禁止清单:列出绝对不能做的事情。
  4. 参考资料:最后附上相关参考资料。

书中以「写作风格 Skill」作为例子,把上面这套框架完整展开了一遍,是个很好的范例,建议对照原书细读。

五、怎么验证 Skill 写得好不好

书里还提出了一个我很认同的观点:技能写得好不好,应该做对比测试。

不过书中没有展开讲具体怎么测——核心思路是让模型一次加载 Skill、一次不加载 Skill,跑同一个任务做对照,看效果差异。这一节我顺着这个思路,补一套可以直接上手的做法,供大家参考。

核心逻辑:加载 vs 不加载

对比测试要回答的其实只有一个问题:有了这个 Skill,模型的输出到底变好了没有,还是只是多了一堆噪音?

所以最朴素的做法是这样三步:

  1. 准备一组真实的任务提示词(强烈建议用你日常工作里真实出现过的需求,而不是凭空编的例子)。
  2. 同一组提示词跑两遍:一遍加载 Skill,一遍不加载 Skill
  3. 把两边的输出摆在一起对比,看加载之后是否真的更好。

怎么判断”更好”:先定验收标准

光靠”感觉好像更好了”是不够的,容易自我欺骗。更靠谱的做法是事先写下验收标准(断言)——也就是一条条明确、可判断的检查项。比如做一个”周报 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 用得更顺手,这本书很值得一读,推荐给大家。

最后,感谢人民邮电出版社英子老师的赠书。

同分类推荐文章

  1. 从”内容治理”到”行为治理”:中国智能体治理框架深度解析与绿盟科技实践 (2026-06-23 21:49:28)
  2. 美团海报生成 AIGC 技术创新与实践 (2026-06-22 15:34:28)
  3. AI Coding Agent 时代,我自己最常用的 4 个终端工具 (2026-06-22 08:00:00)

查看更多 AI 文章 →

建议继续学习

  1. 12款很棒的浏览器兼容性测试工具推荐 (累计阅读 6,300)
  2. 自动化测试中Python与C/C++的混合使用 (累计阅读 5,299)
  3. 对职业发展问题的终极回答 (累计阅读 3,736)
  4. 话说员工的跳槽与忠诚度 (累计阅读 3,644)
  5. Python文件操作函数简介 (累计阅读 3,600)
  6. Linux大棚版gtest官网教程译文 (累计阅读 3,594)
  7. 序列化格式YAML初探 (累计阅读 3,182)
  8. Google App Engine的app.yaml详细说明 (累计阅读 3,041)
  9. 探讨:研发中心应该包括的核心元素模型 (累计阅读 3,014)
  10. 敏捷测试的方法和实践 (累计阅读 3,006)