原以为制作 Skill 要写代码，结果就是写个 Markdown

AI浪潮袭来，不得不学习AI相关的知识。

最近有在学习Skill。

我想用大白话，从零到一，把制作 Skill 这件事和你们分享一下。

不装，不绕，直接上货。

01

Skill 是个什么东西？

你就把它理解成一个插件。

WorkBuddy 本身是个通用 AI 助手，什么都能聊，但什么都不算精。你让它帮你写公众号，它能写，但写出来的东西一股「AI 味」。你让它帮你做小红书，它能做，但封面排版逻辑它不懂。

为什么？因为它没有领域知识。

Skill 就是解决这个问题的。你把某个领域的知识、流程、规范、模板，打包成一个文件夹，丢给 WorkBuddy。下次你说「帮我写小红书」，它不靠自己瞎猜了，它先加载你给的 Skill，按你定义的流程和标准来干活。

一句话：Skill 是你给 AI 的说明书。

图片

你写得越清楚，它干得越漂亮。

02

一个 Skill 的结构有多简单？

很多人一听「开发 Skill」就头大，以为要写代码、配环境、搞部署。

不用。

一个最小可用的 Skill，就一个文件：

my-skill/

└──　SKILL.md

没了。就这。

你在一个文件夹里放一个 SKILL.md，它就是一个 Skill。

但如果你要做得专业一点，结构大概是：

my-skill/

├──　SKILL.md　　　　　　　　　　　　　　#　核心说明文件

├──　references/　　　　　　　　　　　　#　参考文档

│　　　├──　style-guide.md　　　　　   #　风格规范

│　　　└──　templates/　　　　　　　　　#　模板文件

├──　scripts/　　　　　　　　　　　　　　#　脚本（可选）

│　　　└──　helper.py

└──　assets/　　　　　　　　　　　　　　 #　静态资源（可选）

看到没？就是文件和文件夹。

没有编译，没有打包，没有发布流程。

改了就生效，删了就没。跟你在电脑上建个文件夹一样。

图片

03

SKILL.md 怎么写？

这是整个 Skill 的灵魂。就一个 Markdown 文件，但顶部有一段 YAML 格式的「元信息」。

长这样：

---

name:　my-skill

description:　"帮用户写小红书爆款笔记"

triggers:

　　-　写小红书

　　-　小红书文案

　　-　种草笔记

---

#　小红书写作助手

##　触发条件

当用户说「写小红书」「小红书文案」「种草笔记」时激活。

##　工作流程

1.　先确认笔记类型（种草/教程/避雷/故事）

2.　按类型选择对应模板

3.　生成正文，含开头钩子、分段骨架、结尾互动

4.　附上标签组合

重点说三个字段：

name：Skill 的唯一标识，用英文，短横线分隔，比如 xiaohongshu-writer。

description：一句话说清楚这个 Skill 干什么的。这句话会被 WorkBuddy 用来判断「用户说的这个事儿该不该激活这个 Skill」。所以别写「这是一个很有用的工具」这种废话，写具体——帮谁干什么。

triggers：触发词列表。用户说了这些词，这个 Skill 就会被加载。但这里有个很多人踩的坑：触发词不是「精准匹配」，是「语义匹配」。你写「小红书」，用户说「帮我发个红书笔记」也能触发。所以不用列 50 个同义词，列核心的几个就够了。

YAML 下面的正文，就是你写给 AI 的操作手册。

这部分你想写多详细都行。但记住一个原则：你写给 AI 看，就像写给一个聪明但不了解你行业的新同事看。它懂逻辑，但不知道你的规矩。你得把规矩写出来。

04

references 有什么用？

SKILL.md 是「操作手册」，references 是「参考资料库」。

为什么要分开？

因为 SKILL.md 每次激活都会被加载到对话上下文里，吃 token。你如果把所有模板、规范、案例都塞进 SKILL.md，每次激活都烧一大笔上下文。

所以策略是：

SKILL.md：放流程、规则、关键判断逻辑。精简，控制在 2000 字以内。

references/：放详细规范、模板、案例、风格指南。按需加载，用到的时候才读。

比如你做一个小红书 Skill，SKILL.md 里写「按种草模板生成正文」，然后 references/templates/seed.md 里放具体的模板结构。AI 执行到那一步，会自己去读模板文件。

这就是 Skill 的核心设计哲学：主干精简，枝叶按需。

图片

05

脚本和资源什么时候用？

不是每个 Skill 都需要脚本。

如果你的 Skill 只是「给 AI 一套规则让它按规则干活」，那纯 Markdown 就够了。

但如果你需要：

• 调用外部 API 获取数据

• 执行某种计算或转换

• 操作本地文件（读、写、复制）

• 运行某个命令行工具

那就需要脚本了。

脚本放 scripts/ 目录，Python、Node 都行。AI 在执行 Skill 时，可以通过 Bash 工具调用这些脚本。

assets/ 目录放静态资源，比如图片模板、字体文件、JSON 数据。

但 80% 的 Skill 用不到这两个目录。别为了「看起来专业」而硬加脚本，简单的东西保持简单。

06

Skill 放哪里？

两个位置：

用户级：~/.workbuddy/skills/你的skill名/

对你所有项目生效。你做的通用 Skill（比如「公众号写作助手」）放这里。

项目级：你的项目/.workbuddy/skills/你的skill名/

只对当前项目生效。团队共享的项目专属 Skill 放这里。

没有优劣，按作用范围选。

07

怎么测试？

三个字：直接聊。

Skill 不需要「编译」「部署」「上线」。你把文件夹放好，回到 WorkBuddy 对话，说一句触发词，看它有没有按你的规则干活。

没触发？检查 triggers 写得对不对。

触发了但执行得不对？打开 SKILL.md，看看是不是哪里写得不够清楚。

记住：AI 不按你想的干，永远是你写得不够清楚，不是它不够聪明。

你把规则改清楚，再聊一次，立刻验证。

这个循环：改 → 聊 → 看 → 再改，就是 Skill 开发的全部。

图片

08

几个让你少走弯路的建议

第一，先手写一遍流程再写 Skill。

别一上来就写 SKILL.md。先拿张纸，把你脑子里「怎么干这件事」的流程手写一遍。第一步干啥，第二步干啥，遇到什么情况怎么判断。

手写完了，你自然就知道 SKILL.md 该写什么了。

第二，先做最小可用版本。

别一上来就做「完美 Skill」。先写个 50 行的 SKILL.md，能跑通主流程就行。然后在用中发现问题，迭代。

Skill 不是一次性工程，是持续打磨的东西。

第三，抄。

去 ~/.workbuddy/skills/ 里看看已有的 Skill 是怎么写的。结构怎么组织的，触发词怎么设的，references 怎么用的。

别人踩过的坑你不用再踩一遍。

第四，description 是最重要的字段。

不是 SKILL.md 正文，是 YAML 里的那一行 description。因为这是 WorkBuddy 用来做语义匹配的核心依据。你写得越准确，激活就越精准，不会乱触发也不会漏触发。

好，总结一下。

Skill 制作的本质是什么？

把你的专业知识结构化，写成 AI 能理解的规则，让它在特定场景下按你的标准干活。

文件结构就那么几个，SKILL.md 是核心，references 是补充，scripts 和 assets 按需加。放到对的位置，用触发词测试，迭代优化。

没有什么门槛。

你现在就可以打开终端，建一个文件夹，写一个 SKILL.md，然后回到 WorkBuddy 试一下。

五分钟，你的第一个 Skill 就上线了。

别等「准备好了」再开始，永远准备不好的。

直接干。