一个 Skill，到底比一段 Prompt 多了什么？
What does a Skill add beyond a prompt?第一次接触 Skills 时，我最直接的疑问是：
我们创建一个简单 Skill，不还是通过 Prompt 告诉 AI：
什么时候使用、按什么步骤处理、最后输出什么吗？
那它和一段保存在 Notes 里、需要时复制粘贴的 Prompt，到底有什么区别？
答案其实没有那么玄：
最简单的 Skill，核心确实可能就是一段 Prompt。
区别在于，这段指令不再只服务于当前对话。它被命名、写明适用范围，保存成一个可以被人或 AI 再次调用的方法。
最简单的 Skill，仍然是文字指令
假设我经常使用这样一段 Prompt：
审核文章时，先检查是否只有一条主线，论据是否支持结论，再判断需要微调、重构还是重写。
把它保存在文档里，需要时自己复制出来，是一个 Prompt 模板。
把它整理成 Skill，通常还要补充：
- 这个 Skill 叫什么；
- 它解决什么任务；
- 什么情况下应该调用；
- 哪些情况不适用；
- 具体要遵循哪些步骤；
- 最终结果要满足什么标准。
在 Codex 和 Claude Code 当前使用的文件式结构中，Skill 的核心通常是一份 SKILL.md，其中必须写明名称、描述和执行指令。AI 会先读取名称和描述，判断当前任务是否匹配；真正调用时，再载入完整内容。
所以，Prompt 和 Skill 不是互相排斥的东西。
Prompt 可以是 Skill 的核心内容。Skill 多出来的是一层组织方式：让这套指令能够被识别、调用、分享和修改。
Skill 可以带上指令之外的东西
有些 Skill 只需要文字。
例如：
- 按固定标准审核文章；
- 按品牌语气修改文案；
- 用同一种结构整理会议记录；
- 检查交付物是否遗漏必要内容。
有些任务每次还需要查阅同一批资料。
这时可以把模板、术语表、优秀案例、产品说明或内部规范一起放进 Skill，不必每次重新上传。
再复杂一些，Skill 还可以包含脚本和代码。
例如一个数据处理 Skill，可以同时保存字段说明、清理规则、输出模板，以及实际处理 CSV 的脚本；代码检查 Skill 可以规定检查顺序，并调用工具运行测试。
目前 OpenAI 和 Anthropic 的文件式 Skills 都支持在主要指令之外加入参考资料、脚本和其他资源。
一个常见结构大致是：
my-skill/
├── SKILL.md
├── references/
├── scripts/
└── assets/
并不是每个目录都必须存在。
一个写作 Skill 可能只需要 SKILL.md；只有任务确实依赖固定资料或代码时，才需要继续增加文件。
Skill, Memory, Tool, Agent
这些概念经常被放在一起说，但它们负责的事情不同。
拿“审核一篇文章”举例：
Prompt 是这一次的要求：
请审核下面这篇文章。
Context 是这次任务的材料：
文章正文、目标读者、写作背景，以及这次明确不讨论什么。
Skill 是可重复使用的方法：
先看主线，再看论据、重复、事实准确性和修改等级。
Memory 保存需要跨任务继续知道的信息：
例如用户长期不喜欢论文式标题，或者习惯先检查逻辑，再润色表达。
Tool 是 AI 实际能够调用的能力：
搜索网页、读取文件、运行代码、修改文档或操作表格。
Agent 决定 AI 能否围绕目标连续行动：
自己读取材料、选择工具、完成修改、检查结果，再继续下一步。
Skill 提供的是“怎么做”。
它本身不负责保存完整历史，也不会凭空获得文件、工具和执行权限。
Skill 不会自动吸收每次纠正
在某一次任务里纠正 AI，并不意味着 Skill 已经随之更新。
它通常不会自己修改 SKILL.md，也不会仅凭自身知道：
- 上一次任务发生了什么；
- 项目现在进行到哪里；
- 用户最近改变了什么偏好；
- 哪条要求只是这一次的例外。
有些产品另外提供 Memory 或项目说明。例如 Claude Code 使用 CLAUDE.md 和 auto memory 保存跨会话的信息，但这些是独立于 Skill 的机制。
所以，“Skill 没有记忆”不完全是缺陷，更像职责边界：
- 当前任务的变化放进 Context；
- 长期偏好由 Memory 或项目说明保存；
- 方法本身改变时，再明确修改 Skill。
否则，一次临时例外也可能被误当成长期规则。
Skill 在 Chat 和 Agent 中都能使用
纯指令型 Skill 不一定需要 Agent。
审稿标准、写作语气、分析框架和会议总结方法，在支持 Skills 的 Chat 环境中就可以发挥作用。
但如果 Skill 需要读取多个真实文件、运行脚本、调用外部工具或检查执行结果，它就更依赖 Agentic 环境。
原因很简单：
Skill 只说明流程；真正能够做多少，取决于当前产品提供的文件、工具、权限和运行环境。
OpenAI 目前将 Chat、Work 和 Codex 分成三种工作入口：Chat 主要处理提问和对话，Work 面向研究和完整交付物，Codex 面向软件开发、仓库、终端和测试。
同一个“检查”类 Skill，在不同入口里可能表现为：
- Chat：给出审核意见；
- Work：读取多份材料并生成完整报告；
- Codex：检查项目文件、修改代码并运行测试。
Skill 没有变，能够使用的环境变了。
产品内 Skill 和本地 Skill 有什么不同？
产品内 Skill 通常保存在平台账号或 workspace 中。
它的优点是创建、安装和分享更方便，不需要直接管理本地文件。ChatGPT 当前支持通过对话、编辑器或上传创建 Skill，也可以在 workspace 内分享。
但它能访问哪些文件、使用哪些工具，由平台、套餐、入口和管理员权限决定。
本地 Skill 则直接存在于电脑或项目仓库里。
例如 Codex 和 Claude Code 可以从本地目录读取 SKILL.md、脚本和参考资料。它可以随项目进入 Git，也可以为某个仓库保存专属流程。
本地方式更透明，也更适合代码、文件和项目专属任务；相应地，文件结构、依赖、权限和版本也需要自己维护。
二者不是简单的“基础版”和“高级版”。
一个不依赖具体项目的写作方法，放在产品内更方便；一个需要运行本地脚本的流程，自然更适合本地环境。
同一个 Skill 不会自动在所有产品里同步
OpenAI 和 Anthropic 都在采用开放的 Agent Skills 文件格式，这让 Skill 文件更容易迁移。
但“格式兼容”不等于“一次安装，到处生效”。
OpenAI 当前说明，ChatGPT 的个人 Skills 需要分别添加到桌面端和 web/mobile，并不会自动同步；ChatGPT 与 Codex 的治理和运行环境也可能不同。
Anthropic 对 claude.ai、Claude API 和 Claude Code 的区分更加明确：三者的自定义 Skills 需要分别上传或保存，不会自动同步；运行时可用的网络、文件和代码环境也不同。
因此，一份纯文字审稿 Skill 通常比较容易迁移。
一份依赖特定文件目录、脚本、软件包或外部工具的 Skill，换到另一个产品后往往需要重新适配。
怎样从零创建一个 Skill？
可以先做最简单的纯指令版本，不必一开始就加入脚本和复杂目录。
一个实用的起点是找三次真实发生过的相似任务，然后整理：
- 哪些要求每次都会出现；
- 什么情况下应该调用这套方法；
- 哪些情况不应该使用；
- 处理步骤是什么；
- 怎样判断结果合格。
接下来用新的任务测试，而不是只测试创建时使用过的案例。
如果应该调用时没有出现，通常需要修改名称和描述。
如果什么任务都触发，说明适用范围写得太宽。
如果执行过程很完整，但结果仍然不好，问题可能不在调用机制，而在方法本身。
如果规则越来越长，也可能是一个 Skill 承担了几个不同任务，需要拆开。
Codex 当前的 Skill Creator 默认先生成 instruction-only Skill；Claude 的官方建议同样强调，Skill 应保持清晰，并用真实场景测试和迭代。
使用公开 Skill，要像安装软件一样检查
自己做的 Skill，可以通过 workspace 分享、导出文件、项目仓库或 Plugin 分发。
使用别人公开的 Skill 时，则需要多看一步。
因为它可能不只有文字，还包含脚本、外部依赖、文件读写和工具调用。
OpenAI 会扫描上传的 Skills，但也明确说明，平台扫描不能替代用户自己的审核；Anthropic 则建议检查 Skill 中的所有文件，并把第三方 Skill 当作软件来评估。
第一次尝试时，更适合从结果容易检查、权限较低的任务开始，例如：
- 文档格式与语气；
- 会议记录整理；
- 发布前 checklist；
- 代码 review；
- 固定的数据格式转换。
不要因为一个 Skill 可以安装，就默认它适合自己的流程或可以访问敏感环境。
Skill 仍然是一套给模型执行的指令
Skill 可以提高复用和一致性，但不会把语言模型变成确定性程序。
它仍然可能：
- 该调用时没有调用；
- 在不适合的任务里被触发；
- 漏掉某个步骤；
- 对同一条规则作出不同解释；
- 完整执行了流程，却得出错误判断。
它也不能代替权限控制、人工审批和安全机制。
如果某项操作绝对不能发生，仅仅在 Skill 里写一句“禁止执行”并不够。
所以，一个 Skill 比一段 Prompt 多出的，不是某种神奇的智能。
它多出来的是：
更清楚的适用范围、更稳定的调用方式，以及携带资料、脚本和工具流程的能力。
简单任务可能只需要一段保存的 Prompt。
当一套方法需要被自动发现、反复调用，或者必须和资料、脚本及真实环境一起工作时，Skill 才真正体现出区别。