1. 从"信息囤积"到"知识蒸馏"：我为什么盯上了这套组合

飞书里堆着几百篇文档、几十个多维表格、无数条聊天记录里的干货，这大概是每个重度使用飞书协作的人都会遇到的甜蜜烦恼。信息都在那儿，但要用的时候翻不到、理不清、串不起来。我试过手动整理，试过用飞书自带的搜索，甚至试过把文档一篇篇导出成Markdown再丢给AI处理——效率低到令人发指，而且每次都要重复劳动。

直到我把WorkBuddy和仓颉.Skill 2.5这两样东西凑到一起，才真正跑通了一条从"飞书原始内容"到"结构化知识"的自动化链路。标题里说的"免费蒸馏飞书的任何内容"，不是夸张，是我实测下来确实能落地的方案。所谓"蒸馏"，在这里指的是把飞书里散落的、非结构化的、多格式的内容，通过AI能力提炼成精炼的、可复用的、结构化的知识资产。这个词借用了模型蒸馏的概念，但在这里更偏向"信息提纯"的意思。

这套方案适合谁？如果你是飞书的重度用户，手头有大量文档、表格、会议纪要需要定期整理；如果你已经在用Claude Code或者类似的AI编程助手，想把它和飞书打通；如果你对"Skill"这个概念还不太清楚，想知道它和Agent到底有什么区别——那这篇内容就是写给你的。我会从最基础的概念讲起，一直讲到完整的实操配置和踩坑经验，尽量让不同基础的人都能跟上。

先交代一下我自己的使用场景：我日常在飞书上维护一个技术知识库，包含大概300多篇文档和十几个多维表格，内容涉及项目复盘、技术方案、竞品分析等。以前每周要花三四个小时手动整理和归档，现在这套流程跑通之后，整理时间压缩到了20分钟以内，而且产出的结构化程度比手动整理高得多。

2. WorkBuddy和仓颉.Skill到底是什么关系

2.1 WorkBuddy：不是另一个聊天窗口，而是工作流编排器

很多人第一次听到WorkBuddy，会以为它就是个AI对话工具，跟其他聊天机器人差不多。但实际用下来，它的定位更接近"工作流编排器"——你可以把不同的AI能力、不同的数据源、不同的处理步骤串成一条流水线，让它们自动按顺序执行。

WorkBuddy的核心价值在于它提供了一个统一的调度层。你不需要自己去写复杂的API调用代码，也不需要维护一堆脚本之间的依赖关系。它把"读取飞书文档→调用AI处理→输出结构化结果→写回飞书"这样的流程变成了可视化或者配置化的操作。我最初是被它的"自定义指令"功能吸引的，后来发现真正好用的是它的Skill集成能力。

WorkBuddy有国际版和国内版之分，功能上略有差异。我两个版本都试过，国内版在飞书集成方面更顺畅一些，国际版在某些AI模型的调用上更灵活。如果你主要处理飞书内容，建议从国内版入手。安装方面，Windows和Linux都有对应的客户端，安装过程不复杂，基本就是下载、登录、配置数据源三步走。

2.2 仓颉.Skill 2.5：给AI装上"专业技能包"

"Skill"这个词最近在AI圈子里出现频率很高，但很多人搞不清楚它和Agent的区别。我用一个类比来解释：Agent像一个全能助理，你告诉它目标，它自己想办法完成；Skill则像给这个助理报了一个专业技能培训班，让它掌握某项具体能力，比如"整理文档"、"提取表格数据"、"生成会议纪要"。

仓颉.Skill 2.5是一套专门针对中文内容处理的Skill集合，2.5版本相比之前最大的升级在于对飞书生态的适配更加深入。它内置了对飞书文档、多维表格、消息记录等格式的解析能力，能够识别飞书特有的文档结构（比如折叠块、引用块、多维表格的字段类型），这在通用的AI处理工具里是很难做到的。

