从混乱到清晰：我是如何整理 13 个 AI 技能的

摘要：当你的 AI 助手技能从 3 个增长到 13 个，是继续野蛮生长，还是停下来重构？本文记录了一次完整的技能架构重构过程，以及如何用"流水线思维"解决能力重叠问题。

📋 问题的开始

上周五，我打开 OpenClaw 的技能目录，突然意识到一个问题：

打开一看，13 个技能目录整整齐齐地躺在那里：

skills/
├── chat-classifier/      # 对话分类
├── chat-polish/          # 对话润色
├── chat-summarizer/      # 对话总结
├── halo-publish/         # 博客发布
├── halo-publish-auto/    # 自动发布
├── tavily-search/        # 网络搜索
├── browser-mcp/          # 浏览器自动化
├── lobster-insight/      # 情报分析
├── ...                   # 还有 5 个

1. chat-* 系列有 3 个，但代码都在另一个目录
2. halo-publish 有 2 个，功能好像差不多
3. 有些目录是空的，不知道干嘛的
4. 没有文档，不知道谁依赖谁

这就像是一个创业公司，从 3 个人发展到 13 个人，却还保持着"所有人挤在一个房间里干活"的状态。

🔍 第一步：盘点家底

我做的第一件事，是给所有技能做了个"人口普查"。

技能来源分析

🎯 第二步：识别问题

问题 1：代码与定义分离

skills/chat-classifier/
└── SKILL.md          # 只有文档

chat-index/
├── classify.py       # 实际代码在这里
├── summarize.py
└── polish.py

• 新人找不到代码在哪
• 修改功能要跑两个目录
• 容易遗漏更新

问题 2：功能重叠

halo-publish 和 halo-publish-auto 都有发布功能：

• 合并？→ 技能会变得臃肿
• 保留？→ 功能重叠让人困惑

问题 3：职责边界模糊

3 个 chat-* 技能，名义上是独立的，但实际上：

• 共享 meta.json 配置文件
• 共享 chat-index/ 数据目录
• 执行顺序固定（分类→总结→润色）

• 调用时要执行 3 次命令
• 状态管理分散
• 容易出错

💡 第三步：架构设计

核心洞察：流水线思维

我意识到，这 3 个 chat-* 技能，本质上是一个内容生成流水线：

会话记录 → 分类 → 总结 → 润色 → 草稿
           ↓      ↓      ↓
      classifier summarizer polish

就像汽车工厂，不会把"冲压→焊接→涂装→总装"拆成 4 个独立工厂，而是建一条完整的流水线。

核心洞察：管理者 vs 执行者

halo-publish 和 halo-publish-auto 的关系，让我想到了一个类比：

• 重命名 halo-publish-auto → halo-publish-manager
• 明确依赖关系：manager 调用 publish
• 移除重复功能：manager 不再自己实现 Markdown 转 HTML

🛠️ 第四步：重构实施

重构 1：合并 chat-* 为 chat-workflow

skills/chat-workflow/
├── SKILL.md              # 统一文档
├── workflow.py           # 主入口（编排器）
├── modules/              # 子模块
│   ├── classifier.py     # 分类模块
│   ├── summarizer.py     # 总结模块
│   └── polish.py         # 润色模块
└── config/               # 配置目录

• ✅ 一个命令执行完整流程
• ✅ 模块化设计，各功能独立可测试
• ✅ 统一状态管理

重构 2：重命名 halo-publish-auto

• ✅ "manager"体现管理职能
• ✅ 与"publish"（执行器）职责清晰
• ✅ 一看就懂

halo-publish-manager = 发布管理器（审核 + 队列 + 定时）
halo-publish = 发布执行器（API 调用 + HTML 转换）

重构 3：清理空目录

删除了两个空目录：

• reports/ - 从未使用过
• skills/ - 包含一个已独立的子目录

📊 第五步：验证结果

重构前后对比

新架构（三足鼎立）

┌──────────────────┐
│  chat-workflow   │  内容生成（分类/总结）
└────────┬─────────┘
         │ 生成草稿
         ↓
┌──────────────────┐
│halo-publish-   │  发布管理（审核/队列/定时）
│    manager       │
└────────┬─────────┘
         │ 调用
         ↓
┌──────────────────┐
│  halo-publish    │  发布执行（API/HTML）
└──────────────────┘

• ✅ 职责边界清晰
• ✅ 无功能重叠
• ✅ 依赖关系单向
• ✅ 符合 SOLID 原则

💭 第六步：方法论提炼

方法 1：流水线思维

• 是否有固定的执行顺序？
• 是否共享数据目录？
• 是否产生中间产物？

方法 2：管理者 - 执行者分离

• 一个负责"什么时候做"（定时/调度）
• 一个负责"具体怎么做"（API/实现）

方法 3：技能人口普查

1. 来源（本地开发/外部引入）
2. 状态（完整/残缺/空目录）
3. 依赖关系（谁依赖谁）
4. 功能重叠（是否有重复造轮子）

🎯 核心原则

原则 1：单一职责

每个技能只有一个核心职责：

• chat-workflow → 内容生成
• halo-publish-manager → 发布管理
• halo-publish → 发布执行

原则 2：依赖单向

依赖关系必须是单向的：

A → B → C  ✅
A ↔ B      ❌

原则 3：数据隔离

不同技能使用不同的配置文件：

• chat-workflow → meta.json
• halo-publish-manager → publish-config.json

原则 4：文档即代码

每个技能必须有 SKILL.md，且包含：

• 核心职责
• 输入输出
• 依赖关系
• 使用示例

📈 重构收益

短期收益（立竿见影）

1. 调用简化 - 从 3 个命令 → 1 个命令
2. 状态统一 - 共享配置，避免冲突
3. 文档完整 - 每个技能都有清晰说明

长期收益（持续价值）

1. 易于扩展 - 新增功能不影响现有架构
2. 易于维护 - 职责清晰，定位问题快
3. 易于协作 - 新人快速理解架构

🔮 未来规划

下一步优化

1. 添加单元测试 - 确保重构不破坏功能
2. 性能监控 - 记录每次执行耗时
3. 错误处理 - 完善异常情况和重试机制

长期目标

1. 技能市场 - 将成熟技能发布到 OpenClaw 社区
2. 自动化测试 - CI/CD 集成
3. 版本管理 - SemVer 版本号

💡 写在最后

这次重构让我明白了一件事：

3 个月前，我的 OpenClaw 只有 3 个技能：

• 对话分类
• 博客发布
• 网络搜索

现在，它有 9 个有效技能，形成了一个完整的"内容生产流水线"：

对话 → 分类/总结 → 草稿 → 审核 → 发布 → 博客

就像一支足球队，11 个球员如果各自为战，还不如 3 个配合默契的球员。

这，就是我从这次重构中学到的最重要的一课。