这期内容讲清楚 Skill 的几件事:Skill 是什么,怎么安装别人的 Skill,怎么创建自己的 Skill,以及一些最佳实践。

Skill 是什么

Skill 的本质是一个文件夹,这个文件夹有固定的格式。

Skill 的文件夹结构

文件夹里一定会有一个 SKILL.md 作为入口,里面描述这个 Skill 是干什么的、叫什么名字、什么时候触发,以及它要执行的流程。除了入口文件,还有几个按需添加的目录:

  • scripts/ 放脚本,比如需要爬取外部信息、调用外部 AI 工具生成图片的逻辑;
  • references/ 放参考文件,比如流程里有一段很长的规范,可以单独放在这里;
  • assets/ 放资产,比如 Skill 运行后要展示的页面里用到的图片。

为什么 Skill 是一个文件夹?因为现在的 Agent 一定有读取文件、写入文件的能力,还可以执行命令、调用脚本。文件夹是一种通用规范,任何 Agent 只要能读文件,就能读到 Skill 里的信息;它想创建 Skill,也一样调用写文件的能力就能完成。

怎么安装 Skill

既然 Skill 是一个文件夹,安装就和分享文件一样。没有 Skill 这个概念的时候,我们分享一个文件夹,可能会压缩成压缩包,通过聊天软件发给别人。现在 Skill 有社区和资源,GitHub、SkillHub 这类云端的文件托管平台都可以直接下载。代码是文件,Skill 也是文件,可以用同一种形式托管。

Skill 的安装来源

不管是自己的 Skill 还是别人的 Skill,安装就是把文件夹放到电脑上 Agent 会读取的固定目录。以 Codex 为例,打开它的配置目录,里面有一个 skills 文件夹,每一个 Skill 就是其中的一个单独文件夹。

Codex 的 skills 目录

手动安装就是把下载下来的 Skill 解压后丢进这个目录,之后在 Codex 里输入斜杠就能看到它。但大多数时候我们不会这样手动安装,因为 Agent 本身就能执行命令、创建文件,它知道自己的 Skill 目录在哪里。可以直接对它说:

帮我从这个地址下载 Skill,安装到对应目录,再检查是否能读取。

它会把文件放到正确的位置。

Skill 的两个作用

Skill 的作用可以分成两个。

Skill 的两个作用

一是固化工作流,把每天或者经常要执行的重复步骤、检查和交付方式保存下来。比如我有一个做 PPT 的 Skill,里面是一套 PPT 样式规范;还有一个生图的 Skill,能生成小狗和火柴人风格的配图。如果每次都用一大段话重新描述图片风格、小人和小狗长什么样,成本很高,这种流程就适合固化成 Skill。

二是补充 Agent 原本没有的知识。模型不是万能的,比如让它做视频爆款分析,它每次都拆解得不到位。这时可以把我们自己拆解视频的经验写成 Skill,让它每次先读取:要看哪个位置、有什么方法论、开头的 Hook 怎么样、时长和拍摄风格怎么判断。有了这些信息,任何模型都能被更好地指导。

知道这两个作用之后,就可以排除掉一些没有太大作用的 Skill。比如把九九乘法表做成 Skill,没办法提升模型的数学能力;还有一些写得很通用的 UI/UX 指导,只说「你是一个顶级设计师」,没有具体规范,模型能力差的还是差,能力强的本来就不需要。Skill 越通用,对具体某一件事的作用就越小。

怎么创建 Skill

一般我们不会手写 Skill,格式规范不需要深入了解,创建都是让 Agent 来完成。比如在 Codex 里输入斜杠,触发 Skill Creator,告诉它要创建一个什么样的 Skill,它就会创建好并放到对应的文件夹里。

Codex 里的 Skill Creator

我自己的习惯是,先在没有 Skill 的情况下完成一项任务,比如让 Agent 做出一个 PPT,然后再用 Skill Creator 让它复盘整个过程:路径是怎样的、踩了哪些坑。这样下次新开话题时,Agent 虽然没有历史信息,但读取 Skill 之后就能快速获得一部分高质量的上下文,再开始执行任务。

Skill 不是创建出来就完事了,要经常试。每次新开话题调用它,如果执行结果没有达到预期,第一件事应该是优化 Skill,然后再基于新的 Skill 重新执行这一次的任务。我们要减少的是未来的使用成本。

怎么测试 Skill

测试也可以交给 Agent。以前需要手动开两个空话题,一个触发 Skill、一个不触发;现在 Codex 这类 Agent 有子 Agent 功能,可以让它启动两个子 Agent,一个不读取 Skill,一个读取,再给它们同一个任务,对比产出的结果。

用子 Agent 对比测试 Skill

我有一个让文案写得更好的 Skill,就是这样打磨的:给定一个主题,让没有 Skill 的子 Agent 写一段、有 Skill 的写一段,我来判断哪一段好、好在哪、不好在哪,再让主 Agent 按这个标准修改 Skill,然后再触发两个新的子 Agent 对比。不断重复,直到读取 Skill 的子 Agent 一次就能写出符合要求的文案。

刚开始测试时,可以先不让 Agent 把 Skill 安装进目录,只让它写成一个普通文件,这样对两个子 Agent 来说都没有先入为主的信息,对比才公平。

写给 Agent 看的 Skill

最后一个最佳实践:Skill 不是写给人看的,是写给 Agent 看的。

写给 Agent 看的 Skill

对 Agent 来说,上下文越简洁、越准确,执行效果越好,token 开销也越少,所以不要写得太长、太复杂、太冗余。

另外一点是,能用程序固定的步骤就交给程序。以我的封面 Skill oil-cover 为例,它有两种执行模式。

在 Codex 中使用 oil-cover

一种是脚本模式。生成封面的流程很固定:读取视频、选出一帧、生成提示词、把参考图和提示词一起交给生图模型。这些步骤我用脚本固化下来,Agent 不需要读一份很长的文档再一步一步执行,只要调用脚本、把视频信息交给它,就能直接生成封面。脚本模式里我接入了外部的生图模型;在 Codex 里,则会调用它的 image_gen 工具。

另一种是 Agent 自主执行模式,由 Agent 按规范自己完成选帧、分析和生图,最后同样调用项目脚本来合成封面。

oil-cover 的两种执行模式

脚本模式一定更稳定,但使用成本更高,因为需要接入外部模型。如果只有一个 Agent 工具,就用 Agent 自主执行模式,对使用这个 Skill 的人来说也更友好。

更多内容

这期讲到的内容,我都同步到了 VibeHub(vibe-hub.org)的 Skill 概念页里,怎么安装、Skill 的作用、怎么创建、怎么测试都可以在里面查看。

VibeHub 的 Skill 概念页

Skill 的创建成本很低,相比下载现成的 Skill,自己定制的 Skill 掌握度更高,也更契合自己的实际工作流程。