背景

Claude Code 的 Skills 生态很强大，但技能多了之后会出现两个问题：

  1. 上下文膨胀 — 每个 Skill 的完整描述都会注入 System Prompt，24 个 Skill 轻松吃掉几千 token
  2. 匹配混乱 — 多个 Skill 的关键词重叠时，模型可能选错

我的解决方案：单入口 + 分级可见。

架构设计

1
2
3
4
5
用户请求 → my-ai-assistant（主入口，on）
              │
              ├── 自动语义匹配 ──→ 核心子 Skill（name-only）
              │
              └── 手动调用     ──→ 其他子 Skill（/技能名）

核心机制：skillOverrides

Claude Code 的 settings.json 中有一个 skillOverrides 字段，控制每个 Skill 的可见级别：

模式 含义
on 完整加载：名称 + 描述 + 可调用
name-only 仅名称：模型看得到名字，占极少 token
user-invocable-only 仅手动：模型看不到，只能 /技能名 调用
off 完全关闭

我的配置

只保留 1 个 on 状态的主 Skill，其余 24 个全部设为 name-only：

1
2
3
4
5
6
7
8
9
10
11
12
{
  "skillOverrides": {
    "my-ai-assistant": "on",        // 默认，无需显式声明
    "hexo-blog-master": "name-only",
    "git-helper": "name-only",
    "frontend-design": "name-only",
    "shell-tools": "name-only",
    "gsap-animation": "name-only",
    "css-helper": "name-only",
    // ... 其余同理
  }
}

my-ai-assistant 作为唯一入口，内部维护了所有子 Skill 的关键词匹配表，根据用户意图自动路由。模型上下文中只看到子 Skill 的名字（一行），不会加载完整描述，只有在被调用时才会注入具体内容。

收益

  • Token 节省 — 24 个 Skill 的描述文本从 prompt 中移除，每次对话省下几千 token
  • 路由精准 — 单一入口统一调度，不会出现多个 Skill 争抢匹配的情况
  • 灵活性保留 — 随时可以用 /技能名 手动调用任意 Skill

扩展思考

这套方案的适用场景：

  • Skill 数量超过 10 个的用户
  • 有明确”主调度器”Skill 的配置
  • 希望精细化控制上下文成本的团队

如果你的 Skill 不多（5 个以内），直接全部 on 就行，不需要这套分级机制。