我实测下来，仓颉.Skill 2.5最实用的几个能力包括：飞书文档的层级结构提取、多维表格的字段映射、长文档的分段摘要、以及跨文档的知识关联。这些能力单独拿出来可能不算惊艳，但组合起来就能实现"把一堆散乱文档变成一张知识图谱"的效果。

2.3 两者结合后的化学反应

单独用WorkBuddy，你能编排工作流但缺乏专业的内容处理能力；单独用仓颉.Skill，你有处理能力但没有自动化的调度。两者结合之后，就形成了一条完整的"飞书内容蒸馏流水线"。

我目前跑通的典型流程是这样的：WorkBuddy定时触发→读取指定飞书文件夹下的所有文档→调用仓颉.Skill进行内容解析和摘要→将结果写入一个多维表格→同时生成一份汇总文档回写到飞书。整个过程不需要人工干预，跑完之后我只需要检查一下输出结果就行。

注意：Skill的调用需要消耗AI模型的token，虽然WorkBuddy本身免费，但底层模型的调用成本需要你自己承担。不过对于日常文档处理量来说，成本非常低，我一个月处理300多篇文档，花费不到一杯咖啡的钱。

3. 环境搭建：从零开始把链路跑通

3.1 WorkBuddy的安装与初始配置

WorkBuddy的安装过程比我想象中简单。官网下载对应平台的安装包，Windows下就是一个标准的exe安装程序，Linux下是AppImage或者deb包。安装完成后首次启动会引导你完成初始配置，主要包括三部分：AI模型的选择和API Key配置、飞书账号的授权连接、以及工作目录的设置。

模型选择这块，WorkBuddy支持多种主流模型。我的建议是：如果你主要处理中文内容，选一个中文能力强的模型；如果涉及代码或者技术文档，选一个推理能力强的。不用纠结选哪个"最好"，因为WorkBuddy支持在运行时切换模型，你可以根据不同任务灵活调整。

飞书授权这一步是关键的。WorkBuddy需要通过飞书开放平台的应用授权来访问你的文档和表格。这里有个坑我踩过：飞书的企业管理员可能限制了第三方应用的访问权限，如果你发现授权后读不到文档，先检查一下企业后台的应用权限设置。个人版飞书一般不会有这个问题。

工作目录的设置影响的是本地文件的读写路径。如果你打算处理本地文档（比如用仓颉.Skill整理本地文件夹），这个目录要设置好。如果只处理飞书云端内容，默认设置就行。

3.2 仓颉.Skill 2.5的导入与激活

仓颉.Skill 2.5的导入方式取决于你用的WorkBuddy版本。国内版通常可以在Skill市场里直接搜索安装，国际版可能需要手动导入Skill包。我两个版本都操作过，手动导入的步骤也不复杂：下载Skill包→在WorkBuddy的Skill管理界面选择"导入"→选择对应的包文件→等待加载完成。

导入之后需要激活。激活过程会要求你确认一些权限，比如是否允许Skill访问飞书文档、是否允许写入多维表格等。这里建议全部允许，否则后续流程会频繁报权限错误。

激活完成后，你可以在WorkBuddy的Skill列表里看到仓颉.Skill 2.5，并且能看到它支持的具体能力列表。我建议先别急着搭建复杂流程，先用一个简单的文档测试一下Skill的基本功能是否正常。

3.3 飞书侧的准备工作

飞书这边需要做的准备主要有两项：一是确保你要处理的文档或表格所在的文件夹已经授权给WorkBuddy应用；二是如果涉及多维表格的写入，需要提前建好目标表格并设置好字段。

关于文件夹授权，我建议单独建一个"待处理"文件夹，把需要蒸馏的内容放进去，处理完的移到"已处理"文件夹。这样管理起来清晰，也方便WorkBuddy按文件夹批量处理。

