Skill指南：如何从0开始构建一个属于自己的 Skill？

作者：Eian

我们每天刷 X，都能看到各种各样的 Skill。

去AI味的、生成图片的、写文章的、做视频的……..

这些 Skill都很好，但有一个不可忽略的问题

这些Skill都是别人按自己的视角和习惯做的。

而我们每个人的工作方式和习惯本就是千差万别的。

所以再好用的 Skill，拿到你手里都可能会水土不服。

这时候你肯定想过：为什么我不自己做一个？

从使用者，变成创作者。

你可能会觉得 Skill 太复杂，或者想做，但理不清头绪，不知道从哪下手。

而这篇文章就解决两个问题：

第一，给 Skill" 祛魅"，让你从0开始全面了解skill

第二，说清楚怎么从 0 做出一个属于自己的 Skill。

但在动手之前，还是有必要先搞懂它是什么。

Skill，说白了就是一份给 Agent 的说明书。

事情的背景是什么？一件事应该怎么干？遇到问题怎么处理？干到哪一步算完？有什么注意事项？

把这些问题的答案，加上你脑子里的经验、你的习惯，都沉淀成固定的规则，

然后把它们写出来，打包。这就是 Skill。

以后 AI 遇到同类任务，

就可以直接把这份手册直接翻出来看。

然后按照流程推进、最终交付成品，不需要每次重复交代

所以Skill 不是什么高科技，就是"一次写好、反复调用"的经验包。

明白了skill是什么，再来看看Skill 的结构。

做 Skill，最怕的就是一个 SKILL.md 写到底。

几十行还行，超过 200 行，AI每次都要全部看完，没必要、而且极难维护。

这时候就要学会模块化设计。为了便于理解，我用一个"周报助手"Skill举例子。

一个 Skill 的标准骨架（模块）大致如下：

my-skill/
├── SKILL.md          # 必需：Skill 的门面 + 核心指令
├── references/       # 可选：详细的领域知识文档
├── scripts/          # 可选：确定性操作脚本
├── examples/         # 可选：输入输出示例
└── assets/           # 可选：模板、字体等静态资源

每个模块负责什么，我一个一个说。

SKILL.md：这是一个skill最核心的文件，相当于名片+大脑

这是skill必需要有的文件，

对外，它是 Skill 的"名片"

"名片" 就相当于告诉ai，我是做什么的。

例如周报skill就是帮用户写工作周报的，以后当用户说"写周报""整理这周工作""周五了"这样的触发词的时候，AI 就知道调用周报skill完成这份工作。

这里有一个铁律：一定要说清楚这个skill用来做什么，以及什么时候用这个skill。

把触发词写进去，参考我们平时是怎么跟 AI 说这件事的——"写周报""整理这周工作""周五了"，这些触发词。

AI 就靠这些触发词来判断该调用哪个skill来处理这个工作

你写得越像人话，越详细，触发得越准。

对内，它是 AI 的"大脑"

"大脑"是指skill.md文件里有整个skill的核心指令。

包括决策原则、流程骨架、或者绝对不能做的事

第一，决策原则主要解决，AI 遇到分叉路口，怎么选。

第二，流程骨架。写清楚第一步干什么、第二步干什么…….

比如："先收集信息，再分类整理，然后撰写，最后检查

这就是流程。

第三，写清楚绝对不能做的事。

需要注意的是，SKILL.md 只放做决策必须知道的东西，最好不超过500行。

references/：知识库

放那些"需要的时候才看"的东西。

比如行业术语表、政策文档、详细规范、FAQ、历史案例。

拿周报助手skill举例：

• 术语表.md：部门的黑话，"闭环""抓手""颗粒度"到底指什么。
• 老板偏好.md：老板最关心哪几个数字，最烦什么样的表达。

这里有个讲究，references并不是指一个文件，刚刚我们提到的术语表.md/老板偏好.md，都是单独文件，一个文件一个主题，而这些文件都放在references目录下。

AI 在执行过程中，需要了解哪方面知识就去翻对应的文件。就行。

