首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >从 0 到 1:WorkBuddy 手把手教你做出第一个 Skill(小白 10 分钟上手)

从 0 到 1:WorkBuddy 手把手教你做出第一个 Skill(小白 10 分钟上手)

原创
作者头像
用户12729432
发布2026-09-03 14:10:42
发布2026-09-03 14:10:42
180
举报

从 0 到 1:WorkBuddy 手把手教你做出第一个 Skill(小白 10 分钟上手)

正在上传图片...

摘要:很多人用 AI 半年,还停留在"每次重新描述一遍需求"的阶段。Skill 就是把一次成功做事的方法固化下来,让 AI 下次自动照做的能力。本文从"Skill 到底是什么"讲起,用一条完整的实操主线,带你 10 分钟做出第一个能用的 Skill,并给出 7 条让 Skill 真正好用的经验、一份质检清单和一张踩坑对照表。全文面向零基础读者,不需要写一行复杂代码。

一、先别急着动手:你可能早就在"用"Skill 了

先问三个问题,看看你中了几条。

第一,同一个需求你跟 AI 说过很多遍。比如每周都要把一堆日报整理成周报,每次都要重新讲一遍格式要求:「按客户维度分组、每条不超过 30 字、最后加风险提示」。讲完 AI 做得还行,下周又得重讲一遍。

第二,AI 的输出不稳定。同样一句话,今天生成的结果结构清晰,明天就跑偏了。你隐约觉得"应该有个固定说法",但这个说法只在你脑子里,没落到纸面上。

第三,好方法没法传给同事。你摸索出一套好用的提问套路,同事问你怎么做的,你只能截几张聊天记录发过去,对方照着做还是做不出一样的效果。

这三条背后是同一个问题:你的经验没有被固化,只停留在单次对话里。

Skill 解决的就是这件事。它把"你希望 AI 怎么做某件事"写成一份结构化说明书,放进固定目录。下次 AI 遇到匹配的场景,会自动读取这份说明书,按你定的规矩干活。你不用再重复解释,同事拿到这份文件也能得到一致的结果。

二、Skill 到底是什么:一句话 + 三层认知

先给一句大白话定义:

Skill = 把一次成功的做事方法,打包成一份 AI 能自动识别并加载的说明书。

为了理解它和普通对话的区别,可以把它看成三层递进。

最底下这层是单次对话。你临时问一句,AI 临时答一句,说完就散,没有留存。这是我们最熟悉的模式。

中间这层是提示词模板。你把好用的提问方式记在备忘录里,下次复制粘贴出来改一改再用。这已经前进了一步——经验被留存了。但问题是要人工复制,AI 不会自己知道该用哪个模板。

最上面这层就是 Skill。提示词模板被放进约定好的目录,配上一个"触发条件说明"。AI 在开工前会先扫一眼所有 Skill 的说明,判断哪个和当前任务相关,相关就自动加载执行。从"人去找模板"变成了"AI 自己找模板",这是质变。

Skill 与普通对话、提示词模板的三层关系
Skill 与普通对话、提示词模板的三层关系

用一个表格把三者的差别摊开看:

对比项

单次对话

提示词模板

Skill

经验是否留存

谁来决定用不用

AI 自动判断

能否携带脚本/资料

不能

不能

能否团队共享

只能发截图

复制文本

复制文件夹

结果一致性

这里最关键的一行是"谁来决定用不用"。正因为 AI 会自动判断,你才不用在每天的工作里反复提醒它,这才是 Skill 真正的价值。

三、最小可用 Skill:其实只需要一个文件

很多人以为做 Skill 很复杂,要写代码、要配环境。不是的。

一个能跑起来的 Skill,最少只需要一个文件SKILL.md

它就是一份 Markdown 文档,开头有一段固定格式的"头信息"(frontmatter),用来告诉 AI 这个 Skill 叫什么、什么时候该用。下面这张图是完整 Skill 包的典型目录结构——但请注意,除了 SKILL.md,其他全是可选的:

一个 Skill 包的典型目录结构
一个 Skill 包的典型目录结构

一个最小可用的 SKILL.md 长这样:

代码语言:markdown
复制
---
name: weekly-report-summary
description: 从销售易 CRM 的销售日报中提取本周各自然工作日的工作内容,并按固定格式生成本周工作周报。当用户要求「总结本周工作情况」「生成本周周报」「本周日报汇总」时使用。
---