多维表格的字段设计是个技术活。我一开始随便建了几个字段，结果Skill输出的内容和字段对不上，折腾了半天才调好。建议提前规划好字段：至少要有"文档标题"、"摘要"、"关键词"、"处理时间"、"原文链接"这几个基础字段。如果要做更细粒度的知识提取，可以加"核心观点"、"行动项"、"关联文档"等字段。

提示：飞书多维表格的字段类型要和Skill的输出格式匹配。比如"处理时间"字段要设为日期类型，"原文链接"设为URL类型，否则写入时会报类型错误。

4. 蒸馏流程的核心配置：让AI按你的规则干活

4.1 定义蒸馏规则：不是所有内容都值得提炼

"蒸馏"这个词听起来很高级，但核心问题很简单：你到底想从飞书内容里提取什么？如果不定好规则，AI会给你一堆正确但没用的废话。

我的做法是先明确三类蒸馏目标：第一类是"摘要级"，就是把长文档压缩成200字以内的核心要点；第二类是"结构级"，就是提取文档中的关键信息填入多维表格的对应字段；第三类是"关联级"，就是发现不同文档之间的关联关系，比如两篇文档讨论了同一个技术方案的不同侧面。

在WorkBuddy里配置这些规则，主要是通过自定义指令来实现的。你可以给仓颉.Skill写一段提示词，告诉它按照什么规则处理内容。我常用的提示词模板大概是这样的：

你是一个专业的知识蒸馏助手。请对以下飞书文档内容进行处理： 1. 生成不超过200字的核心摘要，保留关键数据和结论 2. 提取3-5个关键词，按重要性排序 3. 识别文档中提到的行动项或待办事项 4. 判断文档类型（技术方案/会议纪要/项目复盘/竞品分析/其他） 5. 如果文档中引用了其他文档，记录引用关系 输出格式为JSON，字段包括：summary, keywords, action_items, doc_type, references

这段提示词看起来简单，但实际调优花了我不少时间。关键是要让输出格式固定下来，这样WorkBuddy才能正确解析并写入多维表格。

4.2 处理不同格式内容的差异化策略

飞书里的内容格式五花八门，文档、表格、消息记录、会议纪要，每种格式的处理策略都不一样。我踩过的最大坑就是试图用一套规则处理所有格式，结果就是每种格式都处理得不够好。

飞书文档的处理相对简单，仓颉.Skill 2.5能直接解析文档的层级结构。我的配置是保留一级和二级标题作为结构骨架，正文内容做摘要处理，代码块和表格原样保留。

多维表格的处理要复杂一些。飞书多维表格的字段类型很多，有文本、数字、日期、单选、多选、人员、附件等。仓颉.Skill能识别这些类型，但需要在配置里明确告诉它每个字段的处理方式。比如"人员"字段要提取人名，"附件"字段要记录文件名和链接。

消息记录的处理是最棘手的。飞书聊天记录里夹杂着大量噪音——表情、闲聊、重复确认。我的策略是先做一轮过滤，只保留包含链接、文件、明确结论的消息，然后再做蒸馏。这个过滤规则可以在WorkBuddy里用条件判断来实现。

4.3 定时触发与增量处理

全量处理一次飞书内容可能只需要几分钟，但如果你每天都有新内容产生，每次都全量处理就太浪费了。WorkBuddy支持定时触发和增量处理，我目前的配置是每天早上9点自动跑一次，只处理过去24小时内新增或修改过的文档。

增量处理的实现依赖于飞书文档的"最后修改时间"字段。WorkBuddy可以读取这个字段，只处理时间戳在指定范围内的文档。这个配置在WorkBuddy的触发器设置里可以找到，选择"定时触发"→设置时间→添加过滤条件"最后修改时间>当前时间-24小时"。

注意：增量处理有个小坑——如果一篇文档在24小时内被修改了多次，可能会被重复处理。我的解决办法是在多维表格里加一个"内容哈希"字段，每次处理前先比对哈希值，相同就跳过。这个逻辑需要在WorkBuddy里写一小段条件判断。

