什么是skills? 如何使用skills?如何创建skills?

摘要：

很多人第一次听到 Skills，会以为它是什么复杂的 AI 插件系统。真正上手之后我发现，它最实际的价值并不是"增强模型"，而是帮我们接手那些重复解释、重复交代、重复返工的工作。本文会从三个角度来聊：Skills 到底是什么、怎么用 Codex 手搓一个 Skill，以及如何从 GitHub 下载并安装 Skill。

前几天上课，老师突然问了我一句："你最近老在说 Codex、Agent、Skills，这个 Skills 到底是什么？"我当时第一反应挺直接的：这谁不会，我玩半个月 Codex，就已经手搓了一个。当然，这句话说出口之前，我脑子里其实也停了一下。因为我知道，很多人第一次听到 Skills，下意识都会把它想得特别复杂：

• 是不是插件系统？
• 是不是得训练模型？
• 是不是得会很多底层原理？
• 是不是只有会写框架的人才能碰？

但我自己真正上手之后，发现完全不是这么回事。Skills 最有意思的地方，不是它多高级，而是它特别接地气。它干的不是"让 AI 变聪明"这件事，而是帮你把那些重复解释、重复交代、重复返工的活，一点点交给 Agent。

换句话说，以前你每次都得对 Codex 说一遍：

• 这类任务你先查什么；
• 再看什么；
• 输出格式要什么样；
• 失败了怎么兜底；
• 哪些资料要优先读。

现在你把这些东西写进一个 Skill 里，以后再遇到类似任务，它就能按你的套路来。这才是我现在对 Skills 最真实的理解：

它不是一个花里胡哨的新概念，而是一种把重复性工作交给 Agent 的方法。

---

一、什么是 Skills：它最实际的价值，是替你接手重复性工作

如果你把 Codex 理解成一个很聪明、很能干、但初来乍到的实习生，那 Skills 就像你写给它的一套老员工操作习惯。

但如果只说"它是写给 Agent 的专项工作说明书"，这句话还是有点虚。

我现在更愿意换个更直白的说法：

Skills，就是把你重复做的事情，整理成一套 Agent 能看懂、能复用、能代你执行的流程。

它的重点不是"说明书"这三个字，而是替代重复性工作。

1. 为什么说它替代的是重复性工作？

因为很多时候，真正浪费你的，不是不会做，而是你明明会做，却每次都要重新说一遍。

比如这些场景，你肯定不陌生：

• 每次让 AI 写文章，你都得重复说一遍语气、结构、标题风格；
• 每次让 AI 帮你改代码，你都得再说一遍先查报错、再看依赖、最后看端口；
• 每次让 AI 帮你整理笔记，你都得强调"不要空话、要通俗、要按考试会怎么考来写"；
• 每次让 AI 帮你装一个 GitHub 项目，你都得补一句"先看有没有 SKILL.md，再决定怎么装"。

这些事单次看都不难。

但问题就在于：你不是只做一次。

你是今天做，明天做，下周还做。你不是不会，而是懒得每次重说。

这时候，Skill 的价值就出来了。

它干的事情，本质上就是把"你每次都要重新交代"的那部分，提前固化下来。

2. 它到底替你省掉了什么？

2.1 省掉重复解释

以前你每次都要告诉 Agent：这次任务是什么，优先顺序是什么，输出长什么样，什么叫"做好了"。

有了 Skill 以后，这些要求可以默认带上。

2.2 省掉重复试错

很多任务第一次跑通以后，真正值钱的不是结果，而是你踩过的坑。

Skill 就是在替你把这些"踩坑经验"存下来。

2.3 省掉重复沟通

如果是你自己用，它省的是你和 Agent 的沟通成本。

如果是团队一起用，它省的是你和同事之间"我怎么做、你怎么做"这种口口相传的成本。

2.4 省掉脑力切换

有些活你不是不会，是懒得重新进入状态。

Skill 的作用，就是让 Agent 先进入状态。

3. 举几个最容易理解的例子

只讲概念，还是容易飘。不如直接看几个例子。

例子 1：代码审查

你每次都让 Agent 帮你 review 代码，但你的要求很固定：

• 先找 bug；
• 再找风险；
• 再看有没有行为回归；
• 最后看测试是不是缺。

这种固定流程就很适合做成一个 Skill。

例子 2：技术博客或公众号写作

你平时写文章有自己的习惯：

• 标题要有人味，不要教程腔；
• 开头先抛场景，不要一上来解释概念；
• 正文要用例子说话；
• 小标题不能太学术；
• 最后要能落到具体行动。