# 本周工作周报生成

## 工作流程

1. 调用 CRM 接口,拉取本周(周一至周日)所有自然工作日的日报记录。
2. 按「客户 / 项目」维度对日报内容归类,剔除重复项。
3. 每类输出 3-5 条要点,每条不超过 30 字,用动宾结构。
4. 末尾追加「风险与待办」小节,只列尚未闭环的事项。

## 输出格式

按以下结构输出 Markdown:

## 一、本周概览
## 二、重点进展
## 三、风险与待办

## 注意事项

- 只使用可核实的真实数据,禁止杜撰客户名称与数字。
- 无法核实的内容统一标注「待补充」。

就这么简单。这个文件放到指定目录,一个 Skill 就成了。

有三点必须说清楚,这是新手最容易翻车的地方。

第一,name 只能用小写字母、数字和连字符。 不要用大写、不要用中文、不要有空格。规范写法是 weekly-report-summary 这种短横线风格。

第二,description 是整个 Skill 唯一也是最重要的"广告位"。 AI 判断要不要用某个 Skill,靠的就是读这段描述。所以描述里一定要写清两件事:这个 Skill 做什么 + 什么情况下该用它。上面示例里"当用户要求「总结本周工作情况」时使用"这句就是触发条件,千万不要省。很多人的 Skill 从来不生效,八成是描述写得太笼统,AI 判断不出来。

第三,正文里不要写"你应该怎么做",要写"具体做哪几步"。 模糊的建议对 AI 没有约束力。写"注意排版美观"没用,要写"每条不超过 30 字、用动宾结构"。

顺带搞清楚:Skill 该放在哪里

新手的第二个高频疑问是目录。Skill 通常有两个存放层级,区别很简单。

用户级目录~/.workbuddy/skills/)里的 Skill,对你所有项目、所有对话都生效。适合放那些通用能力,比如"周报生成""会议纪要整理""文档格式排版"。这类 Skill 你希望它随时随地待命。

项目级目录(项目根目录下的 .workbuddy/skills/)里的 Skill,只在当前项目里生效。适合放和特定业务强绑定的东西,比如"按我们公司模板生成方案文档""查这个客户的 CRM 记录"。这类 Skill 换个项目就没意义,放用户级反而会干扰其他项目的判断。

选择原则只有一条:通用能力放用户级,业务专属放项目级。 拿不准的时候,先放项目级——它的影响范围小,出错也不会污染其他场景;用熟了、确认通用,再挪到用户级。

四、10 分钟实操:让 AI 帮你写出第一个 Skill

理解了原理,我们直接动手。核心思路是:不要从零写,先跑通一次人工流程,再让 AI 把这次流程总结成 Skill。

这条主线分五步,下面这张图是完整流程:

生成第一个 Skill 的五步实操流程
生成第一个 Skill 的五步实操流程

步骤 1:先人工跑通一遍

选一个你有把握、能做出正确结果的任务。比如"把这份会议纪要整理成待办清单"。

先像平时一样跟 AI 对话,反复调整,直到输出让你满意。这一步不能省——你自己都说不清"什么样算好",AI 更不可能总结出来。

跑通之后,把这次成功的对话完整保留下来,它就是生成 Skill 的原始素材。

步骤 2:让 AI 把这次流程总结成 Skill

新建一个对话,把下面这段话发给 AI(引号内的内容按需替换):

我刚刚完成了一次成功的任务:把会议纪要整理成待办清单,过程中反复调整了几轮,最终输出让我满意。现在请把这次有效的方法总结成一个 WorkBuddy 的 Skill,输出一个完整的 SKILL.md 文件内容。要求:一、name 用小写字母加连字符;二、description 里必须同时写清「这个 Skill 做什么」和「什么情况下触发」,触发条件要列举用户的可能说法;三、正文写具体操作步骤,每一步都要可检查,不要写模糊建议;四、补上输出格式模板和注意事项;五、只输出 SKILL.md 的完整内容,不要解释。

AI 会吐出一份完整的 SKILL.md。你要做的不是全盘接受,而是逐条核对自己人工跑通时的关键决策有没有被写进去。缺了就补,写歪了就改。

步骤 3:装到正确的目录

Skill 必须放在约定目录才会被识别。用下面这条命令创建目录并写入文件(路径按你的实际用户名调整):

