引言

用 Claude Code 一段时间后，你会发现一个尴尬的问题：它的内置能力很强，但总有些场景覆盖不到。每次遇到新领域，要么手动写 Prompt，要么临时上网搜。更难受的是——这次搜到的优质提示词，下次还得重新搜。知识不沉淀，经验不复用。

我花了几个晚上，在 Claude Code 的技能系统之上搭建了一套全自动闭环生态。核心思路很简单：让 AI 助手在遇到自己搞不定的任务时，自动去外部”学习”、自动把学到的东西”打包”成永久技能、自动纳入下一次调度的候选池。

一句话概括这条链路：

指令下发 → 主 Skill 调度 → 本地匹配 → 无匹配则自动拉取 prompts.chat 提示词 → 生成并保存为本地子 Skill → 纳入调度池 → 长期迭代优化

下面详细拆解每一步的设计与实现。

一、架构总览：一个主入口，多重能力池

整个系统分为三层：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
┌──────────────────────────────────────────────┐
│              用户指令（自然语言）               │
└──────────────────┬───────────────────────────┘
                   ▼
┌──────────────────────────────────────────────┐
│         my-ai-assistant（全局唯一主入口）       │
│  · 语义分析  · 优先级调度  · 容错降级           │
│  · 扩库闭环  · 技能检索  · 热更新管理           │
└──────────────────┬───────────────────────────┘
                   ▼
┌──────────────────────────────────────────────┐
│              本地子Skill注册表                  │
│                                                │
│  优先级10（核心）：博客 / Git / 前端 / 系统工具     │
│  优先级 5（专项）：搜索 / 数据 / 文案写作          │
│  优先级 1（通用）：闲聊兜底                       │
└──────────────────┬───────────────────────────┘
                   ▼
          ┌────────┴────────┐
          ▼                 ▼
    匹配度 ≥ 80          匹配度 < 80
    调用子Skill          自动扩库流程

设计上借鉴了 Python 的 __init__.py 包管理模式——主文件只做导入和分发，具体实现都在子模块里。这种模式的好处是：入口永远只有一个，用户永远不需要记住”该用哪个技能”。

二、调度核心：语义匹配 + 优先级路由

用户的每一个请求，都会经过三个阶段：

2.1 语义分析

首先提取意图和关键词。不做复杂的 NLP，基于关键词命中 + 语义相似就足够：

  • 关键词命中率（60分）：请求中的关键词命中子Skill注册的匹配词的比例
  • 语义相似度（30分）：请求意图与子Skill功能描述的语义匹配程度
  • 上下文相关性（10分）：结合对话历史和当前工作目录

2.2 优先级遍历

按优先级从高到低遍历所有子Skill：

优先级 类别 示例
10 核心日常工具 Hexo博客、Git管理、前端开发、系统工具
5 专项能力 网络搜索、数据处理、文案写作
1 通用兜底 闲聊、问答、建议

这是关键设计点：优先级提前，高频场景优先匹配。写博客的指令来了，先拿 hexo-blog-master 去匹配，不会跑到通用对话那里。

2.3 多Skill协作

复杂任务不局限单个Skill，支持三种协作模式：

  • 串行：”写一篇文章并发布” → 先调 writing 写内容，再调 hexo-blog-master 发布，最后 git-helper 备份
  • 并行：”同时检查博客状态和Git状态” → hexo-blog-master 和 git-helper 并行执行
  • 嵌套：子Skill内部可以调用更低优先级的Skill（深度≤3层）

三、核心创新：自动扩库闭环

这是整个系统最核心的部分。传统 AI 助手遇到”不会”的任务时，要么硬着头皮用通用能力凑合，要么告诉用户”我做不到”。闭环机制改变了这一点。

3.1 触发条件

当一轮匹配走完，所有已注册子Skill的匹配度都 < 80 分时，系统判定为”无对应能力”，自动进入闭环。

3.2 外部检索

