上篇文章别把整个 GitHub 装进 Skills，Skills 的正确用法发出去后，收到一些质疑：
“说 skill 能做配图 prompt 不行。本来 skill 就是加载 md，没 skill 之前我们用 prompt 模板照样也是能做流程编排。”
“现在大部分 skill 不就是长一点的提示词吗？为什么说'单纯靠提示词做不了'？”
这些批评是对的。
我原文确实表达有问题。写“提示词”的时候，我下意识拿 Gem、Project、GPTs 里的那种提示词当例子。那些确实做不到一次性生成配图。
但“提示词”是个很宽泛的概念。如果我把 SKILL.md 的内容复制出来发给 Claude Code，再给它一个生成图片的脚本，它一样能完成配图任务。
这里的差异不在于提示词能不能复用，Gem 和 GPTs 里的提示词也能复用。差异在于：提示词配套的是 ChatBot，还是 Agent？
ChatBot 和 Agent 的核心区别
Skills 的完整名称叫 Agent Skills。注意这个“Agent”，它不是装饰词。Skills 利用 Agent 的虚拟机环境，提供单纯提示词无法实现的能力。
一句话总结：ChatBot 只能对话，Agent 能动手干活。
 具体来说：
ChatBot 不能调用工具。 你给它一段配图提示词，它能帮你分析文章、生成画图 prompt，但真要生成图片？它只能说“请把这段提示词复制到 Gemini”。剩下的活还是你干。
Agent 能调用工具。 同样的配图任务，它能像个经验丰富的编辑一样自己完成：
全程自动化，你只需要验收。
 那 Skill 到底是什么？
很多人把 Skill 理解成“一段很长的提示词”，这个理解对了一半。
SKILL.md 的核心确实是指令文本。但 Skill 不止于此。
一个 Skill 可以包含三层内容：
第一层：元数据。 就是 name 和 description，告诉 Agent 这个 Skill 是干嘛的、什么时候该用。这部分在启动时就加载，但只占几十个 token。
第二层：指令。 SKILL.md 的主体内容，工作流程、最佳实践、注意事项。只有 Agent 判断需要用这个 Skill 时，才会读取这部分。
第三层：资源和代码。 附带的脚本、模板、参考文档。Agent 按需读取，用的时候才加载。
 这就是官方说的“渐进式加载”：不是一股脑把所有内容塞进上下文，而是用到什么加载什么。
所以你可以给一个 Skill 附带几十份参考文档，只要这次任务用不上，它们就不占用上下文窗口。传统提示词做不到这一点。
为什么说配图“单纯靠提示词做不了”？
回到原来的争议。
如果你说的“提示词”是指发给像 Claude Code 这样的 Agent 的指令，那配图当然能做到。因为这时候提示词是发给 Agent 的，Agent 能调用工具。
但如果你说的是发给普通 ChatBot 的提示词，比如 ChatGPT 的自定义指令、Gemini 的 Gem、Claude 的 Project 指令，那确实做不到。因为 ChatBot 没有工具调用能力，它只能输出文字。
 我原文的问题在于：默认读者理解的“提示词”是 ChatBot 场景下的提示词，但没有明确说出来。
更准确的表达应该是：Skill 必须配合 Agent 使用。 发给 ChatBot 的提示词，无论写多长多详细，都只能完成对话能完成的事。要让 AI 真正“动手”，需要的是 Agent + 工具调用能力。
那我直接给 Claude Code 发长提示词不行吗？
行。
把 SKILL.md 内容复制出来当提示词发，Agent 一样能执行。这也是为什么有人觉得“Skill 就是长一点的提示词”。
但 Skill 的价值不在于“能不能做到”，而在于：
可复用。 写一次，以后每次相关任务自动触发，不用每次复制粘贴。
可组合。 分析 Skill + 提纲 Skill + 写作 Skill，像乐高一样拼起来。单独的提示词模板做不到这种模块化组合。
可迭代。 用着用着发现问题，直接让 Agent 帮你改进 Skill。下次自动生效。传统提示词模板改了之后，你得记得每次都用新版本。
可渐进加载。 Skill 附带的资源文件不会一开始就占用上下文。你的提示词模板再怎么组织，发出去就是全量加载。
 简单说：Skill 是提示词的工程化封装。 能做的事差不多，但管理成本、复用成本、迭代成本完全不同。
最后
上篇文章的核心没变：因需而建、可组合、可迭代。
Skill 就是长一点的提示词吗？
是的。但光有提示词不够。
关键是执行这段提示词的系统，到底是只会说的 ChatBot，还是能真正动手的 Agent。
Skill 是给 Agent 用的。 没有 Agent 的工具调用能力，Skill 就只是一段躺在文件夹里的 Markdown。
| 