这类要求，本来就是写作工作流，最适合沉淀成 Skill。

例子 3：项目排错

比如你经常处理 Spring Boot 启动失败，那你完全可以把经验沉淀成一个 Skill：

• 先判断是构建失败还是启动失败；
• 再区分是依赖问题、端口占用、Bean 注入还是版本冲突；
• 最后按 Windows 环境给出具体命令。

这样下次再遇到类似问题，Agent 就不用从零开始猜。

例子 4：安装 GitHub 上的 Skills

比如看到一个 GitHub 仓库，第一步不是急着装，而是先判断：

• 仓库根目录有没有 SKILL.md；
• 如果没有，是不是某个子目录里有；
• 它的目录结构是不是标准 Skill；
• 能不能直接装，还是得先改造成能装的格式。

这个过程一旦重复做几次，也很适合做成 Skill。

---

二、怎么用 Codex 手搓一个 Skill：不是写插件，而是把你的做事方法拆出来

很多人第一次听说"可以自己做 Skill"，第一反应都是：

• 这是不是要会很多配置？
• 是不是得像开发插件一样搞结构？
• 是不是一上来就得写很多东西？

我一开始也这么想。

但真做过之后，我反而觉得：手搓 Skill 最难的地方，不是技术，而是你有没有把自己的做事方法说清楚。

Skill 的本质，从来不是炫技，而是把你脑子里那套"做事顺序"，变成 Agent 也能执行的一套流程。

1. 第一步：先想清楚这 3 件事

准备做一个 Skill 之前，先别急着建目录。

先回答这 3 个问题：

1. 这个 Skill 是替我做什么重复工作的？
2. 它应该在什么场景下被触发？
3. 一旦触发，它应该按什么顺序干活？

比如你要做一个"公众号写作 Skill"，那你就要想明白：

• 它是替我省掉每次重新讲写作要求这件事；
• 触发场景是"写公众号、写推文、做排版、做封面"；
• 它接手以后，要先定角度，再搭框架，再补素材，再成稿，再做图，再排版。

只有这三个问题想清楚了，后面写 SKILL.md 才不会散。

2. 第二步：用 skill-creator 把骨架搭起来

在 Codex 里，做 Skill 这件事本身，也可以交给一个"教你做 Skill"的能力去辅助。

更接近实际的叫法，一般是 skill-creator。

它给我的最大帮助，不是替我凭空写完一切，而是提醒我几个非常关键的原则：

• SKILL.md 是核心入口；
• name 和 description 决定这个 Skill 能不能被正确触发；
• 主文件不要写成大而全百科；
• 复杂内容拆进 references；
• 重复执行的动作丢进 scripts。

一个常见的 Skill 目录，大概长这样：

my-skill/
├── SKILL.md
├── references/
├── scripts/
├── assets/
└── agents/

最小可用的 Skill，甚至可以只有一个 SKILL.md。

3. 第三步：SKILL.md 不要写成"介绍文"

这一点很关键。

SKILL.md 不是写给人看的产品介绍，而是写给 Agent 看的操作手册。

Agent 真正想知道的不是概念背景，而是：

• 我什么时候该出现？
• 我出现以后先干什么？
• 中间需要读什么资料？
• 什么时候要执行脚本？
• 遇到异常怎么降级？
• 最后应该给用户什么结果？

所以写 SKILL.md 的时候，不要只写"这个 Skill 可以帮助用户完成某某任务"。

更好的写法是把流程写清楚。

4. 第四步：提示词别写虚，要像给同事下任务

很多人会这样写提示词：

帮我创建一个 Skill，用来处理某类任务。

这当然不是完全没用，但问题是，它太虚了。

更稳的写法应该像这样：

帮我创建一个 Codex Skill，用于处理微信公众号文章写作。

要求：
1. 触发场景覆盖公众号、推文、微信文章、排版、封面图。
2. 先做选题，再做框架，再做素材补充，再写正文。
3. 输出风格要像真实公众号文章，不要像教程文档。
4. 复杂规范放到 references。
5. 固定动作放到 scripts。
6. 如果用户明确给了标题，允许跳过选题。

你会发现，这种写法的结果会明显更稳。

因为它不是在"求一个答案"，而是在"布置一个流程"。

5. 第五步：真正好用的 Skill，都是边用边改出来的

第一次写出来的 Skill，大概率不会完美。

但这恰恰是正常的。

因为 Skill 这种东西，本来就不是一次性写完的，它更像你在带一个越来越顺手的长期助手。

