这两天看到不少人在讨论 Skill，有人很兴奋，觉得这是 Agent 工作流的关键拼图，也有人一脸冷静，说这不就是把 Prompt 存成了一个文件。

如果只问一句，Skill 不就是 Prompt 吗，我的答案其实很简单。

很多 Skill，确实就是 Prompt。
但真正有价值的 Skill，已经不只是 Prompt 了。

问题的关键，不在名字，而在它到底封装了什么。

---

先说结论

如果一个 Skill 只有一段说明文字，核心作用只是告诉模型：

• 什么时候调用我
• 按什么风格输出
• 遵循哪些规则

那它本质上就是一个更容易复用的 Prompt。

但如果一个 Skill 进一步封装了这些东西：

• 按需加载的说明结构
• 可执行脚本
• 参考资料或模板
• 工具调用约束
• 可复用、可版本化的工作流

那它就已经不是传统意义上的 Prompt 了，而更接近一个能力包，或者说一个面向 Agent 的工作流模块。

所以这个问题，不能只看 SKILL.md 长什么样，得看它背后有没有“系统部分”。

---

为什么很多人会觉得 Skill 只是 Prompt

因为从表面看，它们确实很像。

一个典型的 Skill，通常会有：

• 名称
• 描述
• 触发场景
• 操作步骤
• 输出要求

如果把这些内容复制到聊天框里，本身也能成立。换句话说，很多 Skill 的第一层价值，就是把原本散落在对话里的提示词，收敛成一个可复用的文件。

这一步当然有意义，但它的意义主要是：

• 复用更方便
• 维护更方便
• 不用每次重写

而不是模型能力突然发生了质变。

所以很多人第一次装 Skill 之后会失望，本质原因就在这。

如果你装进去的只是一个大号 Prompt，那它解决的仍然是 Prompt 问题。

模型该忘还是忘，该跑偏还是跑偏，该理解错还是理解错。

---

真正把 Skill 和 Prompt 拉开差距的，不是文字，而是这 3 件事

1. 按需加载

这是 Skill 和普通 Prompt 的第一个工程差异。

Prompt 的典型用法，是每次对话都把上下文整包塞进去。
Skill 的典型用法，是先记住元信息，真正命中时再加载详细说明，必要时再继续读取脚本、模板、参考资料。

这意味着什么？

意味着你不用每一轮都把一大段规则重新喂给模型。

对于短对话，这个差异可能不明显。
但对 Claude Code、Codex 这种会读文件、调工具、跑长任务的 Agent 来说，这个差异非常实际。

因为它直接影响两件事：

1. 上下文占用
2. 长任务稳定性

Anthropic 官方在 Agent Skills 文档里讲得很明确，Skill 不是简单贴一段大 Prompt，而是基于文件系统存在、按需触发、分层读取的能力组织方式。
来源：Anthropic Agent Skills

从工程角度看，这其实已经不是“怎么说一句话更好”，而是“怎么组织一组长期可复用的上下文资源”。

---

2. 可执行脚本和外部资源

这才是我觉得最关键的一层。

很多人讨论 Skill 的时候，注意力都放在 SKILL.md 上。
但真正拉开差距的，往往不是说明文件，而是说明文件后面挂着的那些东西。

比如：

• scripts/validate.py
• references/style_guide.md
• templates/report.md
• schema.json
• example_input.json

一旦 Skill 开始带这些资源，它的角色就变了。

因为普通 Prompt 只能“劝”模型这么做。
脚本和结构化资源，能把一部分规则变成“必须这么做”。

举个很直接的例子。

你在 Prompt 里写：

请把输出控制在 500 字以内，并且不要出现口语化感叹词。

这当然可以。

但模型能不能稳定遵守，其实是概率问题。

如果你把这个要求做成 Skill，再加一个校验脚本：

1. 先生成正文
2. 再运行长度检测
3. 如果超字数，自动回改
4. 再运行敏感词检测
5. 不通过就继续修正

那这件事的性质就完全变了。

它不再只是“请你遵守”，而是“你必须过这一关”。

Anthropic 的工程文章里其实也在强调类似思路，大模型很强，但有些环节更适合交给确定性的传统代码处理。
来源：Equipping agents for the real world with Agent Skills

这句话翻译成大白话就是：

Prompt 更适合表达意图，代码更适合兜底规则。

而 Skill 的真正价值，恰恰就在于把这两件事接起来。

---

3. 资产化和版本化

