把 Skill 打开看，很多人会有同一个反应：这不就是一个 markdown 文件吗。
这个直觉没错。Skill 的原料里确实有 prompt。问题在于，平时大家说 prompt，多半指一次对话里临时写的一段指令；Skill 更像把这段指令做成可复用的小工具包。差别不在文字长得多高级，而在它什么时候被加载、带着哪些资料、能调用哪些脚本、完成后怎么验收。
举个很日常的例子。你偶尔让模型帮你润色一段话，写 prompt 就够了。你每周都要把知乎稿拆成文章、头条稿、配图提示词、审核清单、发布记录，再要求它检查禁用句式和图片来源，这时继续靠临时 prompt 会很累。每次都得重新交代规则，还容易漏项。
Skill 的价值就在这种重复任务里出现。
这张图把 prompt、Skill 和 Agent 分成三层，重点看它们在一次性指令、可复用流程和自动执行之间的差别。
高赞回答里反复提到按需加载，这点很关键。一个普通 prompt 通常直接塞进当前对话。Skill 只需要先暴露简短描述，等任务匹配时再读取完整说明、参考文件或脚本。这样做的好处很朴素：平时不占太多上下文，真正用到时又能把流程拿出来。
官方文档里对 Skill 的描述也很实在：它可以是一组说明、脚本和资源。比如一个处理 PDF 的 Skill，主体说明告诉模型什么时候用它，脚本负责抽取表格，参考文件记录格式要求。模型不必把所有细节硬背在当前对话里，遇到任务再取。
这张文件夹示意图展示一个 Skill 可能包含说明、脚本、参考资料和示例，不再只是单条临时指令。
当然，Skill 也容易被吹过头。它救不了含糊需求，也替代不了好素材。一个写得很空的 Skill，只会把空话稳定复用；一个权限给太大的 Skill，还可能把简单任务搞复杂。
我判断一个 Skill 值不值得写，通常看几个条件：任务会不会重复，步骤会不会超过三四步，是否需要固定资料，是否有明确检查项，失败以后能不能定位是哪一步错了。都满足，写成 Skill 会省很多沟通成本；只是让模型起标题、改语气、写一小段回复，临时 prompt 更轻。
这张图把适合做 Skill 的场景列出来：重复、多步骤、有素材、有校验，少一个都可以先不用急着封装。
这件事不用神化。Skill 的底料确实是 prompt，但它解决的是 prompt 的组织问题。单条 prompt 像便签，Skill 像一份带材料柜和操作规程的小手册。名字不重要，下一次任务能少解释、少漏项、少返工，才算真的有用。