夜雨聆风
AI扫盲合集
什么是Skills
拆解AI黑话，读懂智能世界
Skill的定义
Skill（技能），是一种把任务说明、参考资料、模板和可选脚本封装在一起的可复用工作流。它不改变模型参数，也不是给模型永久增加记忆；它是让智能体在遇到某类任务时，知道应该采用什么方法、读取什么材料、怎样验收结果。
比如“每次做报告都要先核对数据、套用模板、渲染检查、再交付”。如果只靠临时提醒，步骤容易漂移；写成 Skill 后，这套方法就能反复复用。
不同产品对 Skill 的格式和触发方式可能不同。下面先讲通用思想，再以 Codex / OpenAI 当前的 Skill 结构为例。
01
Skills解决的不是"不会"，而是"不稳定"
•步骤容易遗漏：同类任务每次都重新提醒，难免漏掉校对和验收。
•经验难以复用：好方法只存在某次对话里，换个项目又从头摸索。
•材料散落各处：模板、规范、示例和脚本没有统一入口。
•结果容易漂移：格式、命名、检查标准会随临场发挥变化。
Skill 的价值，是把“这类任务怎样稳定做好”写成智能体能执行的说明包。
02
最小形态：一个文件夹+SKILL.md
在 Codex 的实现里，一个 Skill 至少是一个目录，里面有必需的 SKILL.md。这个文件同时放元数据和操作说明：
1、上半部分：frontmatter
frontmatter是三条横线之间的 YAML 元数据，至少包含 name 和 description。description 要清楚说明“什么时候该用、什么时候不该用”。
2、下半部分：body
body 是 Markdown 正文，写具体操作步骤、输入输出、质量标准和边界。Codex 选中该 Skill 后，才会读取完整 SKILL.md。
03
Skill是怎样被触发的
1.显式调用：用户直接点名或在提示词中选择某个 Skill。
2.隐式匹配：当前任务与 Skill 的 description 匹配时，Codex 可以自动选择。
3.按需加载：系统先看到名称、描述和路径，决定使用后再读取完整说明与相关材料。
因此，description 很重要，但它不是唯一触发方式：用户可以显式调用；产品也可以通过策略关闭隐式调用。
04
完整Skill里可以放什么
位置 | 作用 |
SKILL.md | 必需；元数据 + 工作流指令 |
scripts/ | 可选；需要精确、可重复执行的脚本 |
references/ | 可选；智能体在工作中按需阅读的文档 |
assets/ | 可选；最终产出直接复用的模板、图片或资源 |
agents/openai.yaml | 可选；界面信息、调用策略和工具依赖 |
说明优先，脚本按需。只有当结果必须确定、需要外部工具或重复逻辑很重时，才值得把步骤写成可执行脚本。
05
什么工作最适合做成Skill
•重复出现：每周、每个项目或每次发布都会做。
•步骤稳定：可以写成清楚流程，并有可判断的完成条件。
•依赖材料：需要模板、参考资料、脚本或检查命令。
•质量易漂移：靠临场提醒容易漏步骤，封装后更可靠。
一次性、探索性很强、每次目标都完全不同的任务，往往不急着做成 Skill；先把工作方法跑顺，再封装更合适。
06
Skill与相邻概念的边界
概念 | 核心问题 |
Prompt | 这一次对话具体要做什么 |
Skill | 这一类任务以后怎样稳定地做 |
Tool | 智能体可以调用什么能力 |
MCP | 外部工具和上下文怎样接入 |
Plugin | 怎样把 Skills、连接器和配置打包分发 |
一个常见组合：Plugin 负责安装分发，MCP 负责连接外部系统，Skill 负责规定完成任务的方法，Tool 负责执行具体动作。
写在最后
Skill 不是神秘的新模型能力，而是“把好方法写下来并让智能体照着做”。当任务重复、步骤稳定、材料明确、质量需要验收时，Skill 能显著减少遗漏与漂移。
学有余力的同学，可以继续了解下面这些问题：
如何写好 Skill 的 description？
什么时候应该把步骤写成 scripts？
Skill 与 Plugin 有什么区别？
如何测试一个Skill 是否会正确触发？
END
文案撰写 | 刘尚全
排版编辑 | 杨清逸
指导老师 | 明艳
微信初审 | 明艳
微信复审 | 杨小龙
微信终审 | 肖云鹏
