这期内容讲清楚 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,安装就是把文件夹放到电脑上 Agent 会读取的固定目录。以 Codex 为例,打开它的配置目录,里面有一个 skills 文件夹,每一个 Skill 就是其中的一个单独文件夹。

手动安装就是把下载下来的 Skill 解压后丢进这个目录,之后在 Codex 里输入斜杠就能看到它。但大多数时候我们不会这样手动安装,因为 Agent 本身就能执行命令、创建文件,它知道自己的 Skill 目录在哪里。可以直接对它说:
帮我从这个地址下载 Skill,安装到对应目录,再检查是否能读取。
它会把文件放到正确的位置。
Skill 的两个作用
Skill 的作用可以分成两个。

一是固化工作流,把每天或者经常要执行的重复步骤、检查和交付方式保存下来。比如我有一个做 PPT 的 Skill,里面是一套 PPT 样式规范;还有一个生图的 Skill,能生成小狗和火柴人风格的配图。如果每次都用一大段话重新描述图片风格、小人和小狗长什么样,成本很高,这种流程就适合固化成 Skill。
二是补充 Agent 原本没有的知识。模型不是万能的,比如让它做视频爆款分析,它每次都拆解得不到位。这时可以把我们自己拆解视频的经验写成 Skill,让它每次先读取:要看哪个位置、有什么方法论、开头的 Hook 怎么样、时长和拍摄风格怎么判断。有了这些信息,任何模型都能被更好地指导。
知道这两个作用之后,就可以排除掉一些没有太大作用的 Skill。比如把九九乘法表做成 Skill,没办法提升模型的数学能力;还有一些写得很通用的 UI/UX 指导,只说「你是一个顶级设计师」,没有具体规范,模型能力差的还是差,能力强的本来就不需要。Skill 越通用,对具体某一件事的作用就越小。
怎么创建 Skill
一般我们不会手写 Skill,格式规范不需要深入了解,创建都是让 Agent 来完成。比如在 Codex 里输入斜杠,触发 Skill Creator,告诉它要创建一个什么样的 Skill,它就会创建好并放到对应的文件夹里。

我自己的习惯是,先在没有 Skill 的情况下完成一项任务,比如让 Agent 做出一个 PPT,然后再用 Skill Creator 让它复盘整个过程:路径是怎样的、踩了哪些坑。这样下次新开话题时,Agent 虽然没有历史信息,但读取 Skill 之后就能快速获得一部分高质量的上下文,再开始执行任务。
Skill 不是创建出来就完事了,要经常试。每次新开话题调用它,如果执行结果没有达到预期,第一件事应该是优化 Skill,然后再基于新的 Skill 重新执行这一次的任务。我们要减少的是未来的使用成本。
怎么测试 Skill
测试也可以交给 Agent。以前需要手动开两个空话题,一个触发 Skill、一个不触发;现在 Codex 这类 Agent 有子 Agent 功能,可以让它启动两个子 Agent,一个不读取 Skill,一个读取,再给它们同一个任务,对比产出的结果。

我有一个让文案写得更好的 Skill,就是这样打磨的:给定一个主题,让没有 Skill 的子 Agent 写一段、有 Skill 的写一段,我来判断哪一段好、好在哪、不好在哪,再让主 Agent 按这个标准修改 Skill,然后再触发两个新的子 Agent 对比。不断重复,直到读取 Skill 的子 Agent 一次就能写出符合要求的文案。
刚开始测试时,可以先不让 Agent 把 Skill 安装进目录,只让它写成一个普通文件,这样对两个子 Agent 来说都没有先入为主的信息,对比才公平。
写给 Agent 看的 Skill
最后一个最佳实践:Skill 不是写给人看的,是写给 Agent 看的。

对 Agent 来说,上下文越简洁、越准确,执行效果越好,token 开销也越少,所以不要写得太长、太复杂、太冗余。
另外一点是,能用程序固定的步骤就交给程序。以我的封面 Skill oil-cover 为例,它有两种执行模式。

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

脚本模式一定更稳定,但使用成本更高,因为需要接入外部模型。如果只有一个 Agent 工具,就用 Agent 自主执行模式,对使用这个 Skill 的人来说也更友好。
更多内容
这期讲到的内容,我都同步到了 VibeHub(vibe-hub.org)的 Skill 概念页里,怎么安装、Skill 的作用、怎么创建、怎么测试都可以在里面查看。

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