别把整个 GitHub 装进 Skills，Skills 的正确用法

GitHub Skills 并不是越多越好，关键在于能否精准解决那些重复性痛点，同时避免过度设计。简单来说，核心就三点：第一，判断是否真需要 Skill 的标准，是看那个任务是否反复出现、而且 Agent 自己搞不定；第二，Skill 最适合的场景，是多步骤串联但又不值得单独写个完整系统的事；第三，一个优秀的 Skill 应该是模块化的，能跟其他 Skills 灵活组合。

之前有篇叫《Skills 的最正确用法，是将整个 Github 压缩成你自己的超级技能库》的文章，绝对算得上一篇相当好的入门指南。但不得不说，这种用法还当不起“最”正确用法。不是来抬杠，而是想聊聊：怎么更好地使用 Skills，而不是手里有把锤子就到处找钉子。

你真的需要 Skills 吗？

Skills 很酷，就像切西瓜用上了电锯，感觉确实爽。但如果你只是切个西瓜，西瓜刀其实更顺手。

Skill 是用来补充 Agent 本身不具备、而你又反复需要的信息。这意味着，如果 Agent 已经知道怎么做，或者能通过搜索自己搞定，那就不值得做成 Skill。过度封装只会增加复杂度，却不带来额外价值。

比如下载 YouTube 视频这种事情，真没必要给它一个 GitHub Repo。流行的开源项目，只要不是最近半年的，它都训练过；就算没有，它也会自己去搜。你每次只需要说“帮我下载这个视频”，然后给链接就行了。

真正需要 Skill 的场景是：你反复踩坑之后，发现某个地方每次都要解释一遍。

就像在维护 baoyu-skills 时发现的：每次发布前，都要教它写 changelog、更新 README、写 commit message、根据变更大小决定版本号。几次之后就把这个流程封装成了 release-skills。软件工程强调避免过度设计，Skills 也一样：先解决当下的真问题，别为可能永远用不上的未来需求过度设计。

Skills 是这个任务的最佳方案吗？

Skill 的优势在于：让 Agent 能自主完成多步骤任务，还不用怎么写代码或者只需要少量脚本。如果一个任务用提示词就能解决，那提示词就够了；如果必须写个 Web 应用才能跑通，那成本又太高。Skill 的甜蜜点在中间：任务需要多个步骤串联，但又不值得为此开发一套系统。

比如给文章配图。单纯靠提示词做不了，因为提示词只能帮你分析文章、生成画图提示词，但还是要人一张张生成、一张张插入合适位置。用配图 Skill 就不一样了：Agent 分析文章需要多少配图，一张张生成提示词，一张张调图像 API，最后还给你插入到合适位置。全程自动化，你只需要验收。

这事写程序也能做，但你得搭 Web 应用，后台接 LLM API 和画图 API，成本比 Skills 高得多。用 Skills 呢？几句话接入一个画图 Skill，事就成了。没有任何代码，写好了还能分享给其他人用。

你的 Skill 能和其他 Skills 组合吗？

Skill 的设计初衷是模块化：每个 Skill 做好一件事，然后像乐高一样拼起来。

单点方案和可组合方案的差别，往往不在第一次使用时显现，而在后续复用时拉开差距。一个孤立的 Skill 解决一个问题；一组可组合的 Skills 能解决一类问题。

比如写作风格这事，其实就是提示词，说明你喜欢用什么、不喜欢用什么。完全可以放到 Gemini 里做成一个 Gem，把素材发过去就能润色。但它是单点的，无法组合。如果把它变成一个 Skill，后续写视频采访稿可以用这个风格 Skill，发推文也能用。本来单个 Style 作为提示词模板也能用，但有了 Skills，可以组合起来：

所以设计 Skill 时要避免做“巨无霸”的冲动。一个 Skill 包揽所有看似省事，实则堵死了组合的可能性。

这个 Skill 值得你持续迭代吗？

好的 Skill 不是写出来的，是用出来的。这和传统写提示词完全不同。提示词是你坐在那里冥想 AI 需要知道什么，然后一次性写完；Skill 是你和 Agent 一起干活，干着干着把经验沉淀下来。在用 Agent 完成任务的过程中，让它把成功的做法、踩过的坑自己总结成 Skill。跑偏了就让它反思哪里出了问题。用着用着，Skill 就越来越准。

如果一个 Skill 做完之后就再也不想碰了，那大概率这个 Skill 本身就不该做。

就像发布的小红书 Skill，一个版本一个版本迭代到今天：

• 最开始是小互让帮忙写一个小红书的提示词
• 然后发布成了 Skill
• 后来发现样式太单一，添加了不同的样式风格
• 接着发现信息密度太低，添加了 Layout 选项
• 然后发现内容长了质量不够，就增加了分析并提炼大纲
• 有了大纲发现有时候不是想要的，干脆让它一次性出多个版本让你选
• 今天又加上了水印的支持

最有趣的是，用的过程中发现问题，马上让 Agent 帮你优化，都省了去重现去描述。迭代成本极低，这是 Skill 相比传统代码的独特优势。

什么才是最正确用法？

不是把 GitHub 上所有酷炫的 Skill 都装进来。那只会让 Claude 启动时加载一堆用不上的元数据，反而影响判断。也不是看什么功能就想着封装成 Skill。那是过度设计。

Skills 的正确用法是：先干活，干到某个地方反复卡壳，然后用最小的上下文解决这个卡壳，最后让这个解决方案能和其他 Skill 组合、能持续迭代。三个词：

给 Agent 写 Skill，就像给新员工写入职指南。你不会在第一天就把公司所有文档都塞给他，而是根据他要做的事，给他最需要的那几份。