【Skill 创作】AI 问我：这 27 个 Skill 到底该留哪个？我说：你自己决定。于是它真的开始删自己的 Skill 了……
一句话总结：当项目里堆了 10+ 个 Skill 后，AI 该怎么选、该不该新建、旧的要不要删？这个元技能给了一套完整决策框架，还能自动生成缓存省 95% token。
1、Skill 简介
skill-selector 是一个 Meta-Skill——也就是"管理 Skill 的 Skill"。
起因很简单：我的项目里有 27 个 Skill，AI 每次选错都要浪费一两轮对话重试，废弃的没人清理，新建的全凭感觉。我就想，能不能让 AI 自己管这件事？
做完之后它能做这些：
- 智能匹配：P0-P4 五级优先级，不再瞎试
- 去重清理：检测功能重复和已过时的 Skill，给出删除建议
- 按需创建：发现重复操作模式时主动建议封装新 Skill
- 省 token：首次全量分析后生成 ~120 行项目缓存，后续调用省约 95%
- 互斥检测：自动发现 5 类 Skill 冲突
适合任何有 5 个以上 Skill 的 SOLO 项目。
2、使用场景
我是做无人机防御系统前端的。项目跑了几个月，~/.agents/skills/ 下攒了 27 个 Skill——飞书系列 26 个 + web-dev、webapp-testing 几个开发工具。
问题是怎么暴露的呢？
有一次让 AI 处理飞书文档，它先调 lark-markdown 报错了，换了 lark-doc 才对。我没在意。第二次又来，先试 lark-drive 不对，再换 lark-doc。第三次我开始烦了：每次都试错，AI 自己不知道该用哪个？
然后我又注意到几个事：
- 有个 Skill 的 SKILL.md 写了 400 行，每次全量加载，但我实际只用其中 2 个命令——80% 的 token 在为不读的内容买单
- 项目早从 ECharts 切到 G2 了，但 echarts 相关旧 Skill 还躺着，偶尔被错误匹配到
- 之前封装了个 JSON 格式化 Skill，现在 LLM 本身就能做得一样好，但它还在那白白占位
- 想建新 Skill 时没标准，全凭感觉
总结就是一句话：27 个 Skill，没有一个管理者。
做完 skill-selector 前后对比：
| 之前 | 之后 |
|---|---|
| AI 盲目试多个 Skill | 按优先级一步到位 |
| 全量加载 ~5000 tokens/次 | 缓存命中 ~200 tokens/次 |
| 废弃 Skill 静默占用空间 | 自动检测并推荐清理 |
| 新建 Skill 拍脑袋 | 三层评估模型 |
| 互斥 Skill 打架 | 自动检测报警 |
3、创作过程
第一步：先记录问题
我没有一上来就写代码，而是先花了一天记录每次 AI 选错的场景。记着记着发现了一个悖论——skill-selector 自身调用时也要加载全部 27 个 Skill 的描述来做决策，如果它自己就很重，不就成了最大的 token 浪费源吗？ 这个问题决定了后续的架构方向。
第二步：定三条规则
我问自己：AI 选 Skill 应该按什么顺序？对照自己做技术选型的思路，写了三条铁律放在 SKILL.md 最开头：
- 原则一：项目优先 — 跟当前项目有关的优先，无关的靠后
- 原则二：效率优先 — Token 最省 > 执行最快 > 效率最高 > 功能完整 > 通用性强
- 原则三：全局保护 — 全局 Skill 可能被其他项目依赖，不能随便删
所有后续算法都以这三条为基础。
第三步：解决"自身重量"悖论
借鉴编译器的思路——源码只写一次，之后执行的是编译后的字节码。设计了 Bootstrap 到 Cache 两层架构：
- 首次调用 (Bootstrap)：加载完整逻辑 (~5000 tokens) → 扫描全部 Skill → 生成 ~120 行缓存文件
- 后续调用 (Cache)：读缓存 (~200 tokens) → 命中直接用 → 未命中回退完整分析
首次多花点时间，后面每次快约 25 倍。
第四步：自审修了 4 个 Bug
写完初版后自己 Review，抓了 4 个问题：
- Bug #1：P0 手动指定最高优先级 vs "项目优先"冲突 → 修复为听用户的但提示一句
- Bug #2：去重阈值 >=90%，互斥阈值 >=95%，同一数字两套标准 → 统一为3级（>=95% 实质等同 / 90-95% 灰色地带 / <90% 各有特色）
- Bug #3："连续失败 3 次就废弃"太草率，网络抖动会误判 → 加了时间窗口条件（间隔 <1 小时）
- Bug #4：阈值全部硬编码，不同规模项目无法适配 → 改为
{default: xxx}可覆写格式
4、使用步骤
安装：复制目录即可
~/.agents/skills/skill-selector/
├── SKILL.md # 核心文件 (~1165 行)
└── profiles/
└── _template.md # 缓存模板
不需要装依赖、配环境变量，复制进去就能用。
首次使用：自动 Bootstrap
在新项目第一次触发时，skill-selector 会自动扫描全部 Skill，跑去重/互斥/Token 评估，在 .trae/ 下生成 skill-selector-cache.md。只需要等这一次。
日常使用：读缓存
后续每次涉及 Skill 选择时直接读 ~120 行缓存，约 200 tokens。想刷新就对 AI 说"刷新 skill 缓存"。
5、效果展示
Token 消耗
使用前：每次 ~5000 tokens，一天 10 次 = 50,000 浪费在"选工具"上
使用后：首次 5000 + 后续每次 200 × 10 = 7,000，节省 86%
实际场景对比
“帮我处理这个飞书文档”：
| 没有 skill-selector | 有 skill-selector |
|---|---|
| lark-markdown → 错 → lark-drive → 错 → lark-doc → 对（3轮） | 查缓存直接命中 lark-doc（1轮） |
体检报告示例
对 27 个 Skill 全面扫描后的输出：
lark-doc-legacy 与 lark-doc 功能重叠 95%，legacy 与当前项目无关，推荐安全删除。
json-formatter Skill：LLM 已原生支持同等能力（v4.0+），标记为 superseded-by-llm-v4，确认无依赖后可删，每次省 ~300 tokens。
自主创建流程图
[阶段1] 用户对话持续进行
↓ (触发条件计数器 ≥ 3 条)
[阶段2] 创建评估模型（三层评估）
├── 第一层：项目价值评估（否决项）
├── 第二层：效率指标评估（Token < 1000 / 步骤 ≤ 3 / 频率 ≥ 3）
└── 第三层：可行性评估
↓ (通过评估)
[阶段3] 自主创建提案
├── 生成 Skill 名称和描述
├── 估算 Token 消耗和收益
└── 征求用户确认
↓ (用户同意)
[阶段4] 执行创建
├── 生成 SKILL.md 和必要文件
├── 注册到项目 Skill 列表
└── [建议] 刷新项目缓存
↓
[阶段5] 创建反馈
├── 向用户展示创建结果
├── 记录创建日志
└── 建议后续优化方向
Skill 生命周期总览图
[需求产生]
↓
[创建评估] ←──┐ (循环：可重新评估调整)
↓ (通过) │
[Skill 创建] │
↓ │
[缓存同步] │ (新增节点到缓存)
↓ │
[活跃使用] │
↓ │
[定期健康检查]│
├───[健康]────→ [继续使用] ────┐
│ │
└───[异常]──┐ │
↓ │
[问题诊断] │
↓ │
[缓存同步](更新状态)──┘
↓
[废弃评估]
↓
[废弃/归档/删除]
↓
[缓存同步](移除/标记节点)
注：每次状态变更后都会触发"缓存同步"操作，
确保缓存与实际 Skill 状态一致。
6、Skill 链接
GitHub 开源地址：GitHub - xcsweb/skill-selector at master · GitHub
skill-selector/
├── SKILL.md # 核心元技能（13 章）
│ ├── 核心原则（三条铁律）
│ ├── Bootstrap → Cache 架构
│ ├── P0-P4 匹配算法
│ ├── 操作优先级 / 创建标准
│ ├── Token 优化 / 精简去重
│ ├── 废弃检测（8 种触发条件）
│ ├── 互斥检测（5 种类型）
│ ├── 自主创建 / 生命周期
│ └── profiles/_template.md # 缓存模板
{project}/.trae/
└── skill-selector-cache.md # 项目缓存（~120 行，自动生成）
7、总结与思考
做得好的地方：
- 三条铁律 → 算法 → 流程 → 缓存，层级清晰没有循环依赖
- 4 个 Bug 从根因修复而不是打补丁，同类问题不会再出现
- 全程用占位符不硬编码路径，复制到
~/.trae/skills/就能用
一个感悟：
这套框架本质上就是把人类做技术选型的思考路径——项目优先、效率优先、全局保护——形式化成了可执行的规则。教 AI 管理 Skill 的过程中，我自己做技术选型反而也更清晰了。
欢迎交流，也欢迎 fork 改进！
下面是测评链接，有兴趣的朋友也可以看看
标签：#SOLO技能创作赛 #Meta-Skill #Token优化 #Skill管理
