大多数人都有一个"大部分时候好用"的 prompt。调过几次，存在某个地方，然后慢慢分裂成三四个版本，没人确定哪个是对的。Skill 就是让这件事不再发生的东西——一个 Markdown 文件夹，为什么如此有效？
Skill 就是 prompting, made reusable。它把「每次重新摸索正确的指令集」变成「做一次 prompting 的工作，之后所有人直接复用」。三个关键变化——渐进式披露、目录结构、资源接入——让一个 Markdown 文件夹成为 Agent 可以反复执行的标准化流程。
每个用 AI 工具的人都经历过这个过程
你写了一个 prompt，效果还行。可能是个清单，可能是一套规则——"别做这个""必须检查那个"。你调了几次，输出看着差不多了，存下来以便复用。
然后它开始漂移。
Skill 本质上就是把这个自然演化过程正规化。与其让 prompt 在各处自由漂移，不如给它一个固定的家。
It is prompting, made reusable
说白了，Skill 就是一组 prompt 写在一个 Markdown 文件里，有时搭配一些参考文件或脚本。你把指令放进一个文件夹，通常是一个 skill.md，连同让工作流真正跑通所需的示例、模板和脚本。
这个文件夹就成了 Agent 可以作为可重复流程使用的东西，而不再是一次性的试探。
从这个意义上说，Skill 和 prompting 没有本质区别。它就是 prompting——只是被组织成了对模型和人都直观的形式。我们仍然需要在项目和团队之间管理工作流的集合，Skill 提供了一种做这件事的方式。
从"存下来的 prompt"到 Skill，什么变了
Chua 指出了可复用 prompt 和 Skill 之间的三个核心差异。
你通常不会一开始就把整个工作流加载到模型的 context 里。每个 Skill 附带一段简短描述，说明它是干什么的。Agent 先看这段描述，判断它和当前任务是否相关。只有确认相关时，才会打开完整的 skill.md，或访问附录——reference.md、脚本、MCP 服务器、API。
实际运作起来，这像一个可用工作流的目录。Agent 知道有哪些工具可用，但只在需要时才打开详细说明。
像去图书馆。你先看目录，确定哪本书和你的主题相关。找到了，你也不会从头读到尾——你翻到索引，定位到你需要的那一章。详细指令在真正需要时才被打开。
举个例子：ImageGen Skill 可能区分三种任务——生成新图、编辑已有图、生成风格一致的图集。每种任务需要不同的 prompt 模板。Agent 先看到简短描述——"Generate a new image from a text description"或"Edit an existing image while preserving specified elements"——只在任务涉及编辑时，才加载完整的编辑模板和约束规则。
现代模型非常擅长遍历文件系统。一个东西放在特定文件夹里，这个事实本身就已经传达了它应该如何被使用。就像你按项目或用途组织桌面一样，Skill 目录的结构直接给模型提供了上下文。
这同时引入了模块化。一个 Skill 变成了一个打包好的工作流单元——可以复用、共享、版本化，或者和其他 Skill 组合。你不需要在每个项目里复制粘贴略有不同的 prompt 变体，而是把工作流当作模块来分发。
code-review/，里面有 skill.md 和 examples/——无论是人还是 Agent，都能立刻理解这是什么、怎么用。目录结构本身就是免费的上下文注入。
可复用的 prompt 通常受限于你记得粘贴进去的内容。Skill 可以包含附录、示例、脚本、评估标准，甚至模型在执行任务时可以调用的工具——MCP 服务器、CLI 脚本、内部规范文档。
这意味着 Skill 不只是告诉模型做什么，还给它做好这件事所需的全部支撑材料。工作流建立在指令之上，也建立在上下文和工具之上。
模型变强了，但它仍然不能读心
你可能听过一种说法：模型越来越强，prompting 没那么重要了。
在一个层面上这是对的——你确实不再需要发现什么神奇的措辞或格式技巧来让模型正常运作。但就像和任何人说话一样，清晰无歧义的指令仍然有帮助。模型不能读心。它只能基于你给的指令和它接收到的上下文来执行任务。
Skill 做的事情很简单：让 prompting 的工作只做一次。
与其让每个用户每次都重新摸索正确的指令集，不如把工作流写一次，以它真正应该被执行的方式写下来。一个设计良好的 Skill 让调用者可以给出极简的意图，仍然获得一致的结果。
skill.md 里，暴露给用户的只有意图接口。
无论大团队还是小团队
组织里真正算得上「专业知识」的东西，大部分是一系列习惯和检查——知道部署前要验证什么、知道哪些假设需要被测试、知道什么样的输出算是可接受的。
通常这些知识通过口耳相传或者埋在过时的文档里。有了 Skill，这些知识可以被打包成 Agent 可以直接遵循的东西。所有人跑同一套流程，新成员不需要从零逆向工程出团队的最佳实践。
不再依赖每个人各自的 prompting 风格或口头记忆。
流程变了？更新 Skill 一次，不需要让每个人各自调整自己的 prompt。
复杂工作流可以由多个简单 Skill 组合而成，跨项目、跨团队分发。
用 Git 管理 Skill = 每次流程变更都有记录。
OpenAI Agents SDK 已经在用 Skill 加速开源开发——code review 和 PR 起草都有标准化的 Skill。无论是大型企业还是三人团队，Skill 让重复性任务的执行标准化，和个人风格脱钩。
什么时候应该写 Skill
Skill 没有扩展模型的能力边界，但让它更容易以可预测的方式执行重复性任务。它让你把流程编码和共享，而不是依赖记忆或复制粘贴。
一个简单的判据：如果你发现自己在重复同一个流程超过三次，它就应该成为 Skill。
Skill 引入的是一种形式：把散落的隐性流程变成显性的、可共享的、可一致执行的。
它解决的核心问题是：团队里最有价值的知识往往是「怎么做」——部署前检查什么、什么样的输出算合格、遇到边界情况怎么处理。这类知识历来靠口耳相传，容易衰变，依赖个体。一个 Markdown 文件夹是目前最低摩擦的固化方案。
重复三次以上的流程，就是一个信号：它应该成为 Skill，而不是留在你的记忆里。