如何将专家精华"蒸馏"成可安装的 Skill

引言

专家最值钱的东西，不是他们知道什么，而是他们如何判断。

一个 10x 工程师之所以快，不是因为他技术文档看得多，而是因为他在拿到一个问题时，脑子里已经跑了一个隐形的决策树：这个问题属于哪类？应该先查什么？什么时候该停？

这种判断框架，是隐性知识，写不出来，只能还原。

Skill 是 OpenClaw 的能力扩展单元。本文的方法论是把专家的隐性知识封装进 skill——不是写教程，是还原判断机器。

---

专家知识的三层结构

纯显性记录（文档/博客）只能捕获第三层：

层级	内容	被捕获的难度
元规则	面对 X 情况，优先做 Y；什么时候停，什么时候转	最难，需要还原
方法论	解决某类问题的固定套路	中等，通常被简化
具体答案	可直接使用的结论/方案	易，但价值最低

专家说出来的方法论，通常是事后合理化的，不是他真实使用的。

三层同时存在，但大多数知识管理只捕获了第三层。

---

四步提取法

第一步：观察——不是问，是看

不要问专家”你怎么想的”。问他实际怎么做：

• 拿到一个问题，他默认先查什么？
• 多个约束冲突时，他先放弃哪个？
• 他什么时候知道”这不对劲”要停？

专家的边界判断（什么时候停/转）往往比正向流程更值钱。

第二步：复现——让他挑刺

把你的理解写成条件句：

专家行为：看到 HTTP 429，先等 3 秒重试，最多 3 次
         ↓ 不是总结
抽象模型：IF HTTP 429/503 THEN exponential_backoff(max_retries=3)
         ↓ 更进一步
元规则：限流场景 → 降速 > 降级 > 拒绝

让专家验证这些条件句是否准确。可验证的抽象才是真模型。

第三步：压缩——不是总结，是抽象

从具体案例到条件句式，再到元规则，三层缺一不可：

案例："这次用户反馈加载慢，我检查了数据库，发现缺索引"
     ↓ 抽象为
条件句："IF 用户反馈加载慢 THEN 检查数据库索引"
     ↓ 进一步抽象为
元规则："性能问题 → 先查索引/缓存 > 后查代码逻辑"

第四步：验证——在实际场景修正

把提炼出的规则放回真实场景。专家的精髓在于边界判断，边界错了整个模型就废了。

---

skill 结构设计

skill 是 OpenClaw 的能力封装单元。skill-creator 方法论定义了以下结构：

skill-name/
├── SKILL.md            # 核心入口
├── scripts/            # 确定性操作（脚本化）
├── references/         # 参考资料（按需加载）
└── assets/            # 模板/样本（输出时用）

核心原则：自由度匹配任务脆弱度

自由度是 skill 设计最核心的参数——给定 skill，AI 有多少决策空间：

自由度	适用场景	实现方式
Low（低）	操作序列固定，错误代价高	具体脚本，参数少
Medium（中）	有最优路径，允许变化	带参数脚本或伪代码
High（高）	无固定路径，依赖判断	文本指令，让 AI 决定

判断标准：这个任务出错的代价有多高？高则 Low freedom。

Hexo 发布 → Low freedom（命令固定，错了就 404）
选题判断 → High freedom（没有唯一正确答案）
写飞书文档 → Medium freedom（有模板，但内容需判断）

description 是触发器，不是简介

skill 的 description 决定何时被调用。这是入口，必须写清楚触发条件：

# 差描述
"这个 skill 用于发布博客文章。"

# 好描述
"当用户需要发布文章到 Hexo 博客时使用。
支持：创建文章（hexo new）、生成静态文件（hexo generate）、
验证发布结果。触发词：发博客、发布文章、新建 post。"

description 回答的问题：在什么情况下我应该调用这个 skill，而不是自己处理？

---

完整示例：DevOps 专家 → 上线检查 Skill

第一步：提取元规则

# 从专家行为还原的条件句
- IF 服务有数据库变更 THEN 先看慢查询，再上线
- IF 服务是 K8s 部署 THEN 确认 resource limits 已设置
- IF 服务是 Kafka 消费者 THEN 确认消费组 ID 不冲突
- IF 上线后报错 THEN 先看日志，不急着回滚

第二步：封装进 skill

devops-launch-check/
├── SKILL.md              # 检查流程 + 元规则
├── references/
│   └── common-errors.md  # 常见错误案例库
└── scripts/
    └── check.sh          # 自动化检查脚本

第三步：SKILL.md body

# DevOps 上线前检查

## 适用场景
服务部署/上线前的最后一道检查。被以下词语触发：上线、部署、发版。

## Low Freedom 检查流程

按顺序执行，不可跳过：

1. **数据库变更检查**
   - 有无 DDL？是则先跑索引检查
   - 参考：`scripts/check_ddl.sh`

2. **资源配置检查**
   - K8s 部署？确认 resource limits 设置
   - 无 K8s？确认环境变量完整

3. **消息队列检查**
   - Kafka 消费者？确认消费组 ID 全局唯一

4. **日志等级检查**
   - 确认日志级别为 INFO/WARN，非 DEBUG

## 边界判断
- 上线后第一时间看日志，不急着回滚
- 先确认报错类型：网络/数据库/代码逻辑
- 降级方案优先于回滚

---

与 TD-AI 的关系

memory-tdai 四层管线做的事本质上也是知识蒸馏：

对话 → L1 记忆碎片 → L2 场景叙事 → L3 用户画像

人工蒸馏专家，和 AI 自动蒸馏对话，区别在于：

维度	人工蒸馏	TD-AI
数据源	访谈/观察，样本有限	每轮对话自动捕获
抽象能力	强，但慢	弱，但持续
元规则提取	专家自省或逆向还原	LLM 自动抽象
边界判断	靠专家挑刺验证	向量相似度检测冲突

两者结合的理想路径：

1. TD-AI 持续捕获：自动记录行为模式，发现异常
2. 人工验证：对 TD-AI 发现的模式进行专家挑刺
3. skill 封装：验证通过的规则封装进 skill
4. skill 执行：skill 反过来指导 AI 的行为

---

总结

专家蒸馏成 skill 的本质：

1. 还原决策模型，不是写方法论——条件句式，不是段落
2. 边界判断比正向流程更值钱——什么时候停/转
3. 自由度匹配任务脆弱度——高代价任务给 Low freedom
4. description 是触发器——写”何时用”，不写”是什么”
5. 持续验证——元规则放在真实场景中检验

最终目标：让 AI 拥有”专家的判断力”而不是”专家的答案”。