而在SKILL.md 文件里，只需要交代一句话："部门黑话不确定的时候，去看 references/术语表.md。"

而不是把术语表全文抄进 SKILL.md，这就是模块化设计。也是skill.md决策功能的体现。

scripts/：确定性的操作脚本

什么叫确定性？

就是每次执行都一模一样、错一步都不行的事。

比如格式转换、数据清洗、批量重命名、从聊天记录里提取日期和事项。

这种事如果让 AI 自由发挥。发挥 10 次，它能给你 10 个不同的格式。

写成脚本，又快又不会错，AI 只需要负责"调用"，不用负责思考。

脚本怎么写？记住一个约定：输入输出要傻瓜化。

比如 汇总.py，输入是一个文本文件，输出是整理好的事项列表。

SKILL.md 里写清楚："收集完聊天记录后，运行 python scripts/汇总.py 聊天记录.txt，把结果作为分类整理的输入。"

AI 照着执行就行，不用理解脚本内部。

那什么时候该用脚本，什么时候让 AI 自由发挥？

其实一句话就可以判断：凡是"对了就行，错了就完"的环节，上脚本。

凡是"没有标准答案，靠经验判断"的环节，让 AI 发挥。

examples/：样板间

放一两个输入输出的例子，配对放。

比如 输入-聊天记录.txt 是一段乱糟糟的聊天记录，输出-周报样例.md 是整理好的周报。

AI 看这样的例子比看文字描述学得快得多。

你想让它输出什么格式，直接给个样例，比写500字描述词管用。

assets/：仓库

模板文件、图片、字体、Logo 这些静态资源统一放这里。

比如你们部门周报有固定的 Word 模板，

脚本里需要用到的，只需要一句话引用路径就行：

"最后用 assets/周报模板.docx 的样式输出。"

五个模块怎么配合？

再串一遍，一个任务进来之后发生了什么：

1. 用户说"帮我写周报"，AI 读到 SKILL.md 的 description，对上了，Skill 激活。
2. AI 读 SKILL.md 正文，知道流程骨架和雷区。
3. 收集信息时，跑 scripts/汇总.py，把聊天记录变成事项列表。
4. 写正文时，翻 references/老板偏好.md，确认老板关心的数字；看 examples/输出-周报样例.md，确认格式。
5. 最后套用 assets/周报模板.docx 输出。

大脑做决策，手干活，知识库备查，样板间定标准，仓库出物料。

各干各的，互不添乱，这就是模块化。好管理、好修改、还不乱。

理解了模块化，还要知道 AI 是怎么读Skill 的。

我把它叫"渐进式披露"，一共分三层：

• 第一层：只看名字和 description，决定用不用这个 Skill

所以 description 是门面，

• 第二层：Skill 被选中了，继续读 SKILL.md 的正文。如果没选中直接换下一个，正文不读了。
• 第三层：执行过程中，按需读取 references 和 scripts。

这个机制核心就一件事：千万不能把所有东西都塞进SKILL.md。

SKILL.md 超过 500 行，你的skill也能跑，但设计上就失败了。

现在我们就可以开始一步一步做skill了，还是拿周报skill举例子。

一共7步

第一步：梳理流程

在开始动手之前，先自己把这件事之前的流程梳理清楚。

比如周报skill

自己写周报是怎么做的，先看了什么？然后做了什么？格式有什么要求？老板最关心什么？你踩过什么坑？

全部记下来，流水账就行，不用整理的非常仔细。

这一步其实非常关键，也最容易被跳过。

不要一上来就写 SKILL.md，写出来的全是空话。

核心就一个：Skill 的原材料，是你的真实流程。

第二步：写成自然语言步骤

把流水账整理一下，分成几个阶段。

收集信息 → 分类整理 → 撰写正文 → 检查提交。

建议用"先……然后……最后……"的句式，能看懂就行。

第三步：补上格式和雷区

你的周报有固定格式吗？有字数限制吗？

有没有雷区？比如"没确认的项目不能写""数据必须和系统对上"。这些绝对不能犯的错误也需要写清楚。

雷区这部分非常重要。

第四步：写 SKILL.md

