零基础创建一个Skill,并持续优化Skill
为什么需要Skill:一个真实场景
假设你每周五都要向团队发送工作周报。每次打开对话窗口,你都得重新交代一遍:
- “从 Git 提交记录里提取本周完成的内容”
- “按项目分组,每个项目列出进展和遗留问题”
- “格式用 Markdown,开头写概要,结尾写下周计划”
- “不要包含调试代码的提交”
第一周说了,第二周又说,第三周还在说。你开始想:能不能让AI记住这些要求,下次直接用?
这就是Skill解决的问题——把反复出现的指令一次性打包,让AI在需要时自动调用,不再每次重复交代。
Skill究竟是什么
- 定义:
Skill 是一个以文件夹形式存在的能力模块。它包含一份核心指令文件(SKILL.md)和可选的辅助资源(参考文档、脚本、模板等),让AI在特定场景下按照预设规范执行任务。
用类比来理解:如果把AI比作一位刚入职的同事,聪明但不懂你的业务习惯,那么Skill就是交给这位同事的岗位操作手册——写清楚什么时候做什么、怎么做、做成什么样。
- Skill 与提示词的关键差异: 很多人把Skill等同于“保存下来的提示词”,这个理解不够准确。两者的差异体现在多个层面:
表1 Skill 与提示词的关键差异 对比项
提示词
Skill
存在形式
对话框里的一段文字
独立文件夹,含多个文件
生命周期
当前对话有效,关闭即消失
持久化存储,跨会话可用
内部构成
纯文本指令
指令 + 参考资料 + 脚本 + 模板
触发机制
手动粘贴或输入
自动识别用户意图并激活
知识积累
无法迭代
可持续修改和优化
协作共享
复制文本给他人
共享文件夹即可
- 核心区别:提示词是“临时交代一件事怎么做”,Skill是“建立一套长期可复用的工作规范”。
- Skill 的文件结构
一个标准的 Skill文件夹长这样:
my-skill/ ├── SKILL.md # 核心指令文件(必须存在) ├── references/ # 参考资料目录(按需) │ ├── style-guide.md # 风格规范 │ └── rules.md # 详细规则 ├── scripts/ # 脚本目录(按需) │ └── helper.py # 辅助工具 ├── examples/ # 示例目录(按需) │ └── sample.md # 示例文件 └── assets/ # 资源目录(按需) └── template.docx # 模板文件
各部分职责:
- SKILL.md:唯一必需的文件,包含元数据和核心指令。
- references/:详细规范、风格说明等参考内容,按需加载。
- scripts/:可执行脚本,处理确定性逻辑(格式转换、数据提取等)。
- examples/:完整示例,帮助 AI 理解期望的输出形态。
- assets/:模板、图标等静态资源。
果办OfficeAce对Skill内容采用渐进式加载,避免一次性占用过多上下文:
表2 渐进式加载 层级
内容
加载时机
空间占用
第一层
name + description(元数据)
始终在上下文中
约100词
第二层
SKILL.md 正文
Skill被触发时加载
建议<500 行
第三层
references/ scripts/ 等
按需读取
无硬性限制
这种设计的好处是:AI平时只感知到Skill的“名片”(description),不会浪费上下文空间;真正需要时才加载完整指令,需要细节时再读取参考文件。
怎么去找好用的Skill?
从零开始构建Skill固然最契合自身需求,但参考他人已有的设计方案,往往能启发灵感、缩短摸索周期。
以下几个渠道值得关注:
- 果办OfficeAce的技能广场 果办OfficeAce技能广场预置了海量的高质量Skill,浏览详情后即可一键安装使用。图1 技能广场
- GitHub上的开源技能项目
不少开发者和创作者会将精心打磨的Skill开源至GitHub,通过关键词检索即可定位到相应仓库,你可以通过自然语言让果办OfficeAce安装技能。以安装cangjie-skill为例,提示词如下。
提示词示例:
请帮我安装cangjie-skill,GitHub地址是https://github.com/kangarooking/cangjie-skill
- 在果办OfficeAce搜索
只需向果办OfficeAce提出需求,例如“帮我查找一个能够实现XXX功能的Skill”,它会在技能广场或互联网上搜寻匹配的选项并推荐给你。
图2 查找Skill
什么时候该做Skill:三次法则
- 判断标准
一个简单的判断方法:同样的指令,如果你对AI重复说了三次,就该做成Skill 了。
这比凭感觉决定更可靠。三次不是精确数字,而是一个信号——说明这个需求是重复发生的,值得投入时间封装。
- 适合封装为 Skill 的场景
具备以下特征的工作适合做成 Skill:
- 重复频率高:同类任务每周至少出现两次
- 标准明确:输出格式、质量要求、处理步骤基本固定
- 流程多步:需要三个以上步骤才能完成,容易遗漏环节
- 团队共性:不止一个人会遇到同样的需求
- 不适合封装为 Skill 的场景
以下情况不建议做成 Skill:
- 一次性任务:做完不会再做的事情
- 纯创意工作:没有固定标准,每次要求不同
- 简单操作:一句话就能说清楚的事
- Skill 数量管理 Skill 并非越多越好。每个Skill的description都会占用上下文空间。建议:
- 活跃Skill数量控制在10-20个。
- 超过一个月未使用的Skill,考虑归档。
- 功能相近的Skill合并,避免碎片化。
创建Skill的完整流程
以创建“微信公众号文章润色”Skill为例,专门用来润色微信公众号文章。
第一步:描述需求
直接在果办OfficeAce对话里描述你想要什么,不用任何技术术语。
实操:
登录果办OfficeAce,在底部输入框中输入需求描述,提示词示例如下,输入完成后按“Enter”发送。
我想做一个Skill,专门用来润色微信公众号文章。要求:标题要有悬念感,用数字和反差;开头前3行要抓眼球;段落要短,每段不超过3行;适当用emoji,但每段最多1个;多用“你”、“咱们”,语气要亲切。
第二步:AI自动生成Skill
AI运行完成后,将会提示Skill已创建完成,如图3所示,创建的Skill的名称为“wechat-polish”。
创建后的Skill,可以在果办OfficeAce“我的技能”界面查看,如图4所示。
第三步:测试Skill
测试一下你开发的skill
第四步:验证Skill
测试完成后,用实际数据测试一次,看输出是否符合预期。
实操:
帮我把这篇文章润色成公众号风格
查看是否触发Skill的方法:
在Skill_tool工具中查看是否加载“wechat-polish”,如果已加载,表示已触发“wechat-polish”skill,
- 图7 查看是否触发
第四步:优化Skill
不满意的地方直接告诉AI修改。
前提条件:
emoji用得有点多,改成:开头和结尾可以用,中间正文不用。
优化后,如果还不满意,继续告诉AI修改。
采纳自演进建议:
Skill优化后,如果技能演进策略配置为“询问”,则每次技能演进后,都要待用户审核建议并接纳后演进;如果技能演进策略配置为“自动生效”,则Skill自动更新技能,无需确认。详细内容请参考技能自演进。
如果技能演进策略配置为“询问”为例,则用户还需进行如下操作,技能才更新。
- Skill优化后,会在界面显示优化建议,如图10所示,
- 在左侧导航栏,选择“专家·技能·连接器”,在右侧区域选择“技能”页签,单击“我的技能”,进入“我的技能”界面,再单击右上角的“自演进”,可查看自演进建议。 图11 查看自演进建议
- 审核技能演进的内容,勾选需要采纳的建议,单击“采纳并生效”。提示采纳成功,表示技能已更新。 图12 采纳演进建议
使用Skill的方式
- 用触发词触发
直接说出触发条件,AI自动识别并调用对应Skill。比如触发词是“微信公众号文章优化”,你发这句话加上原始文章,它就自动进入对应工作模式。
- 手动选择技能
在果办OfficeAce的会话框直接选中某个Skill,然后发送需要处理的内容。这种方式适合触发词没有覆盖到的情况。
图13 手动选择技能
- 触发调优
如果发现Skill该触发时没触发(欠触发),在触发词(description)中增加触发短语和边缘场景。如果发现不该触发时触发了(过触发),则在触发词中收窄边界,增加排除条件。
示例:以发现Skill该触发时没触发为例,技能的触发词如图14红框所示。
提示词示例如下,优化有的技能如图15所示,优化后的技能已增加该触发词。
提示词示例:这个skill的触发词再增加公众号文案、推文改写
持续优化Skill建议
- Skill 不是一次创建就定型的,它需要在使用中不断打磨:使用 → 发现不足 → 分析原因 → 用自然语言描述修改点→ 再次使用 → 再次发现 → 再次修改。
- 优化原则
- 从个案找通则:不要针对单个案例打补丁,要找到通用规律。
- 做减法优于做加法:删掉不起作用的指令,比堆砌新指令更有效。
- 解释优于命令:让 AI 理解“为什么”比强制“必须”更有效。
- 每次使用后花一分钟过一遍:
- 触发是否准确(该用时用了,不该用时没用用)
- 输出格式是否符合预期
- 是否有遗漏的步骤
- 是否有冗余的步骤可以删除
- 正文是否可以更精简