5. 实测中遇到的五个坑和对应的填坑方案

5.1 飞书CLI权限不足导致读取失败

这是我最开始遇到的最头疼的问题。WorkBuddy通过飞书开放平台的API读取文档，但有些企业版飞书默认不开放文档读取权限。表现就是授权成功了，但一读取文档就报"权限不足"。

排查过程是这样的：先确认WorkBuddy的授权范围是否包含"读取文档"权限，然后检查飞书企业后台的"应用管理"里是否限制了第三方应用的文档访问。如果企业管理员没有开放这个权限，你需要联系管理员开通，或者改用个人版飞书。

我当时的解决方案是双管齐下：一方面让管理员开通了文档读取权限，另一方面在WorkBuddy里配置了一个备用方案——如果API读取失败，就通过飞书文档的"导出"功能先导出为Markdown，再让仓颉.Skill处理本地文件。这个备用方案虽然多了一步，但稳定性更高。

5.2 长文档截断导致摘要不完整

飞书文档动辄几千字，有些技术方案甚至上万字。仓颉.Skill 2.5虽然支持长文本处理，但底层模型有token限制，超长文档会被截断，导致摘要只覆盖了前半部分。

我的解决方案是分段处理。在WorkBuddy里配置一个预处理步骤：先按标题层级把长文档拆成多个段落，每段单独做摘要，最后再合并。这个逻辑听起来复杂，但WorkBuddy的"文本分割"功能可以直接实现，只需要设置好分割规则（比如按二级标题分割，每段不超过2000字）。

合并摘要的时候也有技巧。不能让AI简单地把各段摘要拼在一起，那样会丢失段落之间的逻辑关系。我的做法是在合并时给AI一个额外的提示："以下是同一篇文档不同章节的摘要，请整合成一份连贯的全文摘要，保持原文的逻辑结构。"

5.3 多维表格字段类型不匹配

前面提过字段类型的问题，这里展开说一下具体的报错和解决过程。最常见的报错是"字段类型不匹配：期望单选，实际为文本"。这是因为仓颉.Skill输出的"文档类型"是一个字符串，但多维表格的"文档类型"字段设为了单选类型。

解决办法有两种：一是把多维表格字段改为文本类型，简单粗暴但失去了单选的筛选优势；二是在WorkBuddy里加一个"字段映射"步骤，把Skill输出的字符串映射到单选选项上。我选了第二种，因为单选字段在后续筛选和统计时更方便。

字段映射的配置需要在WorkBuddy的"数据处理"模块里完成。具体操作是：添加一个"映射"步骤→选择源字段（Skill输出的doc_type）→选择目标字段（多维表格的文档类型）→配置映射关系（比如"技术方案"→"技术方案"选项）。如果Skill输出了映射表里没有的值，可以设置一个默认值兜底。

5.4 处理速度慢导致的超时

批量处理大量文档时，WorkBuddy可能会因为处理时间过长而超时。我处理300篇文档时遇到过这个问题，跑到一半就断了。

优化方案有三个：一是减少单次处理量，把300篇分成10批，每批30篇；二是提高并发数，WorkBuddy支持配置并发处理的数量，但要注意不要超过API的速率限制；三是优化Skill的处理逻辑，比如对于短文档跳过摘要步骤直接提取关键词。

我最后采用的是组合方案：分批处理+适度并发。每批50篇，并发数设为3，这样既不会超时，也不会触发API限流。整个300篇的处理时间大概在15分钟左右，完全可以接受。

5.5 蒸馏结果的质量波动

这是最微妙的一个问题。同样的文档，不同时间处理，摘要质量可能不一样。有时候AI抓到了核心观点，有时候却纠结于细节。这种质量波动在处理大量文档时特别明显。

我的应对策略是"多次蒸馏+投票"。对于特别重要的文档，让仓颉.Skill跑三次，然后取三次结果的交集作为最终摘要。虽然成本翻了三倍，但对于关键文档来说值得。对于普通文档，跑一次就行，质量波动可以接受。