前面三步的原材料齐了之后，现在就可以往骨架里填了。

SKILL.md文件的结构大概分为以下几个板块：

-description：写清楚做什么、什么时候用，触发词写全。

决策原则：把第一步里那些"怎么选"的经验写进去。

流程骨架：把第二步的阶段放进去。

雷区：把第三步的"绝对不能做"放进去。

第五步：按需加上其他模块

SKILL.md 跑起来之后，就可以开始测试了，哪里卡 或者哪里别扭再改。

AI 总搞错部门黑话？加 references/术语表.md。

格式每次都不一样？加 examples/输出样例。

数据整理又慢又错？写个 scripts/汇总.py。

有固定模板？扔进 assets/。

但是不建议五个模块全做，先从最小版本跑起来。稳定之后在一步一步加模块。

第六步：测试

开一个新对话，说"帮我写周报"。

AI 按你的流程执行了，那恭喜你，这个skill就成了。

没自动触发这个Skill，大概率是description没写对，看看是不是触发词是不是写少了、写窄了。

触发了但做得不对？先看是不是流程没讲清，还是缺样例、缺知识库，缺哪里补哪里，然后再测试。

第七步：迭代

Skill 是活的，不是写完就扔的。

多用多测试，哪里别扭改哪里。

改 description、加 reference、补 example，都是日常操作。

一个好用的 Skill，都是要经过多轮修改改出来的，不是一次写出来的。

整个过程，写个简单的skill ，大概15 到 30 分钟。

如果看完这篇文章还是不会，我准备一篇浓缩全文精华的提示词，直接复制给你的Agent就行。

你是一名 Skill 架构师，任务是帮我从 0 创建一个属于我自己的 Skill。
Skill 由五个模块组成，你要按这个骨架来设计：
第一，SKILL.md，这是唯一必需的文件，一身兼两职——对外它是"名片"，所以 description 必须写清楚触发场景和解决什么问题，不能写空话；
对内它是"大脑"，正文只放决策必需的核心指令、流程骨架和硬性红线，控制在 500 行以内，
把所有东西都塞进 SKILL.md 是设计失败。
第二，references/，这是"知识库"，执行中按需读取的背景知识，一个主题一个文件，比如术语表、偏好记录。
第三，scripts/，这是"手"，凡是每次都要一字不差重复执行的操作，写成确定性脚本，并写清输入输出约定。
第四，examples/，这是"样板间"，一对输入输出样例胜过五百字描述，至少给一组。
第五，assets/，这是"仓库"，放模板、图片、字体等静态资源。
不是每个 Skill 都需要五个模块，默认只建 SKILL.md，确实需要时才加别的。
设计时必须遵守"渐进式披露"三层读取机制：第一层 AI 只看 Skill 的名字和 description 来决定用不用；第二层被选中后才读 SKILL.md 正文；第三层执行中按需拉取 references 和 scripts。
所以信息要有层级：触发判断放 description，核心决策放 SKILL.md，细节全部下沉。
创建流程按这七步走：
先让我回忆并描述清楚我要固化的那套工作流；
然后把它写成自然语言步骤；
接着补上输出格式要求和绝对不能踩的雷区；
再写出 SKILL.md 全文；
然后判断需不需要加 references、scripts、examples、assets；
最后给我一套测试方法让我验证效果，并根据测试结果迭代。
你的交付物是：完整的目录结构、每个文件的全部内容（可直接保存使用）、以及测试和迭代建议。
现在开始：先问我，我要把哪套工作流做成 Skill。

从使用者，变成创作者。

就这么简单

但在 Skill 出现之前，它就是个伪命题。

因为你的经验，没有办法沉淀不下来。

你调好的提示词，换个任务就得重新写

Skill 干的事，就一句话：

把你验证过的工作流，写成一份 Agent 看得懂的说明书。

一份写得好的 Skill 发出去。

全世界做同样事的人，都会替你验证、替你迭代。

你的方法，就第一次有了可复制的载体

这本身就是很有成就感的一件事

所以看完这篇都可以为自己创建一个skill了

7步搞定。