第 22 章 知识精馏：把书和视频酿成可执行的 Skill
读过的好书、收藏的好课，常常停在「读过」和「收藏」——知识进来了，工作方式却没变。
这一章讲「知识精馏」：把书本和视频中的方法论，蒸馏成 Agent 可自动调用的 Skill，让别人的经验真正长进你的工作流。我们借助开源项目 cangjie-skill（v1 蒸馏书，v2 增加视频蒸馏）来完成这件事。
除了把自己的 SOP 沉淀成 Skill，还有一条更轻松的路：让 buddyme 替你读书，并把读到的本事变成它自己的。
问题起点：书读完了，然后呢
很多人都有过这样的时刻：书架上立着几十本方法论著作，笔记软件里躺着上百条划线和摘录，可当真实问题摆在面前——一份迟迟写不出的方案、一场需要拍板的讨论、一个反复出现的沟通僵局——那些读过的框架，一个都想不起来。
这不是记性不好，而是知识的存放方式出了问题。读完一本书，笔记做了、金句划了，合上书以为升级了；两周后遇到真实问题，那些方法论却抓不住。知识躺在记忆里，但激活路径不清晰——你不知道在什么场景下，该把哪个框架取出来用。
有趣的是，AI 面临着一模一样的困境。训练时它已经摄入了大量经典著作，实际问答中却常常输出「正确的废话」——每个字都对，就是给不出针对特定问题的可落地步骤。这不是幻觉问题，而是调用机制问题：它知道书里有什么，却不知道在什么场景下该主动调出哪个框架。
换句话说，无论人还是 AI，缺的都不是知识本身，而是一条从「场景」到「方法论」的自动通道。人需要「看到问题就想起框架」的肌肉记忆，Agent 需要「识别场景就激活 Skill」的触发机制——两者本质上是同一件事。
知识精馏要解决的，就是这个「学了用不上」的问题：让书里的方法论变成带着触发条件的执行单元，场景一到，自动激活。
知识精馏的定义
知识精馏（Knowledge Distillation for Skills）是指：从书本或视频中，提取出具有独立触发条件和执行步骤的原子化知识单元（Skill），使 Agent 在遇到对应场景时能够自动激活并给出可落地的行动路径。
这句话拆开来看，有三个关键动作：
- 提取：从原文中捞出真正可用的方法论，而不是把原文压缩一遍；
- 原子化：每个知识单元只解决一类问题，独立成立、独立触发，不与其他单元纠缠；
- 绑定触发条件：为每个单元写清楚「什么场景下该用我」，让 Agent 能在对的时刻主动调出它。
化学中的精馏，是按沸点把混合物分离成纯净组分。知识精馏则按「框架 / 原则 / 案例 / 反例 / 术语」五个维度，把书或视频里的知识分离成不同类型的纯净组分，再只把真正有用的提纯成可执行的 Skill。
举一个直观的对照。假设你刚读完《文案创作完全手册》：
- 摘要式的做法，是得到一份三千字的全书概要——你知道这本书讲了什么，但写标题时它帮不上忙；
- 笔记式的做法，是按章节整理出结构化的要点——比摘要好些，用时仍需自己翻找；
- 蒸馏式的做法，是产出一个「标题写作 Skill」：触发条件是「用户要为广告或公众号撰写标题」，执行步骤来自作者的方法论——先承诺具体利益、再引入具体数字、避免陈词滥调。下次你说「帮我想几个标题」，它自动激活，直接给出可用的产出。
前两种给你原料，蒸馏直接递上工具。所以，知识精馏不是：
- 摘要（压缩原文）
- 读书笔记（结构化原文）
- RAG 索引（存储原文片段供检索）
知识精馏是：将方法论转化为 Agent 能够在真实场景下自动调用的执行单元。它衡量的不是「压缩了多少原文」，而是「激活了多少场景」。
六阶段蒸馏 SOP
cangjie-skill 使用六个阶段将一本书或一组视频蒸馏成一套 Skill。整个过程像一条精炼流水线：先看懂全局，再分头提取，层层筛选，最后铸成可执行、可测试、可联网的 Skill 集合。
阶段 0：整书/整片理解 → 阶段 1：五个 Agent 并行提取 阶段 1：五个 Agent 并行提取 → 阶段 2：三重验证筛选 阶段 2：三重验证筛选 → 阶段 3：构造 Skill 阶段 3：构造 Skill → 阶段 4：链接——建立 Skill 关系网络 阶段 4：链接——建立 Skill 关系网络 → 阶段 5：压力测试
以蒸馏《文案创作完全手册》为例
阶段 0：整书 / 整片理解
不从摘取金句开始，而是先读清整本书的骨架：
- 全书主旨是什么；
- 核心论证链怎么走；
- 关键术语作者如何定义和使用；
- 作者自身的局限与盲点在哪里。
这一步决定后续提取的质量上限。跳过这一步直接提取，容易把作者反对的观点当成他支持的方法论——比如作者引用某个失败案例是为了批判它，提取 Agent 若不了解全文立场，就会把它当作正面经验收进来。
阶段 1：五个 Agent 并行提取
五个 Agent 同时从五个维度扫描全文，独立工作，互不干扰：
| Agent | 提取目标 |
|---|---|
| 框架提取 Agent | 作者构建的分析或决策框架 |
| 原则提取 Agent | 可跨场景复用的行为原则 |
| 案例提取 Agent | 作者援引的正面案例和成功路径 |
| 反例提取 Agent | 作者援引的失败案例和反面教训 |
| 术语词典 Agent | 作者专有术语及其定义 |
五个角度并行，避免单线阅读中的视角遗漏。人类做笔记时天然偏向金句和框架，反例和术语往往被忽略，而反例恰恰是划定 Skill 边界的宝贵素材。
阶段 2：三重验证筛选
每个候选知识单元必须通过三关，未通过直接淘汰：
| 验证类型 | 检查内容 |
|---|---|
| 跨域验证 | 该方法论在书中至少两个独立场景出现过，不是孤证 |
| 预测力测试 | 能用它推导出书中没有直接讨论的问题吗 |
| 独特性检验 | 是不是任何人都能说出来的常识？常识不构成 Skill |
宁缺毋滥：一本书通常有 50–100 个候选单元，通过三重验证后保留 10–25 个。
阶段 3：构造 Skill
每个通过验证的知识单元被构造成一个 Skill，核心是设计触发条件：
- 什么场景下自动激活；
- 激活后执行什么步骤；
- 什么时候不该用（边界）；
- 质量验证标准是什么。
触发条件的设计是最难也最关键的一步。没有触发条件的 Skill，在实际使用中无法被 Agent 正确识别和调用——它只是又一份躺在硬盘里的文档。
阶段 4：链接
找出 Skill 之间的关系，形成知识网络：
- 依赖：Skill A 的执行需要先调用 Skill B 的输出；
- 对比：Skill A 和 Skill B 适用于相似场景但方向相反；
- 组合：Skill A 和 Skill C 联合使用效果更好。
链接层让 Agent 在遇到复杂问题时，能够选择一组 Skill 而不只是单个 Skill。就像一位资深顾问面对问题时，调用的从来不是孤立的一条原则，而是一整套相互支撑的判断组合。
阶段 5：压力测试
诱饵测试：故意给不该触发的场景，检验 Skill 是否能忍住不激活。一个没有边界的 Skill，在错误场景下调用反而帮倒忙。
执行验证：给出真实问题，验证 Skill 是否能输出可落地的步骤而不是正确的废话。
蒸馏产物结构
一本书蒸馏完成后，产物不是一整份大文档，而是一套彼此独立又相互链接的 Skill 集合：
book-skill/
├── README.md # 书目信息、蒸馏说明、适用场景
├── skills/
│ ├── skill-01.md # 每个 Skill 独立文件
│ ├── skill-02.md
│ └── ...
├── index.md # Skill 关系网络（链接层产物）
└── tests/
├── skill-01-test.md # 每个 Skill 的测试用例
└── ...这个结构值得留意三个设计：
- 一个 Skill 一个文件：Agent 加载时可以按需取用，不必每次都把整本书的知识塞进上下文；
- index.md 记录关系网络：依赖、对比、组合关系集中在这份索引里，Agent 遇到复杂场景时顺着它找到一组 Skill 而非单个；
- tests/ 与 Skill 一一对应：每个可执行单元自带验收标准，这是产物能持续进化的基础。
每个 Skill 文件包含：触发条件、执行步骤、输出格式、边界限制、测试用例。测试用例格式兼容 darwin-skill（自动 Skill 进化工具），蒸馏产物可以持续自动优化。
知识精馏 vs-RAG
这是使用者最常问的问题：「我把书放进 buddyme 知识库（RAG 检索）不就行了，为什么还要蒸馏？」
| 维度 | RAG | 知识精馏（Skill） |
|---|---|---|
| 本质 | 检索——找出最相关的原文片段 | 提炼——从原文中提取可执行的方法论 |
| 使用前提 | 用户需要知道该问什么 | 用户描述问题，Skill 自动识别并激活 |
| 质量控制 | 无——任何内容都可以入库 | 三重验证过滤，宁缺毋滥 |
| 调用方式 | 被动等待查询 | 主动匹配场景并触发 |
| 知识形态 | 存储原文（记住知识） | 提纯为执行步骤（运用知识） |
| 边界控制 | 无 | 诱饵测试确保不乱激活 |
| 资源消耗 | 较重（需维护向量索引） | 较轻（Skill 文件即可） |
RAG 解决「知识管理」问题——让你能查到书里有什么。知识精馏解决「知识运用」问题——让 Agent 在对的时刻主动拿出对的框架。
当你不知道该问什么时，RAG 帮不了你。Skill 不需要你记得书里有哪些方法论。
两者也并不冲突：知识库负责存原文、做溯源，蒸馏产物负责在场景中出手。一个务实的组合是——平时靠 Skill 自动激活，需要核对原文细节时，再回知识库检索。
与 Karpathy-LLM-Wiki 思路的对比
Andrej Karpathy 提出 LLM 知识库（LLM Wiki）的思路：将原始资料索引到目录，让 LLM 编译成 Wiki，然后对 Wiki 做 Q&A，产出结果再回填，持续增强。
cangjie-skill 的阶段 0（整书理解）和阶段 1（并行提取）吸收了这一核心思想：先让 AI 深度阅读、结构化整理、建立索引、维护一致性。
两者的差别在于最后几步：
| 对比点 | LLM Wiki | 知识精馏 |
|---|---|---|
| 产物形态 | Wiki 条目（结构化知识库） | Skill 集合（可执行单元） |
| 使用方式 | 用户主动查询 | 场景一到，Agent 自动激活 |
| 解决问题 | 知识管理 | 知识运用 |
两种方案不互斥，但目标不同。可以把 LLM Wiki 理解为「给资料编一部词典」，知识精馏则是「从资料里训练出一位助手」——词典等你来查，助手会在合适的时机自己开口。
视频蒸馏工作流（v2 新增）
现实中，大量高价值的知识并不在书里，而在视频和课程里——一场内部分享、一套系列课、一个博主的复盘长视频。cangjie-skill v2 在书本蒸馏基础上增加了视频蒸馏能力（借助video-downloader skill）。视频与书的区别在于：需要先完成「视频 → 文字」的转换，再进入六阶段 SOP。
视频获取与转写
整体流程：
输入视频链接 → video-downloader skill：下载视频 video-downloader skill：下载视频 → 提取音频 提取音频 → ASR 转写为文案 ASR 转写为文案 → cangjie-skill：六阶段蒸馏 cangjie-skill：六阶段蒸馏 → 输出 Skill 集合
视频下载：使用 yt-dlp（开源工具）支持 YouTube、B 站等主流平台，只需输入视频链接即可自动下载。视频号因平台限制暂不支持自动化。
音频转写：本地 Whisper 模型可用，但长视频转写耗时显著（一小时视频约需 48 分钟本地转写）。推荐使用 ASR API 服务，速度快，适合批量处理。
多视频合并蒸馏
同一主题的多个视频可以合并蒸馏，产出统一的 Skill 集合。合并时 Agent 自动处理内容去重和知识单元合并，避免同一原则在不同视频中被重复提取为多个 Skill。
这在实际中特别有用：同一位老师往往在不同视频里反复讲同一套方法，散着看很难拼出全貌；合并蒸馏一次，得到的便是去重后的完整方法论体系。
video-downloader skill 与 cangjie-skill 的分工
视频处理逻辑（下载、提取音频、转写）独立封装在 video-downloader skill 中，不集成到 cangjie-skill 内部。原因是职责分离：cangjie-skill 专注文本蒸馏，视频获取是前置准备步骤，两者可以独立演进。
使用方式：
1. 用 video-downloader skill 获取视频文案
2. 将文案交给 cangjie-skill 进行六阶段蒸馏
3. 输出对应的 Skill 集合适用与不适用场景
适合蒸馏的材料
| 类型 | 适合程度 | 说明 |
|---|---|---|
| 方法论密度高的书 | ★★★★★ | 框架清晰，原则可提取，最适合 |
| 访谈 / 课程视频 | ★★★★☆ | 内容结构化程度较高，适合蒸馏 |
| 长视频 / 播客 | ★★★☆☆ | 可用，知识密度因内容而异 |
| 金句散文类书籍 | ★★☆☆☆ | 方法论少，蒸馏产物质量有限 |
| 小说 / 叙事文学 | ★☆☆☆☆ | 不适合，缺乏可提取的方法论框架 |
一个简单的判断方法：这本书有没有「按照它说的做，就能做得更好」的部分？有，就值得蒸馏；如果它的价值在于情绪、叙事或审美体验，那它属于阅读本身，蒸馏帮不上忙。
蒸馏的前置条件
蒸馏前最好读过或看过一遍原材料。原因：
- 需要判断哪些方法论是重点；
- 需要在蒸馏过程中的关键节点做判断（如三重验证的边界情况）；
- 读过之后蒸馏，吸收率显著高于未读过直接蒸馏。
蒸馏不是替代阅读，而是阅读后的知识结构化工具。没读过书的人拿到蒸馏产物，得到的是一堆「别人说有效」的步骤；读过书的人拿到同一份产物，每个步骤背后都有真实的语境支撑——用起来完全是两回事。
蒸馏产物的持续优化
蒸馏不是终点。刚出炉的 Skill 就像刚入职的新同事：方法论背得很熟，但还没经过真实业务的打磨。
cangjie-skill 产出的每个 Skill 自带测试用例，格式兼容 darwin-skill（达尔文 Skill）。
darwin-skill 是自动 Skill 进化工具：把 Skill 喂给它，它会自动评估、改进、测试，且分数只升不降。它像一位不知疲倦的教练，反复考试、找出薄弱环节、做针对性练习，并保证每次改动都不会让 Skill 变差。
这意味着蒸馏产物不是静态的。随着 Agent 实际使用反馈的积累，Skill 可以持续自动优化，逐步接近书中方法论在真实场景下的最优表达。
实际使用中的两个信号
判断一个 Skill 是否需要优化，留意两种情况：
- 该激活时没激活：明明场景匹配，Agent 却没有调用它——多半是触发条件写得太窄，放宽触发词或补充同义场景描述；
- 不该激活时激活了：场景不相关却被调出来——边界限制不够清晰，把误触发的场景补进「不适用」清单。
每次修正后，记得把新遇到的场景补充为测试用例，让下一轮进化有据可依。用得越久，这套 Skill 越贴合你的实际工作——这正是「伙伴」和「工具」的区别：工具不会越用越懂你，伙伴会。
资源消耗与模型选择
知识精馏是 Token 消耗密集型任务，主要来源于：
- 阶段 0 的全书上下文理解（长上下文）；
- 阶段 1 的五个 Agent 并行调用；
- 阶段 2 的三重验证（多轮推理）；
- 阶段 5 的压力测试（多组测试用例）。
| 场景 | 大致 Token 消耗 | 大致耗时参考 |
|---|---|---|
| 蒸馏一本普通书 | 数万至十余万 Token | 30–90 分钟 |
| 蒸馏 26 集课程视频（4 小时） | 较高 | 约 1 小时 |
| 蒸馏 4 个主题视频（80 分钟） | 中等 | 约 40 分钟 |
模型选择建议：
- 任务拆解和蒸馏协调：使用推理能力强的模型负责 Agent 编排；
- 并行提取和验证：可使用性价比高的 Coding 模型执行；
- 长上下文场景：选择原生支持长上下文的模型，避免因上下文截断导致蒸馏不完整。
要求：一次完整蒸馏任务的 Token 使用量与耗时统计界面，能看出各阶段消耗占比
蒸馏产物的分享与复用
知识精馏的一个重要特点是：产物（Skill 集合）可以直接分享和复用。蒸馏产物就是一组带说明的 Markdown 文件，天然适合放进 Git 仓库、发给同事或开源发布。
使用已蒸馏的 Skill
将 GitHub 仓库地址提供给 Agent，让 Agent 自动安装对应 Skill 即可使用，无需重新蒸馏。对使用者来说，装一个别人蒸馏好的 Skill，和装一个自己蒸馏的 Skill，体验完全一样。
团队内的复用方式
- 团队书单共蒸：团队共读一本书后，由一人牵头蒸馏，产物放在团队仓库里，全员可用——读书会从「各读各的」变成「共享一套方法论资产」；
- 内部课程沉淀：公司内训视频、老员工的分享录屏，蒸馏成 Skill 后成为新人的隐形导师；
- 社区协作：同一本书不需要被每个人重复蒸馏。任何人蒸馏的成果都可以开源，其他人直接复用。经典方法论书籍的蒸馏产物，很适合作为社区共建的第一批资产。
扩展应用
视频课程的蒸馏产物可以进一步构建课程 Agent，供学员问答和辅助实践，即课程内容的结构化知识服务化。一门课蒸馏一次，之后每位学员面对的不是一堆视频文件，而是一位「上过这门课」的助手。
常见误区
误区 1：AI 训练过的书不需要再蒸馏
对于大众熟知的经典书籍，AI 确实有一定记忆。但对小众书籍、新出版书籍以及时效性强的视频内容，AI 大概率没有训练过。此外，即使 AI 训练过某本书，蒸馏的价值在于建立触发条件——让 AI 知道在什么场景下应该调出该书的哪个框架，而不只是「知道书里有什么」。
误区 2：蒸馏完就不需要看书了
蒸馏是阅读的补充，不是替代。没读过就蒸馏，会在关键判断节点上缺乏背景，导致蒸馏结果遗漏重点。阅读过一遍后再蒸馏，蒸馏产物的质量和完整度显著更高。
误区 3：AI 给了建议就能直接执行
即使 Skill 被正确激活并给出了可落地的步骤，方向对不对、能不能执行、效果好不好，仍然需要人来判断。AI 给出的是选项和分析，决策是人的责任。
误区 4：Skill 覆盖越多越好
覆盖太宽的触发条件会导致 Skill 在不适用的场景下被错误激活，反而产生误导。三重验证和诱饵测试的目的正是控制边界，宁可覆盖窄一点，也不要乱激活。
误区 5：蒸馏一次就一劳永逸
刚蒸馏完的 Skill 是对书本的忠实转译，不是对你工作的最优解。真实使用中遇到的场景、术语和边界，书里未必覆盖。把使用反馈回填到测试用例里，Skill 才会越用越顺手。
蒸馏结果示例
以吴恩达《给所有人的 AI 入门课》（2026 版，26 个视频，时长约 4 小时）为例：
- 蒸馏耗时：约 1 小时
- 产出：25 个 Skill
- 特点：全部为时效性内容，AI 未经训练，蒸馏后可直接在对应场景下被 Agent 调用
这批 Skill 覆盖了课程的核心内容：提示词编写原则、AI 辅助写作与编程、工作流构建、AI 伦理与局限等。蒸馏完成后，当你问「帮我优化这段提示词」或「用 AI 做一份学习计划」时，Agent 会自动激活对应 Skill，按照吴恩达课上的方法来回应——而不是给出泛泛的通用建议。
这个例子最能说明蒸馏的时机价值：课程 2026 年才发布，任何模型都没有训练过它的内容。与其等模型更新，不如一小时蒸馏，立刻让 Agent「上完这门课」。
另一个值得参考的例子是《文案创作完全手册》的蒸馏产物：约 20 个 Skill，覆盖标题写作、卖点提炼、直邮文案结构、读者心理等场景。一位内容创作者的使用反馈是——「以前写标题靠灵感撞，现在写标题像查手册，每个类型都有作者验证过的公式可用。」
总结：让读过变成会用
知识精馏是 Skill 的一种生产方式。它和「从业务流程提炼 SOP 再封装成 Skill」的做法是并行的：
| 来源 | 适用场景 |
|---|---|
| 从业务流程提炼（SOP → Skill） | 企业内部操作规范、重复性业务流程 |
| 从书本 / 视频蒸馏（知识精馏） | 专家方法论、经典著作、高价值课程内容 |
两者产物格式一致，都是带有触发条件的可执行 Skill，可以在同一个 Agent 框架下混合使用。
如果说 SOP 封装是把「我们自己怎么做事」沉淀下来，知识精馏就是把「高手怎么做事」引进来。一个向内整理经验，一个向外引进方法，殊途同归——都是把沉睡的知识，变成 Agent 手边随取随用的工具。
回到本章开头的问题：知识读了用不起来，不是因为读得不够多，而是因为缺少从场景到方法的激活通道。知识精馏补上的正是这条通道。挑一本你反复读、反复忘的书，花一个小时蒸馏它——这可能是把书架上那些「读过」变成「会用」的最短路径。