1
2
3
4
5
6
7
告知用户："本地无匹配能力，正在从 prompts.chat 检索并自动创建新Skill"
         │
         ▼
调用 prompts.chat 插件 → 精准检索场景化高质量提示词
         │
         ▼
筛选：评分高、适配编程/办公/写作场景、非娱乐/违规内容

为什么不直接用 Google？因为 prompts.chat 上沉淀的是经过社区验证的结构化提示词，质量比原始搜索结果高得多。筛选这一步至关重要——宁缺毋滥，低质量的Skill比没有Skill更糟糕。

3.3 标准化封装

检索到最优提示词后，按 Claude Code 的 Skill 标准格式封装：

1
2
3
4
5
6
7
8
9
10
---
name: docker-dev-assistant
title: Docker运维助手
description: Docker容器化部署、镜像管理、docker-compose编排
tags: [docker, 容器, 运维, 部署]
version: 1.0.0
---

# Docker运维助手
...

命名规则遵循”见名知意”原则——比如 Docker运维助手、Python测试工具，用户和管理者一眼就能看懂。

优先级分配逻辑：

  • 核心高频（10）：编程语言、框架、开发工具等日常高频场景
  • 专项中频（5）：特定领域工具、运维、测试等
  • 低频通用（1）：小众工具、一次性任务等

3.4 即刻生效

新Skill创建完成后，立即用它处理当前用户请求。用户感知不到”等待安装”的过程——从触发检索到任务完成，整体体验是连续的。

1
2
3
4
5
新Skill创建完成
   │
   ├── 录入子Skill注册表，纳入全局调度池
   ├── 告知用户："已自动创建「Docker运维助手」Skill，后续同类请求直接复用"
   └── 立即调用新Skill处理当前请求

3.5 长期迭代优化

闭环不止于”创建”，更在于”维护”：

  1. 沉淀优先：同一个场景出现第二次，直接走本地已沉淀的Skill，不再重复检索
  2. 质量自检：某个子Skill连续3次执行效果差、匹配度低 → 自动标记为”待优化”
  3. 反馈驱动升级：用户反馈”这个Skill不行” → 自动重新检索 prompts.chat 替换
  4. 去重合并：定期扫描注册表，功能重复的Skill合并能力、保留最优版本

这样形成了一个正向循环：用得越多，能力越强，匹配越准。

四、容错体系：三层降级链

没有哪个系统是100%可靠的。为此设计了三层降级：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
调用子Skill
   │
   ├── 成功 → 返回结果 ✓
   │
   └── 失败 → 自动重试1次
                 │
                 ├── 成功 → 返回结果 ✓
                 │
                 └── 失败 → 降级到下一个匹配度最高的子Skill
                               │
                               ├── 成功 → 返回结果 ✓
                               │
                               └── 失败 → 继续降级…
                                             │
                                             └── 全部失败 → 主Skill直接兜底处理

关键设计：最后一层永远是主Skill自己。这意味着用户的请求永远不会被丢弃——哪怕所有子Skill都挂了，主Skill用自己的通用能力去处理，同时向用户报告完整的错误链。

五、热更新：不停机的技能管理

所有管理操作通过自然语言指令完成，直接修改配置文件：

操作 指令示例
新增 “添加新Skill：Docker助手，功能：容器管理，优先级：10”
删除 “删除Skill：旧版翻译助手”
修改 “更新Skill：Git管理，新功能：增加 submodule 支持”
查看 “查看所有Skill”
调优先级 “调整优先级：数据处理，新优先级：10”
启停 “停用Skill：网络搜索助手” / “启用Skill：网络搜索助手”

停用不等于删除——从调度池中跳过，但保留注册信息，随时可以一键恢复。

每次启动时还会自检：遍历注册表中所有子Skill，检查对应的 SKILL.md 文件是否存在、frontmatter 中的 name 字段是否匹配。不可用的Skill会被标记并跳过。

六、技能发现：不只是自建，还能”借用”

