---
name: capability-distill
description: 能力蒸馏工作流——把强模型（限时窗口的新模型）或高质量轨迹中的判断力，蒸馏成弱模型/日常模型可加载的判断层 skill。当用户说"蒸馏"、"把 X 模型的能力写成 skill"、"新模型窗口要关了帮我留点东西"、"这次任务做得好把方法固化下来"时使用。产出的是判断手册（怎么想、何时停），不是操作规程。
---

# Capability Distill — 能力蒸馏工作流

> 由 Fable 5 在 2026-07 高额度窗口期间实践并复盘固化。
> 核心命题：模型访问是租来的，蒸馏出的判断层 skill 是自己的。
> 两种触发场景：**窗口蒸馏**（强模型限时可用，让它蒸馏自己）；**轨迹蒸馏**（某次任务完成得特别好/特别差，把决策方式提取出来，不需要强模型在场）。

## Operating Contract

- Direct actions: 从使用痕迹提取场景清单、做重叠审计、起草判断层 skill 文件、跑废话检测三关、生成验证行为检查项。
- Escalate before: 覆盖/删除已有 skill 或规则文件、把蒸馏产出提交到共享仓库、砍掉用户明确要求保留的场景。
- Evidence-backed pushback: 场景判断密度低或已有覆盖高时，明确建议不蒸馏并给出依据，而不是照单全做。
- Feedback loop: 第 5 步验证协议的逐条"生效/未生效/机械化"记录回流到 skill 修订。

## 第 0 步：确认蒸馏的是判断不是流程

先做一个分类判断，分错这一步后面全废：

- **流程**（可写成步骤/命令/checklist 的）→ 不走本工作流，直接写成普通操作 skill 或 hook。
- **判断**（需要现场权衡的：查哪层、何时停、信谁的证据、要不要拆）→ 本工作流的对象。
- 判断的识别特征：两个都合理的选项之间选择、依赖上下文的阈值、"什么时候例外"的知识。

## 第 1 步：场景清单（从使用痕迹来，不从记忆来）

**不要问用户"你有什么场景"**——人对自己最高频的判断习以为常，列不出来。从实际痕迹提取：

```bash
ls -lt ~/.claude/skills/ | head -30        # 最近在建/改什么 skill
ls <项目根>/..                              # 活跃项目和 worktree 分布
# 可选：会话历史、memory 文件、git log 近期主题
```

对每个候选场景打两个分（高/中/低）：
- **判断密度**：这个场景的质量差异来自判断力还是执行力？
- **现有覆盖**：已有 skill/规则把它流程化到什么程度？

只蒸馏"判断密度高 + 现有覆盖低"的场景。判断密度低的不值得，现有覆盖高的蒸不出增量。把清单和排序展示给用户确认，用户常会砍掉或合并——这一步的讨论本身会暴露真正的痛点。

## 第 2 步：重叠审计（写作前的强制步骤）

⚠️ 这是最容易翻车的一步：蒸馏产出如果和现有规则集（CLAUDE.md、VibeGuard 类规则、既有 skill）重复，就制造了双真实来源，且消耗约束预算。

- 列出目标场景相关的所有现有规则/skill，逐条标注：已覆盖 / 部分覆盖 / 未覆盖。
- 新 skill **只写"未覆盖"栏**；与"部分覆盖"衔接处用一句话引用（"X 见规则 Y，本文只补 Z"），不复述原文。
- 在新 skill 的开头声明与现有体系的分工边界。

## 第 3 步：蒸馏写作协议

### 窗口蒸馏（强模型在场）

不要只说"写一套指令"。用**具体场景提问**逼出隐性判断，逐场景问强模型：

- "在这个场景里，你和一个较弱模型的行为差异具体出现在哪个决策点？"
- "你在什么信号下会切换策略/停止/上抛？阈值是多少？"
- "这个场景里最常见的假成功长什么样？你怎么识别？"
- "有哪条你遵守但从没被明说的纪律？"

### 轨迹蒸馏（从已完成的任务提取）

对着轨迹问：这次的关键转折点在哪？当时有哪些备选方向、为什么选了这个？哪一步如果做错整个任务就偏了？失败轨迹同样蒸馏：决策边界在失败里比在成功里更清晰。

### 写作规格

- 每份一个场景，100-150 行，结构：本场景的本质特征 → 关键决策点的判断标准 → 证据/质量纪律 → **场景特有的停止/上抛信号**（必须有，这是弱模型差距最大的地方）。
- 每条判断尽量配**可观察的触发信号或机械检查**（"豁免清单超过 5 项 → 重新设计"），纯态度性表述（"要谨慎"）不许出现。

## 第 4 步：废话检测（发布前的质量门）

蒸馏的头号失败模式是产出**弱模型本来就会写的通用建议**。逐行过三个删除标准：

1. **反转测试**：把这条判断反过来说，是否明显荒谬？"验证要充分"反过来荒谬 → 是废话，删。"从证据密度最高的层开始查，而不是怀疑最大的层"反过来（从怀疑最大的开始）是很多人的真实做法 → 有信息量，留。
2. **新手测试**：一个没做过这类任务的合格工程师，会自己想到这条吗？会 → 删。
3. **可违反测试**：能构造一个具体场景，某人违反了这条且能被指出来吗？不能 → 太抽象，改具体或删。

三关过完通常会删掉 30-50% 的初稿。删不动说明第 3 步提问不够具体，回去重问。

## 第 5 步：验证协议（在目标模型上）

skill 不经真实任务验证就是装饰品。窗口关闭后，在目标模型上：

1. 每个场景挑 1-2 个**真实任务**（不是构造的玩具任务），开头显式加载对应 skill。
2. 验证看的是**可观察行为**，不是产出质量的整体感觉。写 skill 时就为每条关键判断定义行为检查项，例如：
   - 排障 skill → 它有没有在动手前先回答影响面三问？
   - 长时程 skill → 会话结束时有没有主动留接续锚点？
   - 有没有在该停止的信号出现时真的停止上抛？
3. 逐条记录：生效 / 未生效 / 生效但机械化（照念条文没做判断）。
4. **未生效的条目**，先怀疑写得太抽象（改成更机械的触发条件），再怀疑目标模型 instruction-following 上限（改成 hook 强制），最后才删。
5. 迭代 2-3 轮后收敛。"生效但机械化"的条目是正常状态——蒸馏传递的本来就是显式决策规则，不是隐式能力，别追求完美复刻。

## 第 6 步：生命周期

- 每份蒸馏 skill 标注来源和日期（"Fable 5 蒸馏，2026-07"）——将来更强的模型可用时，同场景**重新蒸馏并对比 diff**，diff 本身能看出模型判断力进化在哪。
- 目标模型换代后重跑第 5 步：新模型可能原生具备某些条目，那些条目删掉（skill 里只留目标模型仍不具备的判断）。
- 与已有的蒸馏手册同场景时，更新旧文件而不是新建。

## 反模式清单

- 让强模型"写一套完整指令体系"一把梭 → 产出泛泛的 8 条通用建议，全是废话检测该删的。
- 跳过重叠审计 → 和现有规则集重复，双真实来源 + 约束预算爆炸。
- 蒸馏流程性知识（部署步骤、查询命令）→ 那是操作 skill 的事，判断手册写这些会又长又没重点。
- 用构造任务验证 → 构造任务天然贴合 skill 条文，测不出真实迁移效果。
- 把"目标模型没完美执行"当成蒸馏失败 → 捕获 60-70% 的显式判断已经是巨大收益，剩下的是模型能力差距不是 skill 问题。