skill-distiller

Skill Distiller

将为高能力模型（Opus）编写的技能转化为确定性工作流，使其能在成本较低的模型（Sonnet、Haiku）上可靠执行。EvoSkills 的核心见解是：技能编码的是可复用的任务结构，而非特定模型的产物。在 Opus 上演进出的技能可迁移到其他模型，并带来 +35-45pp 的提升——但前提是指令足够确定，能力较低的模型可以遵循，而无需即兴发挥。

参考文件

文件	内容	加载时机
references/distillation-patterns.md	将推理转换为规则的模式目录	始终

前置条件

• 源技能必须存在，并符合当前 package-evaluator 2.0.0 合约：实际的 report-v2 static_conformance.status: PASS，且不存在尚未解决的 CRITICAL 或 HIGH 作者判定问题。机器证据与作者判定的问题应分开保留；live_effectiveness.status 仍为 NOT_MEASURED。
• 可访问源模型（Opus）和目标模型（Haiku/Sonnet），以便进行验证
• 用于跨模型断言检查的 surrogate-verifier 技能
• 如果无法使用评估器或所需的作者评审，则报告缺少的前置条件，并在收集轨迹前停止；不得捏造分数或跳过此门槛。此项前置条件并不能证明跨模型行为表现。

工作流

阶段 1：复杂度分析

评估源 SKILL.md 各部分的推理难度：

复杂度信号	分数	蒸馏操作
包含 3 个或更多分支的决策树	HIGH	转换为明确的 if/then 查找表
“运用判断”或“结合上下文考虑”	HIGH	替换为具体的启发式规则
多步推理链	HIGH	拆分为编号的原子步骤
提及领域专业知识	MED	添加包含相关知识的显式参考文件
清晰列出的步骤	LOW	保持原样
包含预期输出的具体示例	LOW	保持原样

生成复杂度映射：章节名称 -> 复杂度分数 -> 计划操作。

阶段 2：轨迹收集

使用 Opus 在 5 个代表性任务上执行源技能：

1. 从 evals/cases.yaml 中选择任务（正向案例），或生成新任务
2. 对每个任务，捕获完整的执行轨迹：
   • 发起的工具调用（使用了哪些工具，顺序如何）
   • 输出中可见的中间推理
   • 最终输出的结构和内容
   • 耗时和令牌用量
3. 将轨迹保存为结构化数据，以供模式提取

阶段 3：模式提取

从收集到的轨迹中提取确定性模式：

1. 决策路径——对于每个 HIGH 复杂度的章节，找出 Opus 在 5 个任务中实际做出的决策。如果 Opus 在 4/5 的案例中选择了相同路径，则将该路径设为默认规则
2. 查找表——对于 Opus 运用了领域知识的情形，建立明确的查找表（例如：“如果输入包含 SQL，则使用这些模式；如果输入包含 Python，则使用那些模式”）
3. 具体示例——从轨迹中提取具有代表性的输入/输出对，作为蒸馏后技能中的少样本示例
4. 工具序列——识别常见的工具调用模式，并将其明确写出（“步骤 1：读取文件。步骤 2：搜索模式 X。步骤 3：写入输出。”）

第 4 阶段：精简重写

应用第 1 阶段的所有精简操作，重写 SKILL.md：

源模式	精简后的替换内容
“分析代码并确定……”	“检查以下 5 种具体模式：[列表]”
“使用适当的格式”	“以 Markdown 表格形式输出，列为：[A、B、C]”
“考虑上下文并决定……”	“如果 [条件 A]：执行 X。如果 [条件 B]：执行 Y。默认：Z”
“应用……的最佳实践”	引用明确列出最佳实践的文件
多段推理指令	使用编号步骤列表，每步一个句子

重写规则：

• 每条指令都必须让模型无需专业领域知识即可执行
• 每个步骤的输入和输出都必须明确，不得要求推断
• 将所有“考虑”“分析”“确定”动词替换为“检查”“计数”“列出”“输出”
• 对任何可能产生歧义的步骤添加具体示例
• 将 SKILL.md 控制在 500 行以内（精简应减少内容，而非增加内容）

第 5 阶段：目标模型验证

在目标模型（Haiku 或 Sonnet）上运行精简后的技能：

1. 加载精简后的技能，执行第 2 阶段中的同样 5 项任务
2. 使用 surrogate-verifier 为每项任务的输出生成断言
3. 比较通过率：

指标	源模型（Opus + 原版）	目标模型（Haiku + 精简版）	差值
通过的断言	N/M	N/M	±
加权得分	X.XX	X.XX	±
输出完整性	%	%	±
格式合规性	%	%	±

4. 如果目标模型得分低于源模型得分的 80%，则迭代：
   • 找出目标模型未通过的断言
   • 针对这些具体失败点添加更明确的指令
   • 重新运行验证（最多迭代 3 次）

第 6 阶段：跨模型报告

生成最终对比：

# Skill Distillation Report: <skill-name>

## Complexity Reduction
- Sections distilled: N/M (HIGH → LOW)
- Instruction word count: original X → distilled Y (Z% reduction)
- Decision points replaced with lookup tables: N

## Cross-Model Performance
| Model   | Assertions Passed | Weighted Score | Format Compliance |
|---------|-------------------|----------------|-------------------|
| Opus    | 7/7               | 1.00           | 100%              |
| Sonnet  | 6/7               | 0.92           | 100%              |
| Haiku   | 5/7               | 0.85           | 85%               |

## Changes Made
1. [Section] "Analyze complexity" → explicit 5-item checklist
2. [Section] "Apply formatting" → fixed markdown table template
...

## Recommendation
[SHIP | ITERATE | MANUAL_REVIEW_NEEDED]

错误处理

错误	解决方法
源静态合规性检查失败，或作者编写的检查中存在尚未解决的严重/高优先级问题	拒绝精简；分别报告各个证据来源，并建议通过 test-engineer 修复源内容
源评估器或作者编写的审核不可用	报告确切缺失的前置条件；不完成门禁，也不收集追踪记录
没有可用的执行追踪记录	生成合成任务，并在继续前收集追踪记录
目标模型未通过任何断言	技能可能对目标模型而言过于复杂；详细报告
精简后的技能比源技能更长	检查精简过程；可能需要合并模式

局限性

• 无法精简依赖多处开放式自适应推理或多轮推理的技能
• 视觉/交互类技能（HTML 生成、浏览器自动化）可能不适合精简
• 精简优化的是确定性，而非创造力——需要开放式生成的技能（写作、头脑风暴）不适合作为精简对象
• 收集追踪记录需要实际运行模型，因此会产生 API 费用