代码语言:bash
复制
mkdir -p ~/.workbuddy/skills/meeting-todo-extractor

然后把上一步得到的 SKILL.md 存进这个文件夹。想确认是否放对位置,可以列一下:

代码语言:bash
复制
ls -la ~/.workbuddy/skills/meeting-todo-extractor/

能看到 SKILL.md 就说明安装位置没问题。

步骤 4:用一句自然语言验证

这一步是检验 Skill 是否真的生效的唯一标准。

新开一个对话,故意用很随意、不提 Skill 名字的说法,比如:"帮我把今天下午那场会的纪要整理成待办。" 观察 AI 有没有自动加载你的 Skill。

如果 AI 按你写的格式输出了,恭喜,Skill 生效了。如果它还是按自己的默认方式回答,说明 description 没写到位,回到步骤 2 改描述——99% 的"不生效"都是描述问题,不是目录问题。

步骤 5:按结果迭代

Skill 不是一次成型的。每用一次,记下哪里不满意,改成更具体的约束。

比如发现 AI 总把"待办"和"风险"混在一起,就在正文里补一条:「待办与风险必须分节,待办以动词开头,风险必须包含影响范围」。你给的约束越具体,AI 的发挥越稳定——这和带新人是一个道理。

五、进阶:给 Skill 装上脚本和资料

当你有一个 Skill 跑顺了,接下来会遇到两个新需求。

第一个:有些步骤不该让 AI 自由发挥。 比如调接口拉数据、批量改文件名、跑固定流程——这些是确定性操作,让 AI 每次临场写代码反而容易出错。解法是把它们写成脚本,放进 scripts/ 目录,让 Skill 正文里明确"执行 scripts/fetch.py 拿数据"。

代码语言:bash
复制
my-skill/
├── SKILL.md
└── scripts/
    ├── fetch_data.py
    └── format_output.py

这样 AI 只负责判断和调度,脏活累活交给脚本,稳定性和速度都会上一个台阶。

第二个:参考资料太多,全塞进 SKILL.md 会撑爆上下文。 比如一份 200 页的接口文档、一套公司排版规范。全写进主文件,AI 每次加载都要读一遍,又慢又贵。

正确做法是放进 references/ 目录,在 SKILL.md 里只写一句"需要查阅接口字段时读 references/api.md"。AI 平时不读,真需要时才去翻。

这就是 Skill 设计里最重要的一条原则——渐进式披露:主文件只放"每次都要用的",脚本放"到点就执行的",参考资料放"需要时才查的"。三类内容各就各位,Skill 才能又快又准。

按使用频率分层的渐进式披露结构
按使用频率分层的渐进式披露结构

理解这条原则之后,你的 Skill 设计思路会从"把所有东西堆进一个文件",转变为"按使用频率分层存放"。这也是初级和进阶 Skill 之间最明显的分水岭——会写代码的人能做出能跑的 Skill,懂得分层的人才能做出又快又省、可以长期维护的 Skill。

六、让 Skill 真正好用的 7 条经验

这几条是我踩过坑之后总结的,按重要性排序。

1. description 是唯一的广告位,值得花一半时间打磨。 判断标准是:把你可能的说法都写进去。别只写"处理周报",要写"当用户要求总结本周工作情况、生成本周周报、本周日报汇总时使用"。

2. 一个 Skill 只做一件事。 不要做一个"文档全能助手"。任务边界越窄,description 越好写,触发越精准,输出越稳定。做五个各管一摊的小 Skill,远好过一个什么都管的大 Skill。

3. 该写死的写死,该留白的留白。 格式、字段、步骤顺序这类必须一致的东西,写死。措辞、举例、表达方式这类需要因地制宜的,留给 AI 判断。全都写死,Skill 会很僵;全都不写,Skill 等于没有。

4. 给出输入输出样例。SKILL.md 末尾附一个"输入样例 → 输出样例",比写五百字说明都管用。AI 对示例的遵循度远高于对描述的遵循度。

5. 把失败路径也写进去。 大多数人只写"顺利时怎么做"。真正拉开差距的是写清"数据拉不到怎么办""格式对不上怎么办""用户给的材料不全怎么办"。这些边界情况写清楚了,Skill 才敢在无人值守时自动跑。

6. 用真实任务驱动迭代,不要凭空设计。 每次真实任务跑完,花两分钟把不满意的地方改回 Skill。改十次之后,它会比任何一次凭空设计的版本都好用。