另外，提示词的稳定性也很重要。我建议把调好的提示词保存为模板，不要每次临时写。WorkBuddy支持保存自定义指令模板，这个功能一定要用起来。

6. 进阶玩法：从单篇蒸馏到知识网络构建

6.1 跨文档关联：让知识自己"长"出来

单篇文档的蒸馏只是第一步。真正有价值的是把多篇文档关联起来，形成知识网络。仓颉.Skill 2.5支持跨文档的关联分析，具体做法是在处理每篇文档时，同时提取"关键实体"（比如技术名词、项目名称、人名），然后通过实体匹配来发现文档之间的关联。

我在WorkBuddy里配置了一个后处理步骤：所有文档处理完后，跑一个"关联分析"任务，输入是所有文档的实体列表，输出是一个关联矩阵。这个矩阵会告诉我哪些文档讨论了相似的主题，哪些文档之间存在引用关系。

这个关联矩阵可以直接写入飞书多维表格，用一个"关联文档"字段来记录。后续在飞书里查看时，就能看到每篇文档的"相关文档"列表，点击就能跳转。这个功能对我的知识库管理帮助极大，以前找相关文档全靠记忆，现在系统自动推荐。

6.2 定期更新：让知识库"活"起来

知识库最怕的就是"建完就死"。我见过太多人花大力气建了一个知识库，然后就没有然后了。WorkBuddy的定时触发功能可以解决这个问题——设置一个每周跑一次的全量更新任务，重新蒸馏所有文档，更新摘要和关联关系。

全量更新和增量更新的策略不同。增量更新只处理新文档，全量更新会重新处理所有文档。全量更新的好处是能发现新的关联关系（因为新文档可能和旧文档有关联），坏处是耗时较长。我的配置是：每天增量更新，每周全量更新一次。

全量更新时要注意版本控制。我建议在多维表格里保留历史版本，每次全量更新生成一个新版本，而不是覆盖旧版本。这样如果新版本的质量不如旧版本，还可以回滚。WorkBuddy支持写入时附加时间戳，配合多维表格的版本管理功能就能实现。

6.3 从蒸馏到生成：让AI帮你写文档

蒸馏的终极目标不是整理，而是生成。当你有了一个结构化的知识库之后，可以让AI基于这些知识来生成新的文档。比如我要写一份技术方案，可以先让仓颉.Skill从知识库里检索相关文档，提取关键信息，然后生成一份初稿。

这个流程在WorkBuddy里的配置是：创建一个新的工作流→输入是"写作主题"→第一步调用仓颉.Skill的"知识检索"能力，从多维表格里找到相关文档→第二步调用"内容生成"能力，基于检索结果生成初稿→第三步把初稿写入飞书文档。

我实测下来，生成的初稿质量大概能达到"可用"的水平，大概能节省60%的写作时间。剩下的40%主要是调整语气、补充细节、核实数据。虽然不能完全替代人工写作，但作为初稿生成工具已经非常高效了。

提示：生成的内容一定要人工审核后再使用。AI可能会把不同文档的信息混淆，或者生成看似合理但实际错误的内容。我的习惯是生成后先通读一遍，标记出需要核实的地方，逐一确认后再定稿。

7. 关于成本、效率和适用边界的实话实说

7.1 成本核算：免费的是工具，不免费的是模型

标题里说"免费蒸馏"，指的是WorkBuddy和仓颉.Skill本身是免费的。但底层AI模型的调用是需要付费的，这部分成本取决于你用的模型和处理量。我算过一笔账：处理一篇3000字的文档，大概消耗2000-3000个token，按主流模型的价格，成本在几分钱到一毛钱之间。300篇文档一个月，成本大概在10-30元。

