我一开始也觉得，Skill 这套说法多少有点重新发明 prompt。你给模型一段更长的说明，附几份文档，再绑几个工具，不就差不多了吗？后来我看了一圈现在主流产品和文档，发现这件事确实有营销包装，但也不能简单归成“换个名字继续卖提示词”。真正被单独拿出来讲的，不是那一段自然语言本身，而是把一段可重复的做事方法，封装成可调用、可共享、可版本化、可维护的执行单元。

这个区别听起来像概念游戏，但到了工程现场，差别很快就会暴露出来。因为 prompt 解决的是“这一次怎么把话说清楚”，而 skill 想解决的是“下次、下下次，甚至换个人来，能不能还按同样方式把事做对”。这不是同一个问题。

我为什么觉得这件事值得单独写

最近很多 agent 产品、代码代理、企业助手，都在强调自己的 skill 系统。Anthropic 在公开文档里对 Agent Skills 的定义很直接：它不是一段提示词，而是一个有组织的文件夹，里面可以放 instructions、scripts、resources，还能以版本化的方式挂到代码执行环境里。OpenAI 这边对 GPTs 的官方描述虽然不用同一套产品语言，但也一直在强调 instructions、knowledge、capabilities、actions、version history 这些东西是一起工作的。

这恰好说明一件事：行业现在真正想卖的，不再只是“你会不会写 prompt”，而是“你能不能把一段经验沉淀成稳定资产”。从这个角度看，skill 确实比 prompt 多了一层工程含义。

Prompt 解决表达，Skill 解决复用

我会这样区分它们：

• Prompt 更像一次性交互接口。它关心你这次怎么描述任务、怎么约束输出、怎么让模型少跑偏。
• Skill 更像可部署的工作单元。它除了文字说明，还会带上文件、脚本、工具边界、执行顺序、依赖关系，甚至版本。

这也是为什么很多团队明明 prompt 写得不差，系统还是不稳定。真正难的往往不是“告诉模型做什么”，而是下面这些脏活：

• 要先读哪份文档，不要把整个知识库一股脑塞进上下文；
• 什么情况下该调用哪个工具，什么情况下不该调；
• 遇到缺字段、权限不足、文件格式不对时怎么降级；
• 这套流程改版后，旧会话和新规则怎么共存；
• 换个同事来接手，能不能看懂它到底靠什么在跑。

这些问题，你可以勉强都写进一个超长 system prompt 里。但只要系统开始变复杂，那段 prompt 很快就会长成一坨没人敢动的配置垃圾。它理论上还能跑，工程上已经不可维护了。

name: weekly-support-summary
instructions: |
  先读取 support/triage.md，再按 severity 分类，最后生成周报
resources:
  - support/triage.md
  - support/faq.md
scripts:
  - scripts/normalize_tickets.py
allowed_tools:
  - zendesk_search
  - export_csv
version: 3

上面这个示意很粗糙，但它已经不是传统意义上的 prompt 了。这里面至少混合了流程说明、资源定位、脚本依赖、工具权限和版本控制。你当然可以说“本质上还是在给模型加上下文”，这没错；但工程上它已经更接近一个小型运行单元，而不是一句写得更好的提示词。

为什么这件事会被吹这么大

因为它刚好踩中了现在 agent 落地最痛的一层：模型越来越强，但可复用经验越来越难管。

过去大家吹 prompt engineering，是因为每个人都在找“怎么把模型哄对”的手感。现在产品开始吹 skill，是因为企业和团队更关心另一件事：怎么把已经验证过的方法固定下来，让别人也能复用，而不是每次都靠某个最懂 AI 的同事现场发挥。

说白了，skill 被吹，不是因为它比 prompt 神秘，而是因为它刚好补上了从“能演示”到“能维护”之间那段最麻烦的空白。

但被夸大的地方也很明显

我还是不建议把 skill 听成什么新范式革命。它至少有三层被夸大的地方。

• 第一，它没有消灭 prompt。 你只是把 prompt 从聊天框挪到了文件、模板、配置和工具描述里。
• 第二，它没有自动带来稳定性。 说明写烂了、资源过期了、工具 schema 变了，skill 一样会坏，而且往往更隐蔽。
• 第三，它会带来新的维护账。 版本谁来管，脚本谁来修，依赖谁来升级，失败日志谁来追，这些都不是 prompt 时代必须面对的问题。

很多演示会让你以为，skill 的价值来自“更聪明”。我反而觉得，它真正的价值来自“更可管”。这两个方向差很多。前者是模型能力叙事，后者是工程系统叙事。我更相信后者。

个人开发者要不要现在投入

我的判断是：可以学这个思路，但别急着给自己的 every prompt 都套一层 skill 框架。

如果你是个人开发者，最值得借鉴的不是完整平台，而是这三个动作：

• 把高频任务拆成固定步骤，而不是每次临场重写；
• 把关键文档、脚本、工具边界放在一起，减少上下文漂移；
• 给重要流程留版本和变更记录，不要把经验只留在某次会话里。

什么时候不值得做？当你的任务本来就低频、边界又经常变，或者你现在连最小稳定流程都还没摸清。这个阶段硬上 skill，通常只是在给混乱套个目录结构。

如果我只花半天，会先验证什么

• 挑一个你一周至少会重复三次的任务；
• 把说明、参考文档、脚本、允许调用的工具放进同一目录；
• 让模型严格按这个目录运行两轮；
• 记录失败是不是更集中、更容易复现、更容易修。

只要这三件事开始变好——复现更稳定、接手更容易、修改更可控——那你就已经摸到 skill 真正有用的部分了。它不在于名字，而在于你有没有把经验变成资产。

我的判断

Skill 当然没有神到值得被当成新物种。它在底层上，依然离不开 prompt、上下文和工具调用。但把它简单理解成“prompt 换皮”也不够准确。更接近事实的说法是：skill 是把 prompt 工程往前推了一步，推进成了可复用、可共享、可维护的流程封装。

所以我不吃“新概念革命”这套，但我承认它背后对应的问题是真的。谁先把这层流程资产化做扎实，谁的 agent 系统才更像工程系统，而不是一次次靠灵感驱动的对话表演。

参考来源类型：Anthropic 官方 Skills 文档与最佳实践、OpenAI 官方 GPTs 与 Projects 帮助文档。