7. 统一命名和归档。 建议按"用途"建目录,比如按客户、按业务线分文件夹,Skill 用动宾短语命名(extract-meeting-todogenerate-weekly-report)。三个月后你回头找,会感谢现在的自己。

8. 定期做一次"断舍离"。 Skill 和代码一样会腐坏。业务变了、接口改了、平台升级了,当初好用的 Skill 就会变成"看起来应该管用,实际跑出来全是错"的定时炸弹。建议每个月花半小时,把不常用的 Skill 过一遍:还在用的跑一次验证,三个月没用过的先归档,已经失效的直接删掉。留着一堆不知道还能不能用的 Skill,比没有 Skill 更危险——因为你会误以为它还在正常工作。

七、发布前质检清单

做完别急着用,照着这份清单过一遍:

  • name 是否只用小写字母、数字和连字符
  • description 是否同时写清了「做什么」和「什么时候用」
  • description 里是否列举了用户可能的说法(触发词)
  • 正文步骤是否每一步都可检查,没有"注意美观"这类模糊表述
  • 是否提供了输出格式模板
  • 是否写清了异常和失败情况的处理
  • 是否附带了输入输出样例
  • 脚本是否放在 scripts/,大块资料是否放进了 references/
  • 是否用「不提 Skill 名字的随意说法」验证过自动触发
  • 换一个全新对话再验证一次,确认不是偶然生效

八、踩坑与对策

把我在实际使用中遇到的高频问题整理成对照表:

现象

原因

解法

Skill 从来不自动触发

description 太笼统,AI 判断不出相关性

补齐触发条件,列举用户的真实说法

有时触发有时不触发

触发词覆盖面不够,只有部分说法能命中

把同义说法都写进 description,用逗号分隔

name 报错或找不到

用了大写、中文、空格或下划线

改成小写字母加连字符

输出每次都不一样

正文里全是模糊建议,没有硬约束

把格式、字数、结构写成可检查的硬指标

加载很慢、响应变卡

把大段参考资料全塞进了主文件

拆到 references/,主文件只留索引

关键步骤经常出错

确定性操作让 AI 临场写码

抽成 scripts/ 里的固定脚本

换台电脑就失效

Skill 放在了项目临时目录

放到用户级目录 ~/.workbuddy/skills/

同事拿到也不好用

缺少输入输出样例,各自理解不同

在末尾补一组完整样例

改了 SKILL.md 没生效

会话已加载旧版本

新开一个对话再验证

九、小结:从"会用"到"会攒"

回到开头那三个问题:重复描述、输出不稳、经验传不出去。Skill 给出的答案其实很朴素——把你已经会的东西写下来,放到 AI 能看到的地方。

它不需要你懂编程,只需要你能说清楚"这件事该怎么做"。而"说清楚"这件事本身,也是在倒逼你把经验从模糊的感觉,变成可复用、可传授的方法。

真正拉开人与人差距的,从来不是会不会用 AI,而是用完之后有没有留下点什么。每完成一个成功案例,花十分钟把它变成一个 Skill。半年下来,你就不再是一个人在用 AI,而是一支带着全套标准作业程序的团队在用。

现在就挑一个你这周重复做过两次以上的任务,按第四部分的五步走一遍。第一个 Skill 做出来之后,你会发现第二步、第三步快得超出想象。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

目录
  • 从 0 到 1:WorkBuddy 手把手教你做出第一个 Skill(小白 10 分钟上手)
    • 一、先别急着动手:你可能早就在"用"Skill 了
    • 二、Skill 到底是什么:一句话 + 三层认知
    • 三、最小可用 Skill:其实只需要一个文件
      • 顺带搞清楚:Skill 该放在哪里
    • 四、10 分钟实操:让 AI 帮你写出第一个 Skill
      • 步骤 1:先人工跑通一遍
      • 步骤 2:让 AI 把这次流程总结成 Skill
      • 步骤 3:装到正确的目录
      • 步骤 4:用一句自然语言验证
      • 步骤 5:按结果迭代
    • 五、进阶:给 Skill 装上脚本和资料
    • 六、让 Skill 真正好用的 7 条经验
    • 七、发布前质检清单
    • 八、踩坑与对策
    • 九、小结:从"会用"到"会攒"
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档