除了自动扩库（从 prompt 生成新Skill），系统还内置了外部技能发现能力——当用户明确想找某个功能时，可以检索 Claude Code 插件生态中已有的技能并安装。

与自动扩库的区别：

维度 外部技能发现 自动扩库
触发 用户明确说”帮我找个XX技能” 匹配度<80时自动触发
来源 Claude Code 生态已有插件 prompts.chat 提示词
产物 安装现成Skill 从提示词生成全新Skill
自动化 按需手动 全自动

两条路径互补：自动扩库解决”没有能力”的问题，外部发现解决”想用现成的”的问题。

七、边界控制：什么能做，什么不能做

自动扩库意味着系统会”自己生长”，但这需要明确的边界：

  1. 单次限一：一次任务只创建1个新Skill，不批量生成。避免一次”失控”污染整个注册表
  2. 领域限定：仅检索编程、开发、运维、写作、数据、博客、工具类内容。娱乐、违规类一概过滤
  3. 质量门禁：低评分提示词直接拒绝，不为了”填坑”降低标准
  4. 永久保存：所有新Skill写入本地 skills/ 目录，重启不丢失

这些限制看起来很保守，但正是这种保守让系统可以放心地自动化。没有边界的自动化是灾难。

八、实战走查：一次完整的闭环

假设用户说了一句：”帮我把这个 Docker 容器日志接入 Grafana 做监控面板”。

第一轮——本地匹配：

系统遍历注册表：Hexo博客？不匹配。Git管理？不匹配。前端开发？不匹配…所有子Skill匹配度都低于80。

第二轮——自动扩库：

  • 告知用户：【本地无匹配能力，正在从 prompts.chat 检索】
  • 调用 prompts.chat 插件，搜索 “Docker Grafana 监控 日志”
  • 筛选到一条评分9.2的提示词，主题是”DevOps监控仪表盘搭建”
  • 封装为 DevOps监控助手，优先级设为5（专项中频）
  • 写入 skills/devops-monitoring/SKILL.md
  • 录入子Skill注册表

第三轮——当场执行：

新创建的 DevOps监控助手 立即被调用，按提示词中的步骤指导用户完成 Grafana 数据源配置、面板创建、日志查询等操作。

第四轮——后续复用：

三天后用户又问了一个 Grafana 相关的问题。这次系统直接命中 DevOps监控助手，匹配度 92，不再触发检索。用户感受到的只是”AI 助手记得上次怎么做的”。

九、设计理念总结

回头看整个系统，有几个原则贯穿始终：

1. 入口唯一，路由透明。 用户永远只面对一个入口，不关心背后的调度逻辑。这是最好的用户体验——你不需要知道有多少个齿轮在转，只需要知道方向盘在你手里。

2. 能力自生长，但不失控。 自动扩库让系统从”静态工具”变成”活的生态”。但每次只增加一个Skill、严格的领域过滤、质量门禁——这些约束保证了生长是有序的。

3. 沉淀 > 搜索。 每次都上网搜是低效的。第一次搜完变成本地Skill，第二次直接复用。知识资产的积累是复利效应。

4. 优雅降级，永不丢失请求。 三层降级链保证了一个原则：用户说了话，就一定有人回应。最差的情况是主Skill自己兜底，同时把问题记录下来。

5. 做减法比做加法更需要勇气。 去重合并、质量自检、反馈驱动替换——系统不仅在生长，也在新陈代谢。不健康的Skill会被自动淘汰。

结语

这套系统从 v1.0 的简单调度，到 v2.0 的模块化架构，再到 v3.0 的自动扩库闭环，每一步都在往”更少的用户操作、更多的自动化”方向走。

最终目标是：你只需要描述你想做什么，系统自己想办法去做——做不了的，自己去学，学完再做。 这才是 AI 助手该有的样子。

如果你也在用 Claude Code，又在折腾自己的技能体系，希望这篇文章能给你一些启发。欢迎交流讨论。