比较实际的迭代方式是：

1. 先做最小版；
2. 用真实任务跑一次；
3. 看它哪里理解偏了；
4. 把这些偏差补成更明确的规则；
5. 把高频动作抽成脚本；
6. 把冗长说明拆进 references。

做到这里，你会发现：

做 Skill，不是在给 AI 加一个功能，而是在把你自己的工作方法产品化。

---

三、如何下载 Skills：最快的学习方式，就是先从 GitHub 拉一个下来拆

如果说自己从零做一个 Skill，是从 0 到 1。

那从 GitHub 下载别人的 Skill，就是最快的入门方式。

因为很多时候，你不是完全不会做，你只是还没见过一个"能用的 Skill"到底长什么样。

这时候最好的办法，不是继续脑补，而是先拆别人已经跑通的东西。

1. 第一步：先别急着装，先看有没有 SKILL.md

我现在看 GitHub 上的 Skill 仓库，第一反应已经不是"快装快装"，而是先判断它是不是一个标准 Skill。

最直接的判断方式，就是看：

有没有 SKILL.md

如果有 SKILL.md，再继续看它的位置。

它可能在仓库根目录，也可能在某个子目录里。

2. 第二步：最朴素的方法就是 git clone

如果你只是想先看内容、研究结构，最直接的方式就是：

git clone https://github.com/owner/repo.git

拉下来以后，先别急着运行，建议先看这几个地方：

• SKILL.md 在哪里；
• 有没有 references；
• 有没有 scripts；
• 目录结构是不是清晰；
• 这个 Skill 的触发场景是不是明确。

看懂结构以后，再决定要不要装。

3. 第三步：更适合 Codex 的方法，是直接用安装脚本装

如果你已经在 Codex 环境里，其实更顺手的方法，通常不是手动复制目录，而是直接用安装脚本从 GitHub 装。

处理这类仓库时，流程一般是：

1. 判断 SKILL.md 在根目录还是子目录；
2. 如果在根目录，就把路径当成 .；
3. 指定本地安装名；
4. 直接装进本地 skills 目录。

示例命令如下：

python C:\Users\fangxiaole\.codex\skills\.system\skill-installer\scripts\install-skill-from-github.py ^
  --repo owner/repo ^
  --path . ^
  --name my-skill ^
  --method download

这里简单解释一下几个参数：

• --repo owner/repo：GitHub 仓库名；
• --path .：Skill 所在目录，如果 SKILL.md 在根目录，就写 .；
• --name my-skill：安装到本地后的 Skill 名称；
• --method download：使用下载方式安装。

4. 第四步：不是所有仓库都能直接装

不是所有 GitHub 仓库都写得那么标准。

有些仓库更像思路集合，有些更偏别的 Agent，有些结构能用，但格式不完全兼容。

这时候也不用慌，只要抓住几个核心判断点：

• 有没有 SKILL.md；
• frontmatter 里有没有基础字段；
• 正文是不是在描述触发条件和执行流程；
• 整个目录能不能被独立拎出来使用。

如果这些都具备，那很多仓库即使不能直接装，也能稍微改一下再装。

5. 第五步：装完以后别忘了重新加载

很多人会遇到一种情况：

明明已经装好了，本地目录也在，但用起来没反应。

这时候先别急着怀疑是不是装错了，很有可能只是因为 Agent 还没有重新加载到新的 Skill。

所以最稳妥的动作就是：

装完以后，让 Codex 重新加载 Skills。

---

四、回头再看：Skills 到底解决了什么问题？

写到这里，我们再回头看开头那个问题：

"Skills 到底是什么？"

我的理解是：

Skills 不是一个听起来很高级、但离你很远的 AI 概念。它更像是一种很朴素的能力：把你那些已经做熟了、但又总在重复的工作，一步步交给 Agent。

你负责把标准、顺序、经验和边界整理出来。

它负责在下一次、下下次、以后很多次，都按这个套路替你执行。

所以 Skills 真正值钱的地方，从来不是"新功能"。

而是它让你开始有机会把自己的工作方法沉淀下来，把脑子里那些原本只能靠口头重复交代的东西，慢慢变成一个可以复用、可以分享、甚至可以持续迭代的能力包。

以前是你在反复指挥 AI 干活。

后来你会做 Skills 以后，就开始轮到 AI 替你接重复活了。

---

总结

Skills 的本质，是把你已经跑通的工作经验，变成 Agent 下一次可以直接复用的能力。