当你的 AI Agent 拥有 242 个 Skills：一场 Skill 治理实践
说到这个，我终于干了一件早就该做的事——清点一下我的 AI Agent 都有哪些技能（Skills）。
结果吓一跳：242 个 skills，散落在 5 个不同目录里，还有 25 组同名冲突、32 组触发词重叠。
这不是能力丰富，这是乱成一团。
这篇文章记录整个扫描、治理和清理的过程，顺便总结出一套能跑通的 skill 治理方法。
说到这个，我才意识到问题有多严重
Skills 是 AI Agent 的“外挂功能”，比如视频生成、公众号发文、PPT 制作这些。
一开始觉得挺酷，哪个好用就加进来，慢慢就堆成了一个大杂烩。
直到有一天我突然发现：
- 发一篇公众号文章，可能有 3 个不同的 skill 在抢着响应
- 做个 PPT，竟然有 9 个 skill 同时匹配关键词
- 连 “hyperframes” 这个词，都有 28 个 skill 在争
你说一句“帮我做个 cover”，系统居然要在 32 个技能之间选一个——而你只是想生成一张封面图。
这哪是智能？这是混乱。
扫描一下：原来我有这么多重复技能
我写了个小脚本，把所有 skill 目录扫了一遍，提取了名称、来源、描述和触发词。
结果一看，直接坐不住了：
- 总技能数：242
- 来源目录：5 个（全是不同生态的）
- 同名冲突：25 组
- 触发词重叠：32 组
最夸张的是这几个词，简直是“战场”：
| 触发词 | 竞争技能数量 |
|---|---|
| cover | 32 |
| skill | 29 |
| hyperframes | 28 |
| image | 22 |
| 发布 | 15 |
| 小红书 | 12 |
| PPT | 9 |
也就是说，只要你说这几个词，AI 就会陷入选择困难症。
冲突的根本原因：大家都在复制粘贴
不是技能太多的问题，而是它们来自 多个独立的 Agent 生态系统。
像 Claude Code、Kimi CLI、Hermes、QClaw 这些框架，每个都有一套自己的 skills，然后通过符号链接塞进同一个地方。
结果就是：
hyperframes出现在 3 个目录里gsap、three.js、tailwind这些适配器也全重复了- TDD、调试、规划这类流程类 skill，两套系统都有
功能几乎一样，但因为来源不同，谁先加载谁就赢——完全是靠运气。
治理第一步：搞清楚规则
治标不如治本。我写了份叫 SKILL_GOVERNANCE.md 的文档，定下几条铁律：
1. 单一来源原则
所有 skill 的唯一真实来源必须是一个项目级目录。其他地方只能通过符号链接引用，不能直接新建。
2. 命名空间隔离
给每个 skill 加前缀，区分用途：
dev-*：开发相关（调试、TDD）hf-*：HyperFrames 生态（动画、视频合成）social-*：社交平台发布（小红书、公众号）create-*：内容创作（图文、漫画）
这样就不会再出现“两个叫 poster 的技能打架”。
3. 触发词独占表
高频词只能归一个 skill 用。比如：
- “小红书图文” → 只有一个运营 skill 负责
- “PPT” → 按场景拆成网页幻灯片 / PPT视频 / AI智能PPT
- “debug” → 只留一个系统化的调试工具
避免“谁都想接”的尴尬局面。
4. 生命周期管理
新增 skill 必须过三关：
- 名称合规 ✅
- 触发词无冲突 ✅
- 不在别处重复 ✅
废弃的 skill 不删，放进 archive/ 并标记为 deprecated，保留 30 天后清理符号链接。
清理实战：从删掉一个重复技能开始
第一件事，先处理一个明显重复的：
md-poster 和另一个 poster skill 功能一模一样——都是把 Markdown 转成图文卡片。
那个新版本功能更全，我就合并进去，然后：
- 删除源目录里的旧版
md-poster - 把所有符号链接（Kimi、agents 等目录）都删干净
- 在治理文档中标记为已合并
验证确认：系统里再也找不到 md-poster 的影子。
接下来怎么走？分阶段来
我把治理任务分成三个阶段，按优先级推进：
Phase 1：消除同名冲突（马上做）
删掉 .qclaw 和 .claude 目录里跟 .hermes 重复的 HyperFrames skills。它们代码完全一样，留一份就够了。
Phase 2：功能合并（本月完成）
那些触发词不同但功能类似的技能，比如图片生成工具，统一迁移到新版，旧版打上 deprecated 标签。
Phase 3：命名空间迁移（下个月）
给所有 HyperFrames 适配器加上 hf-* 前缀，流程类加 dev-*。这是一次性改名，要同步更新所有符号链接和索引文件。
回到正题：我发现了几个反模式
这场治理让我看清了几种常见的错误做法：
反模式 1：越多越好
242 个技能不是资产，是负担。每加一个，都要担心它跟其他 241 个打架。
反模式 2：复制代替抽象
看到一个好用的 skill，直接复制一份改名字就用了。省事是省事，但维护成本爆表。
反模式 3：触发词泛化
为了更容易被调用，拼命往描述里塞热门词。最后变成啥都能响应，但啥都不准。
正解：技能即 API
一个好的 skill 应该像一个设计良好的 API：
- 做一件事，做到极致 ✅
- 触发词精准，不模糊 ✅
- 版本可控，不随便改名或删 ❗️
给你的建议：现在就动手审计一下
如果你也在用 AI Agent 的 skill 系统，建议你现在就做一次简单检查：
- 列出所有 skill（可能比你想得多）
- 找出同名重复项
- 搜索高频词，看有几个 skill 在抢
- 写一份简单的治理文档，规定命名和触发词规则
别等 200+ 才开始。10 个的时候建规则，200 个的时候只需要执行规则。
Skill 治理的本质不是限制能力，而是让正确的能力在正确的时间被正确调用。
毕竟，一个不知道自己会调哪个 skill 的 Agent，和一个没 skill 的 Agent，区别不大。