当你的AI助手SKILL太多,多到你自己都忘了

1️⃣ 一个真实的尴尬场景

我用 AI 助手（Hermes Agent）搭了一套公众号内容生产流水线——选题侦察、写稿、降AI味、排版、自动发布到草稿箱，五个 skill 串起来，一条龙。

后来又搭了写作素材库，用 FAISS 向量检索存电子书和视频文字稿。又做了商业分析工具、小程序创业方法论库、降AI味工具、违禁词排查……

搭着搭着，我发现了一个很尴尬的问题：

我自己都不知道我有哪些 skill 了。

有一次朋友问我”你这个 AI 都能帮你干嘛”，我愣了半天，只能说出三四个。回去翻了半天目录才发现，我一共搭了 17 个 skill。

更尴尬的是，如果我去忙别的事情，十天半个月不碰，回来之后别说怎么用，连某个 skill 是干什么的都得重新看一遍 SKILL.md。

2️⃣ 你可能也会遇到这个问题

如果你也在用 AI Agent 做自己的工具链，你大概率会走到这一步：

• 工具越积越多，每个都有一套用法
• 用斜杠命令逐个查看太低效
• 想要一个入口，一眼看完所有能力
• 而且工具增删改了，这个入口要自动同步，不想手动维护文档

最后一条是关键。我不想再搞一个”需要维护的文档”来管理”我已经维护不过来的文档”。

3️⃣ 我的解法：让 AI 自己当导游

我没有生成静态文档，没有搞定时任务，没有建数据库。

方案极其简单——写一个 skill，教 AI 怎么当导游。

每次我问”我有哪些 skill”，AI 就现场扫描所有 skill 的 SKILL.md 文件，实时生成一份能力清单。扫描一次大概两三秒，结果天然是最新的：

• skill 删了 → 扫不到 → 清单里就没了
• skill 改了 → 扫到新的 → 清单自动更新
• 新建 skill → 马上出现在清单里

没有中间文件，没有缓存，不存在”文档和实际不一致”的问题。

4️⃣ 输出长什么样

跟 AI 说一句”我有哪些skill”，它会按目录分组返回：

注意几个设计细节：

1. 按目录分组
   
   ，同一个工具链的 skill 放一起，不会散。比如 wechat-factory 下的 6 个 skill 归为一组。
2. 只说”怎么用”，不说”怎么操作”。
   
    面向不懂技术的人，”跟我说xxx”就行，不需要知道底层跑了什么脚本。
3. 每个 skill 附带绝对路径
   
   ，方便需要时直接去目录里看源码。

5️⃣ 背后的提示词

这个 skill 的本质就是一段提示词，教 AI 怎么扫描、怎么过滤、怎么翻译成大白话。完整内容如下：

几个值得说的设计决策：

为什么要过滤系统 skill？ 系统自带了 80 多个 skill（apple、github、mlops 等通用工具），如果全列出来，噪音太大，我自己的 17 个 skill 会淹没在里面。只看自建的，一目了然。

为什么要按物理目录分组而不是按功能归类？ 因为功能归类是主观的——AI 可能会把”刘小排思维模式”主观归到”wechat-factory”里（因为它跟写作相关），但它实际是一个独立 skill。严格按目录位置分组，零歧义。

为什么不让 AI 缓存结果？ 因为 skill 会增删改。缓存意味着”可能过期”，不缓存意味着”永远是新的”。扫描 17 个文件只需要两三秒，不值得为此引入缓存机制。

6️⃣ 思路比我之前想的简单很多

最初我想过几个方案：

• 生成一个总览 Markdown 文件，skill 变了就更新它 → 需要维护同步逻辑
• 用 cron 定时扫描，每天更新一次 → 太重了，而且 skill 随时可能改
• 建一个索引数据库 → 杀鸡用牛刀

最后选的方案是什么都不存储，每次问的时候现场算。跟 React 的渲染哲学一样——不要手动操作 DOM，让框架根据 state 自动算出来。

在这里，state 就是”当前有哪些 skill 目录”，渲染就是”扫描并生成清单”。state 变了，下次渲染自然就是新的。

最简单的方案，往往是最好的方案。