这是很多个人用户一开始感知不到，但团队一旦开始协作就会特别明显的一层。

Prompt 更像一次性的表达。
Skill 更像可以沉淀、可以协作、可以迁移的资产。

它可以：

• 放进 Git
• 走版本管理
• 被 review
• 被别人复用
• 跨对话、跨项目继续使用
• 和脚本、模板、接口能力一起演进

这件事听起来有点抽象，但你只要做过几轮 Agent 工作流搭建，就会明白为什么它重要。

你真正想保留下来的，不是某一次聊天里说得特别好的那句话。
你想保留下来的，是那套以后谁来都能继续跑的工作方法。

这也是为什么我现在越来越把 Skill 看成一种“工作流封装”，而不是“高级 Prompt”。

---

学术和实测怎么看这件事

这件事其实已经有人认真测过了，而且结论挺有意思。

第一篇是 SkillsBench。

它测的是更像“精选能力包”的那类 Skill。结果显示，在匹配合适任务的前提下，Skill 确实可以明显提高任务通过率，论文里给出的平均提升是从 33.9% 到 50.5%。
来源：SkillsBench, arXiv:2602.12670

但另一篇 SWE-Skills-Bench 的结论就没那么乐观。

它专门看软件工程场景里的 Skill，结果发现并不是所有 Skill 都有帮助，很多公开 Skill 的增益非常有限，甚至会因为版本不匹配、上下文冲突、规则设计不清，反过来拖累结果。
来源：SWE-Skills-Bench, arXiv:2603.15401

把这两篇放在一起看，我觉得可以得出一个非常朴素的结论：

Skill 不是天然有效。

它既不是装上就变强，也不是概念本身就是骗局。

它有没有价值，取决于你到底封装了什么。

如果只是把 Prompt 存起来，那收益通常有限。
如果把触发逻辑、外部资源、脚本校验、工作流约束一起封进去，收益才会开始变明显。

---

一个简单判断标准：什么时候该用 Prompt，什么时候该做 Skill

这是我自己现在最常用的一套判断方法，挺土，但很好使。

更适合直接写 Prompt 的情况

• 只做一次
• 任务很短
• 没有外部工具依赖
• 没有稳定格式要求
• 不需要团队复用

比如：

• 帮我想 10 个标题
• 帮我润色一段文案
• 帮我解释一个概念

这类场景，Prompt 足够了，做 Skill 反而过度设计。

更适合做 Skill 的情况

• 这个任务会反复出现
• 需要固定流程
• 需要模板、参考资料或示例输入
• 需要脚本校验
• 需要调用 API、读写文件或操作外部工具
• 未来要给别人复用，或者换 Agent 后继续用

比如：

• 固定格式的周报生成
• 论文审稿质检
• 内容选题到成稿的工作流
• 电商图批量生成规范
• 接入某个图像或视频 API 的调用流程

这类场景里，Skill 的价值会明显高很多。

---

为什么很多接 API 的 Skill 特别容易体现价值

因为这类场景里，Skill 封装的往往不是“表达方式”，而是“调用能力”。

比如一个生图 Skill，如果只是写一句：

请帮我生成一张图片

那当然和 Prompt 没本质差别。

但如果它把这些一起封装了：

• 模型名称
• 参数格式
• 请求结构
• 错误处理
• 重试逻辑
• 轮询逻辑
• 返回结果解析

那它就已经不是一句提示词了，而是一个真正能工作的能力模块。

像 iMini 这种接口集成型 Skill，就是比较典型的例子。它的价值不在于“告诉模型去画图”，而在于把多模型调用、参数组织、异步任务处理这些脏活累活提前收好了。
入口：imini-ai/imini-api-integration-skill

从工程角度看，这种 Skill 和普通 Prompt，已经不是一个层级的东西。

---

回到最初的问题

Skill 不就是 Prompt 吗？

我的答案是：

如果一个 Skill 只有文字说明，那大概率是。
如果一个 Skill 已经把脚本、模板、参考资料、约束逻辑和复用关系一起打包进去了，那它就不只是 Prompt 了。

它看起来可能还是一个 SKILL.md 文件。
但真正值钱的部分，往往是那个文件后面带着的系统能力。

所以与其争论概念，我更建议直接问自己一句：

我现在要沉淀的，到底是一段会说话的话术，还是一套以后能重复跑的工作流？

如果是前者，Prompt 足够。
如果是后者，Skill 才开始真正有意义。

---