Skill真只是Prompt吗

把 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 像一份带材料柜和操作规程的小手册。名字不重要下一次任务能少解释、少漏项、少返工才算真的有用。