夜雨聆风
OpenClaw：用 1 个架构，整合 3 个 Skill
文 / 谜鹿的 AI 自救指南
看到 Skill 就想加载使用，类似的越装越多📚
今天想写公众号，加载了 wechat-article-writer；明天想写小红书，又加载了 xiaohongshu-note-writer；后天看到有个新的封面生成 Skill，又忍不住装上😅
结果就是：3 个封面 Skill 功能重叠，用户问「用哪个」；风格规则分散在 5 个文件里，改一条规则要同步 3 个地方；每次产出的内容质量不稳定，有时候像 AI 写的，有时候又像真人写的🤖
这个问题困扰我很久了。直到今天，我决定彻底重构🔧
01｜问题：Skill 太多，维护不过来
先说现状。
重构前，我的创作 Skill 体系长这样：
milu-creator-skill/ # 风格总控wechat-article-writer/ # 公众号写作xiaohongshu-note-writer/ # 小红书写作xiaohongshu-cover-maker/ # 封面生成 1xiaohongshu-cover-generator-pro/ # 封面生成 2xiaohongshu-skills/ # 封面生成 3
3 个封面 Skill，功能重叠 80%。用户触发「写小红书」时，我得先判断用哪个封面 Skill——有时候用 cover-maker，有时候用 cover-generator-pro，有时候两个都调用。
更麻烦的是风格规则。milu-creator-skill 定义了 19 条语言风格细则，但 wechat-article-writer 和 xiaohongshu-note-writer 各自有一套独立的风格描述。改一条规则（比如「标题≤12 字」），我得同步修改 3 个文件。
AI 技术驱动效率提升
02｜方案：为什么选方案 C
我设计了 3 个整合方案。
📋 方案 A：引用式整合
在各个执行 Skill 中添加风格基准引用
✅ 优点：改动最小，只需在每个 Skill 里加一行引用
❌ 缺点：风格规则还是分散的，只是加了个链接
📋 方案 B：内嵌式整合
把 milu-creator-skill 的核心规则复制到各个执行 Skill 中
✅ 优点：执行时不需要跨文件读取，速度快
❌ 缺点：风格更新时需要同步修改 5 个文件，维护成本更高
🎯 方案 C：分层调用（最终选择）
创建分层架构，统一调度
✅ 优点：单一事实来源，易于维护，可复用
⚠️ 缺点：需要重构现有文件，工作量较大
我选了方案 C。
理由是：短期工作量大，但长期维护成本低。而且分层架构是通用的，以后新增平台（比如知乎、抖音），只需加一个目录，不用重写规则。
分层架构设计示意
03｜执行：4 步完成重构
1
创建 shared/共享规则
提取核心规则到 shared/目录（3 个文件）
2
创建平台专用目录
为公众号和小红书分别创建专用目录
3
创建调度器
创建 dispatcher.md 作为统一入口
4
更新执行 Skill
在执行 Skill 开头添加风格基准引用
维护成本对比 · 下降 60%
04｜结果：维护成本降 60%
重构完成后，新架构长这样：
milu-creator-skill/├── SKILL.md # 风格总控├── dispatcher.md # 调度器├── shared/ # 共享规则（3 个文件）├── wechat/ # 公众号专用（2 个文件）└── xiaohongshu/ # 小红书专用（2 个文件）
还有一个意外收获：归档了 2 个重叠的小红书封面 Skill。现在统一用 xiaohongshu-cover-maker，用户不再困惑「用哪个」。
05｜经验：分层设计原则
原则 1：单一事实来源
风格规则只在一个地方定义（shared/style-rules.md），其他地方只引用，不复制。这样更新时只需改一个文件，不会出现同步遗漏。
原则 2：共享优先
先提取共享规则（80%），再定义平台特殊规则（20%）。这样新增平台时，只需定义那 20% 的差异，不用重写全套。
原则 3：调度器隔离
用户不直接接触执行 Skill，而是通过调度器（dispatcher.md）分发。这样底层重构不会影响用户体验，调度器可以灵活调整调用链。
📌 行动建议
如果你也是装了一堆 Skill 却总觉得不好用，建议你：
列出你所有的 Skill，找出功能重叠的 提取共享规则，放到一个地方 为每个平台创建专用目录 创建一个调度器，统一入口
Skill 不在多，在精 ✨
你的 Skill 体系，打算怎么搭？评论区聊聊👇
—— 完 ——
字数：约 2800 字 | 阅读时间：约 5 分钟
关注公众号：谜鹿的 AI 自救指南