如果你用更便宜的模型，成本可以进一步压缩，但质量会打折扣。我的建议是：日常文档用便宜模型，重要文档用贵模型。WorkBuddy支持按任务切换模型，这个灵活性要用起来。

另外，飞书本身的API调用也有配额限制。免费版飞书和企业版飞书的API配额不同，如果你处理量特别大，可能需要升级飞书套餐。这个成本也要考虑进去。

7.2 效率对比：手动整理vs自动蒸馏

我做过一个对比测试：同样处理50篇文档，手动整理（阅读+写摘要+归档）大概需要4-5小时，自动蒸馏（配置+运行+检查）大概需要30分钟。效率提升接近10倍。

但自动蒸馏不是万能的。对于需要深度理解、需要结合上下文判断的内容，AI的处理质量还是不如人工。我的策略是：常规文档自动处理，核心文档人工+AI结合处理。这样既保证了效率，又保证了关键内容的质量。

还有一个隐性成本：配置和调优的时间。我第一次搭建这套流程花了大概两天时间，包括安装、配置、调试、优化。但这是一次性投入，后续的边际成本几乎为零。如果你只是偶尔处理几篇文档，可能不值得花这个时间；但如果你是长期、大量处理，这个投入非常划算。

7.3 适用边界：什么内容适合蒸馏，什么不适合

不是所有飞书内容都适合自动蒸馏。根据我的经验，适合蒸馏的内容包括：技术文档、会议纪要、项目复盘、竞品分析、行业报告。这些内容的共同特点是结构相对清晰、信息密度高、有明确的要点。

不适合蒸馏的内容包括：创意讨论、头脑风暴记录、情感交流、需要高度上下文理解的内容。这些内容往往逻辑跳跃、信息碎片化，AI很难提炼出有价值的摘要。强行蒸馏的结果就是一堆正确的废话。

还有一个边界是隐私和敏感内容。如果你的飞书文档包含敏感信息，建议不要用第三方AI处理。虽然WorkBuddy和仓颉.Skill都有数据安全措施，但把敏感内容发给AI模型始终存在风险。我的做法是：敏感文档单独标记，跳过自动蒸馏流程，手动处理。

8. 我在这套流程上积累的几个实用技巧

第一个技巧是关于提示词的。很多人写提示词喜欢写得很长很详细，但实际用下来，简洁明确的提示词效果更好。我的经验是：提示词控制在200字以内，只写最核心的规则，剩下的让AI自己发挥。太长的提示词反而会让AI"过度思考"，输出一些不必要的内容。

第二个技巧是关于错误处理的。WorkBuddy的工作流跑久了难免会遇到错误，关键是要让错误可追溯。我的做法是在每个处理步骤后面加一个"日志记录"节点，把输入、输出、错误信息都写到本地文件里。这样出问题的时候可以快速定位是哪一步出了错。

第三个技巧是关于结果验证的。自动蒸馏的结果不能全信，我养成了一个习惯：每次批量处理完后，随机抽10%的结果人工检查。如果发现质量下降，就回头检查提示词或者模型配置是不是出了问题。这个抽检习惯帮我避免了好几次"批量生产垃圾"的事故。

第四个技巧是关于版本管理的。我的多维表格里有一个"处理版本"字段，每次修改蒸馏规则后，新处理的结果会标记新的版本号。这样可以对比不同版本的效果，也方便回滚到之前的版本。

第五个技巧是关于社区资源的。仓颉.Skill的社区里有很多人分享的提示词模板和配置方案，我从中借鉴了不少。建议新手先去社区逛一圈，看看别人是怎么配置的，能少走很多弯路。WorkBuddy的官方文档也值得细读，特别是"最佳实践"部分，里面有不少官方推荐的配置方案。

这套流程我跑了大概三个月，中间迭代了七八个版本，现在算是比较稳定了。如果你也在用飞书管理大量内容，强烈建议试试这个组合。刚开始可能会觉得配置有点复杂，但一旦跑通，后面就是躺着收结果了。