正在上传图片...
摘要:很多人用 AI 半年,还停留在"每次重新描述一遍需求"的阶段。Skill 就是把一次成功做事的方法固化下来,让 AI 下次自动照做的能力。本文从"Skill 到底是什么"讲起,用一条完整的实操主线,带你 10 分钟做出第一个能用的 Skill,并给出 7 条让 Skill 真正好用的经验、一份质检清单和一张踩坑对照表。全文面向零基础读者,不需要写一行复杂代码。
先问三个问题,看看你中了几条。
第一,同一个需求你跟 AI 说过很多遍。比如每周都要把一堆日报整理成周报,每次都要重新讲一遍格式要求:「按客户维度分组、每条不超过 30 字、最后加风险提示」。讲完 AI 做得还行,下周又得重讲一遍。
第二,AI 的输出不稳定。同样一句话,今天生成的结果结构清晰,明天就跑偏了。你隐约觉得"应该有个固定说法",但这个说法只在你脑子里,没落到纸面上。
第三,好方法没法传给同事。你摸索出一套好用的提问套路,同事问你怎么做的,你只能截几张聊天记录发过去,对方照着做还是做不出一样的效果。
这三条背后是同一个问题:你的经验没有被固化,只停留在单次对话里。
Skill 解决的就是这件事。它把"你希望 AI 怎么做某件事"写成一份结构化说明书,放进固定目录。下次 AI 遇到匹配的场景,会自动读取这份说明书,按你定的规矩干活。你不用再重复解释,同事拿到这份文件也能得到一致的结果。
先给一句大白话定义:
Skill = 把一次成功的做事方法,打包成一份 AI 能自动识别并加载的说明书。
为了理解它和普通对话的区别,可以把它看成三层递进。
最底下这层是单次对话。你临时问一句,AI 临时答一句,说完就散,没有留存。这是我们最熟悉的模式。
中间这层是提示词模板。你把好用的提问方式记在备忘录里,下次复制粘贴出来改一改再用。这已经前进了一步——经验被留存了。但问题是要人工复制,AI 不会自己知道该用哪个模板。
最上面这层就是 Skill。提示词模板被放进约定好的目录,配上一个"触发条件说明"。AI 在开工前会先扫一眼所有 Skill 的说明,判断哪个和当前任务相关,相关就自动加载执行。从"人去找模板"变成了"AI 自己找模板",这是质变。

用一个表格把三者的差别摊开看:
对比项 | 单次对话 | 提示词模板 | Skill |
|---|---|---|---|
经验是否留存 | 否 | 是 | 是 |
谁来决定用不用 | 人 | 人 | AI 自动判断 |
能否携带脚本/资料 | 不能 | 不能 | 能 |
能否团队共享 | 只能发截图 | 复制文本 | 复制文件夹 |
结果一致性 | 低 | 中 | 高 |
这里最关键的一行是"谁来决定用不用"。正因为 AI 会自动判断,你才不用在每天的工作里反复提醒它,这才是 Skill 真正的价值。
很多人以为做 Skill 很复杂,要写代码、要配环境。不是的。
一个能跑起来的 Skill,最少只需要一个文件:SKILL.md。
它就是一份 Markdown 文档,开头有一段固定格式的"头信息"(frontmatter),用来告诉 AI 这个 Skill 叫什么、什么时候该用。下面这张图是完整 Skill 包的典型目录结构——但请注意,除了 SKILL.md,其他全是可选的:

