把“蒸馏”这个词用在飞书上是我最近折腾 WorkBuddy 和仓颉.Skill 2.5 时的真实体会。很多人一听蒸馏第一反应是知识蒸馏、模型蒸馏把大模型的能力压缩进小模型但这里说的蒸馏飞书含义更接地气——把飞书里散落的文档、表格、多维表格、消息记录抓出来浓缩成 AI 能直接消费的结构化知识。这套组合我已经跑通了一段时间今天就把它写成一篇能直接照着做的实操文章送给正在用飞书做知识管理、又想让 AI 自动处理这些内容的团队和个人。先说结论WorkBuddy 负责调度和干活仓颉.Skill 2.5 负责把“怎么蒸馏”这件事定义成可复用的技能飞书开放平台负责把数据吐出来。三样东西组合在一起不需要额外付费就能把飞书里的任何内容变成 AI 知识库的原料。我自己天天在飞书里写周报、维护多维表格、存各类文档折腾之前每天至少花半小时手动整理折腾之后五分钟内全部做完。文章里我会把链路拆开讲每一步都给出可以直接复制的配置和命令也会把踩过的坑一个个列出来。1. 为什么要把飞书内容“蒸馏”出来知识碎片化的真实困境飞书对我来说是双刃剑。一方面它真的很能装东西文档、知识库、多维表格、妙搭应用、群消息、云盘文件几乎把团队的全部工作痕迹都收在里面。另一方面恰恰因为太能装内容一旦多起来就成了一个巨大的“知识黑盒”——东西全在里面但你需要的时候根本找不全更别提让 AI 去理解它们。1.1 飞书沉淀了什么以及为什么 AI 吃不到我自己的飞书工作台里长期维护的东西大致有四类第一类是日常文档包括产品需求、会议纪要、复盘报告第二类是多维表格比如项目排期、客户跟进表、周报收集表第三类是零散消息群里讨论的结论、决策截图、临时发的链接第四类是妙搭应用和自动化流程本身也在产生新数据。这四类内容的共同问题是它们对人眼来说是“可读的”但对 AI 来说是“断裂的”。一个 LLM 不会自动去翻你的多维表格也不会自己去理解你这周的周报里到底有没有风险项。即使你把这些文档一股脑喂给 AI它也只能拿到孤立的文本抓不住字段之间的关联更说不清哪条记录是本周新增的、哪个字段是上周更新过的。所以我说的“蒸馏”本质上不是把飞书当成普通文档仓库来复制粘贴而是做三件事把分散的内容抓取出来把非结构化的文本解析成结构化数据再按一套预设的规则浓缩成 AI 可以反复使用的知识资产。这套思路和模型蒸馏里的“教师模型教学生模型”虽然机制完全不同但精神是一致的——从冗余中提炼精华从大而全中抽出小而准。1.2 “蒸馏”在这里到底是什么意思为了避免歧义我先把词界定清楚。模型蒸馏、知识蒸馏是深度学习领域的概念目标是把大模型的能力迁移到小模型上而在 WorkBuddy 加仓颉.Skill 这套场景里蒸馏指的是“数据蒸馏”或者说“内容再加工”原始内容在飞书里是半结构化甚至纯非结构化的状态经过蒸馏之后变成了干净的、带标签的、AI 可以直接读的 JSON 或 Markdown。举个例子。飞书多维表格里的客户跟进记录原始状态是一个宽表里面“跟进情况”这一列全是长文本写到什么算什么风格也五花八门。蒸馏之后我希望得到的是这样一条记录客户名称、跟进人、最新阶段、风险等级、下次跟进时间。每一个字段都清晰、可排序、可统计。这个过程需要 AI 去读原文、理解语义、再抽取字段靠人工做工作量很大靠 WorkBuddy 加仓颉.Skill 就能自动化。还有一个容易被忽略的点蒸馏飞书内容不只是“读出来”还包括“写回去”。输出后的结构化知识可以再生成飞书多维表格回填、生成新的飞书文档草稿或者推送到群里。这相当于给飞书装上了一个“知识吞吐”的管道——读得出来、转得动、还吐得回去。这一层的价值比单纯导出文档高得多因为它在改变工作流本身而不是在保留一个静态的副本。2. 搭建前的三个核心判断WorkBuddy、仓颉.Skill 2.5 与飞书的连接方式这个方案涉及三样东西很多人一开始会卡在概念上WorkBuddy 是干什么的仓颉.Skill 2.5 又是什么飞书怎么连进去我按照自己的理解把它们拆成三个问题来回答一个负责执行一个负责定义能力一个负责提供数据。想清楚这三者的关系后面配置就不会乱。2.1 WorkBuddy 与仓颉.Skill 2.5 各自解决什么问题WorkBuddy 在我眼里是一个 AI Agent 工作台它的核心能力是承接任务、调度工具、执行多步骤操作。你可以给它下指令它会在自己的工作台里调用各种工具去完成任务。从我用下来的感受看它特别适合做“批处理”和“流水线”类的事情比如批量处理本地文档、定时抓取网页内容、按固定模板生成报告。这正好符合蒸馏任务的特性重复、有规则、需要多步操作。仓颉.Skill 则是把“能力”封装成技能包的体系。这里的 Skill 不是指某一个具体的模型而是一整套可配置的技能定义它告诉 WorkBuddy 遇到某类任务时该怎么拆步骤、调哪些工具、按什么格式输出。2.5 版本我印象比较深的变化是对技能文件的结构做了更强约束技能描述、触发条件、步骤流程、输出Schema 分得更清楚。换句话说2.5 更强调“技能是你自己定义出来的标准作业流程”而不是让 AI 自由发挥。放在蒸馏飞书的场景里分工就很明确了WorkBuddy 是发动机仓颉.Skill 2.5 是发动机上插的那块控制程序飞书则是油箱。没有 WorkBuddy技能定义得再漂亮也跑不起来没有仓颉.SkillWorkBuddy 不知道该按什么路径去处理飞书内容没有飞书开放接口前面两个再强也拿不到源数据。2.2 飞书接入方式的选型对比连接飞书主要有三条路开放平台 API、机器人 Webhook、CLI 命令行工具。我全部试过一遍最后留下了开放平台 API 作为主力理由很简单它最稳、权限最细、能覆盖文档和多维表格两类核心数据源。开放平台 API 的接入方式是在飞书开放平台后台创建一个自建应用拿到 App ID 和 App Secret然后给应用开通需要的权限范围比如“查看文档”“查看表格”“读写多维表格”。之后通过代码换取 tenant_access_token再拿这个 token 去调用具体的 API。整个过程不需要买任何付费套餐免费额度对个人和小团队来说足够用。机器人 Webhook 更适合做“触发”和“通知”比如蒸馏完成后把结果自动推送到群里或者有人发特定指令时触发一次蒸馏任务。CLI 工具则是飞书官方提供的命令行接口适合在本地脚本里快速执行一些操作但有一个常见的前提条件你的飞书账号需要开通 CLI 权限否则会直接报错。这个权限问题后面我专门写了一段因为它是很多人配置失败的第一道坎。接入方式适合场景权限要求我的建议开放平台API文档、多维表格批量读写后台配置App权限主用覆盖度最高机器人Webhook定时触发、结果通知建机器人、配Webhook辅助做自动化通知CLI命令行快速脚本操作、本地方便账号需有CLI权限看账号情况再启用2.3 环境安装的细节清单安装部分WorkBuddy 有网页版、桌面客户端、Linux 安装包几个形态我自己在 Windows 和 Ubuntu 上都跑过。如果你用的是 Ubuntu安装后第一件事是确认版本和工作目录有时候系统缓存目录默认放在根分区时间一长会被日志撑爆所以我建议尽早把缓存目录改到数据盘。仓颉.Skill 2.5 这边重点是导入技能文件的方式。有些版本支持在界面里直接导入有些需要放到指定目录下。我习惯把技能文件集中管理用类似如下的目录结构区分skills/ ├── feishu_distill/ │ ├── skill.yaml │ ├── prompts/ │ └── scripts/ └── common/ ├── fetch_doc.py └── to_markdown.py这样的组织方式有两个好处一是每个蒸馏任务对应一个独立技能目录互不干扰二是公共脚本可以复用不会在多个技能里重复粘贴代码。飞书这边的准备工作相对固定后台建应用、配权限、拿 App ID/App Secret、把 API 调用脚本写好、验证 token 能拿到数据。这一环通了后面的蒸馏链路才有根。3. 蒸馏链路的完整拆解从飞书源数据到 AI 知识库我把一次完整的蒸馏任务抽象成四个阶段采集、解析、蒸馏、输出。这四个词听起来很学术实际上对应的是四次具体的动作。一次合格的蒸馏不是让 AI 直接“读一遍飞书然后总结一下”而是每一步都有明确的输入输出每一步都对结果负责。3.1 一条蒸馏任务的数据流以一个具体任务为例我要把多维表格里的“客户跟进记录”蒸馏成本地知识库的 Markdown 文件。数据流是这样的第一步通过飞书 API 读取多维表格的表结构和记录注意这里不是简单拉全部数据而是要带上字段名、字段类型、记录ID第二步把每一条记录里的长文本字段单独提取出来传给 AI 做语义解析第三步AI 根据预设规则抽取关键字段比如“风险等级”“下一步动作”“需要升级处理吗”第四步把结构化结果写入目标文件并按创建时间生成索引。3.2 用 Skill 文件把“蒸馏规则”固化下来仓颉.Skill 2.5 最让我满意的点是它能把上面这套流程固化成一份技能文件之后每次执行都走同一套标准。技能文件里至少要写清楚以下内容技能名称和描述、触发条件、执行步骤、输入输出 Schema。拿客户跟进蒸馏来说一份简化版的 skill.yaml 会长得像下面这个样子name: feishu_customer_distill version: 2.5 description: 从飞书多维表格中提取客户跟进记录的关键字段。 trigger: type: command keyword: 蒸馏客户跟进 steps: - action: feishu.bitable.list_records params: app_token: {{app_token}} table_id: {{table_id}} - action: llm.extract_fields params: target_fields: [客户名称, 跟进人, 最新阶段, 风险等级, 下次跟进时间] output_schema: json - action: local.write_file params: format: markdown target_dir: knowledge/customer_followup这份文件的含义很直白触发关键词是“蒸馏客户跟进”先拉多维表格记录再用 LLM 抽取指定字段最后写成 Markdown 文件。Skill 的价值在于你不需要每次重新告诉 AI 要提取哪些字段、用什么格式输出它一看到触发条件就会自动按这套规则执行。配置一次长期生效。3.3 输出格式与目标位置的选择输出层是很多人会忽略但影响很大的环节。我建议输出格式优先选 JSON 或 Markdown不要直接输出纯文本。原因是纯文本丢失了字段边界AI 后续再次消费时需要重新解析等于做了两次蒸馏效率大打折扣。JSON 适合给程序用比如回写到数据库、同步到另一个多维表格Markdown 适合给人和知识库用方便阅读和检索。两者可以同时输出一份做永久存储一份做展示层。目标位置的安排我推荐按“源数据归属”来组织目录而不是按时间堆在一起。比如knowledge/feishu/下面再按项目、客户、周报分目录蒸馏结果就落在对应目录里。这样后期找数据、做全量重建都非常方便。如果源数据本身有更新机制比如周报是每周新增的我还会在输出时附带一个采集时间戳避免数据覆盖导致历史丢失。4. 实战把飞书多维表格蒸馏成团队周报知识库概念讲完上一段实际能跑的案例。我选的是“团队周报蒸馏”因为这个场景几乎是所有团队都会遇到的而且飞书里周报的存放形式各异有人写在文档里有人填在多维表格里有人直接丢群里。正好可以展示蒸馏对不同数据源的兼容能力。4.1 场景设定与实际痛点我模拟的团队每周五大家会在一个共享多维表格里填写本周进展、风险、下周计划。表格字段包括姓名、所属项目、本周进展长文本、风险与阻塞长文本、下周计划长文本、填表时间。平时没问题问题是月底做汇报时需要把四周的内容汇总成一份月度摘要挑出重点进展和风险再按项目归堆。手动干的话你得把每个人的长文本读一遍再提炼出几行话非常费眼。4.2 仓颉.Skill 蒸馏规则配置我写的蒸馏规则目标是从“本周进展、风险与阻塞、下周计划”三个长文本字段里分别抽取出不超过三条要点的摘要再追加一个“是否需要管理层关注”的判断字段。配置如下name: weekly_report_distill version: 2.5 description: 将飞书多维表格中的周报记录蒸馏为结构化月度摘要。 steps: - action: feishu.bitable.query params: time_range: {{last_month}} - action: llm.paragraph_compress params: field_mapping: 本周进展: [进展1, 进展2, 进展3] 风险与阻塞: [风险1, 风险2] 下周计划: [计划1, 计划2] add_judgement: 是否需要管理层关注 - action: local.write_markdown params: output_dir: knowledge/weekly_reports index_by: 项目为了让 AI 理解“摘要”的标准我也会在技能文件里追加一段提示词说明压缩的原则保留可验证的事实删除形容词和寒暄风险项必须保留原意不要美化。这一步很关键因为同样的 LLM 在没有任何约束时给出的摘要经常会缺失风险信息——它天然倾向于“汇报好消息”而蒸馏要保留的是全部关键信息不是按 AI 的喜好重新创作。4.3 执行链路与实测结果执行时我只需要在 WorkBuddy 里触发关键词“蒸馏上周周报”它就会自动去飞书拉取最近一周的多维表格记录逐条解析按规则输出 Markdown。下面是一段执行后的真实输出已做脱敏### 项目Alpha - 进展1: 完成模块A开发并通过内部评审 - 进展2: 集成测试用例覆盖率达85% - 风险1: 第三方SDK接口稳定性不足需关注 - 是否需要管理层关注: 是 ### 项目Beta - 进展1: 需求文档初稿完成待评审 - 进展2: 启动前端原型设计 - 风险1: 无 - 是否需要管理层关注: 否说实话第一次跑通的时候我挺意外的。整张多维表格四十多条记录蒸馏加输出总共花了不到两分钟而且风险字段没有丢。换作人工整理至少要花二十分钟以上还得忍受漏看。现在每周五晚上我自动执行一次周一的晨会材料直接就有现成的摘要稿。5. 进阶玩法与避坑清单把这些坑提前填平工具好用不代表路上没有坑。我把这段时间遇到的典型问题整理成清单按“权限接入层、内容解析层、自动化运转层”三部分展开。你如果照着搭大概率能少走一半弯路。5.1 权限与接入层的坑第一坑飞书账号没有 CLI 权限。这个报错信息非常迷惑它不会告诉你解决办法只会让你怀疑是不是凭证写错了。实际上CLI 权限需要在飞书后台由管理员开通普通成员默认是没有的。如果你只是自己用我建议跳过 CLI直接用开放平台 API免得卡在这一步。如果你确实需要 CLI 去做本地方便的脚本操作那就要走权限申请流程并且确认 WorkBuddy 所在机器能用这个账号完成认证。第二坑App 权限范围没有配全。很多人建完自建应用只开了“读取文档”的权限结果调用多维表格接口时报 no permission。飞书的权限是分细项的文档、表格、多维表格、消息、通讯录都是独立权限项。我建议在建应用时把可能要用的权限一次性勾上省得后面来回补。第三坑WorkBuddy 的国际版和国内版差异。如果你用的是 WorkBuddy 国际版默认的 API 端点、数据存储位置和国内版不同连接飞书时要注意走哪个环境。我自己一开始环境选错拿到的 token 一直 401排查了半天才发现是应用域名选错了。5.2 内容解析层的坑第四坑长文本字段的截断和格式污染。飞书多维表格里的长文本通常自带换行、缩进、提及导出来后如果直接喂给 LLMAI 很容易把换行和缩进误当成内容边界。我的处理办法是在调用 API 时先做清理统一把换行替换为句号分隔把 提及去掉再交给 LLM。这个清理脚本放在公共脚本里每个技能都可以调用。第五坑多维表格的分页问题。数据量稍微一大一次 API 请求是拉不完所有记录的需要按 page_token 翻页。最简单的做法是写一个循环拉取把所有记录合并后再进入解析阶段。不要偷懒只取第一页。第六坑对“蒸馏”结果的预期管理。蒸馏是对已有内容的精华浓缩不是让 AI 帮你生成全新的知识。如果你输入源本来就是空的或信息极少任何蒸馏配置都变不出有价值的内容。我见过有人配置完技能发现输出太单薄埋怨工具不行其实问题出在源头数据质量上。这恰恰说明蒸馏系统会逼着你把飞书里的内容维护得更好——因为数据不干净最后出来的蒸馏物一定不干净。5.3 让蒸馏自动化运转的小技巧最后分享几个让这套体系真正“转起来”的技巧。第一给 WorkBuddy 定义全局指令让某些规则对后续所有任务生效比如规定所有输出文件都要带日期前缀、所有摘要都要注明来源记录ID。这样你不需要在每个技能里重复配置。第二把触发方式改成定时任务。飞书蒸馏这件事最怕的不是执行慢而是你忘了跑。我建议把周报蒸馏、项目进展蒸馏这类周期性任务挂到定时机制里每周固定时间自动触发结果自动落盘做到真正无人值守。第三善用回写能力。蒸馏结果不一定要停在本地文件里你也可以用一个技能把结构化结果回写到飞书的另一个多维表格比如从周报蒸馏出“月度风险汇总表”自动生成一张新表。这样飞书里的数据就形成了一个闭环原始数据在表格里蒸馏结果也在表格里人看表格、AI 读表格各取所需。折腾这套东西大半个月我最大的体会是蒸馏的本质不是让 AI 替你决定要什么而是你先想清楚你要什么再把规则固化成 Skill最后交给工具去执行。WorkBuddy 和仓颉.Skill 2.5 提供的只是一个可复用的骨架真正让它有价值的是你对业务的梳理——哪些字段是重要的哪些内容是噪音哪些结果需要回写给团队。把这些问题想明白飞书里那些零散内容就不再是黑盒而是随时可以蒸馏出来的知识资产。