一个最小可用的 SKILL.md 长这样:
---
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 通常有两个存放层级,区别很简单。
用户级目录(~/.workbuddy/skills/)里的 Skill,对你所有项目、所有对话都生效。适合放那些通用能力,比如"周报生成""会议纪要整理""文档格式排版"。这类 Skill 你希望它随时随地待命。
项目级目录(项目根目录下的 .workbuddy/skills/)里的 Skill,只在当前项目里生效。适合放和特定业务强绑定的东西,比如"按我们公司模板生成方案文档""查这个客户的 CRM 记录"。这类 Skill 换个项目就没意义,放用户级反而会干扰其他项目的判断。
选择原则只有一条:通用能力放用户级,业务专属放项目级。 拿不准的时候,先放项目级——它的影响范围小,出错也不会污染其他场景;用熟了、确认通用,再挪到用户级。
理解了原理,我们直接动手。核心思路是:不要从零写,先跑通一次人工流程,再让 AI 把这次流程总结成 Skill。
这条主线分五步,下面这张图是完整流程:

选一个你有把握、能做出正确结果的任务。比如"把这份会议纪要整理成待办清单"。
先像平时一样跟 AI 对话,反复调整,直到输出让你满意。这一步不能省——你自己都说不清"什么样算好",AI 更不可能总结出来。
跑通之后,把这次成功的对话完整保留下来,它就是生成 Skill 的原始素材。
新建一个对话,把下面这段话发给 AI(引号内的内容按需替换):
我刚刚完成了一次成功的任务:把会议纪要整理成待办清单,过程中反复调整了几轮,最终输出让我满意。现在请把这次有效的方法总结成一个 WorkBuddy 的 Skill,输出一个完整的 SKILL.md 文件内容。要求:一、name 用小写字母加连字符;二、description 里必须同时写清「这个 Skill 做什么」和「什么情况下触发」,触发条件要列举用户的可能说法;三、正文写具体操作步骤,每一步都要可检查,不要写模糊建议;四、补上输出格式模板和注意事项;五、只输出 SKILL.md 的完整内容,不要解释。
AI 会吐出一份完整的 SKILL.md。你要做的不是全盘接受,而是逐条核对自己人工跑通时的关键决策有没有被写进去。缺了就补,写歪了就改。
Skill 必须放在约定目录才会被识别。用下面这条命令创建目录并写入文件(路径按你的实际用户名调整):
mkdir -p ~/.workbuddy/skills/meeting-todo-extractor然后把上一步得到的 SKILL.md 存进这个文件夹。想确认是否放对位置,可以列一下:
ls -la ~/.workbuddy/skills/meeting-todo-extractor/能看到 SKILL.md 就说明安装位置没问题。
这一步是检验 Skill 是否真的生效的唯一标准。
新开一个对话,故意用很随意、不提 Skill 名字的说法,比如:"帮我把今天下午那场会的纪要整理成待办。" 观察 AI 有没有自动加载你的 Skill。
如果 AI 按你写的格式输出了,恭喜,Skill 生效了。如果它还是按自己的默认方式回答,说明 description 没写到位,回到步骤 2 改描述——99% 的"不生效"都是描述问题,不是目录问题。
Skill 不是一次成型的。每用一次,记下哪里不满意,改成更具体的约束。
比如发现 AI 总把"待办"和"风险"混在一起,就在正文里补一条:「待办与风险必须分节,待办以动词开头,风险必须包含影响范围」。你给的约束越具体,AI 的发挥越稳定——这和带新人是一个道理。
当你有一个 Skill 跑顺了,接下来会遇到两个新需求。
第一个:有些步骤不该让 AI 自由发挥。 比如调接口拉数据、批量改文件名、跑固定流程——这些是确定性操作,让 AI 每次临场写代码反而容易出错。解法是把它们写成脚本,放进 scripts/ 目录,让 Skill 正文里明确"执行 scripts/fetch.py 拿数据"。
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。
这几条是我踩过坑之后总结的,按重要性排序。
1. description 是唯一的广告位,值得花一半时间打磨。 判断标准是:把你可能的说法都写进去。别只写"处理周报",要写"当用户要求总结本周工作情况、生成本周周报、本周日报汇总时使用"。
2. 一个 Skill 只做一件事。 不要做一个"文档全能助手"。任务边界越窄,description 越好写,触发越精准,输出越稳定。做五个各管一摊的小 Skill,远好过一个什么都管的大 Skill。
3. 该写死的写死,该留白的留白。 格式、字段、步骤顺序这类必须一致的东西,写死。措辞、举例、表达方式这类需要因地制宜的,留给 AI 判断。全都写死,Skill 会很僵;全都不写,Skill 等于没有。
4. 给出输入输出样例。 在 SKILL.md 末尾附一个"输入样例 → 输出样例",比写五百字说明都管用。AI 对示例的遵循度远高于对描述的遵循度。
5. 把失败路径也写进去。 大多数人只写"顺利时怎么做"。真正拉开差距的是写清"数据拉不到怎么办""格式对不上怎么办""用户给的材料不全怎么办"。这些边界情况写清楚了,Skill 才敢在无人值守时自动跑。
6. 用真实任务驱动迭代,不要凭空设计。 每次真实任务跑完,花两分钟把不满意的地方改回 Skill。改十次之后,它会比任何一次凭空设计的版本都好用。
7. 统一命名和归档。 建议按"用途"建目录,比如按客户、按业务线分文件夹,Skill 用动宾短语命名(extract-meeting-todo、generate-weekly-report)。三个月后你回头找,会感谢现在的自己。
8. 定期做一次"断舍离"。 Skill 和代码一样会腐坏。业务变了、接口改了、平台升级了,当初好用的 Skill 就会变成"看起来应该管用,实际跑出来全是错"的定时炸弹。建议每个月花半小时,把不常用的 Skill 过一遍:还在用的跑一次验证,三个月没用过的先归档,已经失效的直接删掉。留着一堆不知道还能不能用的 Skill,比没有 Skill 更危险——因为你会误以为它还在正常工作。
做完别急着用,照着这份清单过一遍:
name 是否只用小写字母、数字和连字符description 是否同时写清了「做什么」和「什么时候用」description 里是否列举了用户可能的说法(触发词)scripts/,大块资料是否放进了 references/把我在实际使用中遇到的高频问题整理成对照表:
现象 | 原因 | 解法 |
|---|---|---|
Skill 从来不自动触发 |
| 补齐触发条件,列举用户的真实说法 |
有时触发有时不触发 | 触发词覆盖面不够,只有部分说法能命中 | 把同义说法都写进 description,用逗号分隔 |
| 用了大写、中文、空格或下划线 | 改成小写字母加连字符 |
输出每次都不一样 | 正文里全是模糊建议,没有硬约束 | 把格式、字数、结构写成可检查的硬指标 |
加载很慢、响应变卡 | 把大段参考资料全塞进了主文件 | 拆到 |
关键步骤经常出错 | 确定性操作让 AI 临场写码 | 抽成 |
换台电脑就失效 | Skill 放在了项目临时目录 | 放到用户级目录 |
同事拿到也不好用 | 缺少输入输出样例,各自理解不同 | 在末尾补一组完整样例 |
改了 SKILL.md 没生效 | 会话已加载旧版本 | 新开一个对话再验证 |
回到开头那三个问题:重复描述、输出不稳、经验传不出去。Skill 给出的答案其实很朴素——把你已经会的东西写下来,放到 AI 能看到的地方。
它不需要你懂编程,只需要你能说清楚"这件事该怎么做"。而"说清楚"这件事本身,也是在倒逼你把经验从模糊的感觉,变成可复用、可传授的方法。
真正拉开人与人差距的,从来不是会不会用 AI,而是用完之后有没有留下点什么。每完成一个成功案例,花十分钟把它变成一个 Skill。半年下来,你就不再是一个人在用 AI,而是一支带着全套标准作业程序的团队在用。
现在就挑一个你这周重复做过两次以上的任务,按第四部分的五步走一遍。第一个 Skill 做出来之后,你会发现第二步、第三步快得超出想象。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。