第一次看到“用 WorkBuddy 仓颉.Skill 2.5 免费蒸馏飞书的任何内容”这个玩法我第一反应是标题党吧后来花了几周时间把 WorkBuddy、仓颉.Skill 2.5 和飞书开放 API 串在一起真正跑通了文档、多维表格、群消息三条蒸馏流水线才发现这条路不仅可行而且成本确实能被压到零。所谓“蒸馏飞书”本质上就是把飞书当成知识原料库用 AI 代理去读、去清洗、去结构化最后沉淀成一份 AI 能长期调用的技能包而不是简单地把文档下载到本地。这套玩法适合两类人一类是天天泡在飞书里、文档和表格多到翻不过来的团队成员想把这些存量知识变成 AI 的上下文另一类是搞自动化流程的开发者希望让 AI 定时去飞书“收菜”自动整理周报、FAQ、SOP。只要你能拿到飞书开放平台的应用凭证整个过程不花一分钱。接下来我就把这套组合拳拆开从安装到踩坑完整走一遍。1. 一套玩法拆解为什么是 WorkBuddy 仓颉.Skill 2.51.1 蒸馏这个词用在飞书上到底是什么意思“蒸馏”原本是模型训练里的概念指的是把大模型教师网络学到的知识迁移到小模型学生网络里典型的有白盒蒸馏、黑盒蒸馏。但在飞书这个场景里我们借用了同一个字面意思把大量原始信息“收汁”留下精华。飞书里的原始内容有一个共同问题——噪声太多。文档里有大量重复的目录、过时的版本、口语化的碎碎念多维表格里字段类型五花八门人员、日期、附件摞在一起群消息更是碎片化重灾区。直接把这些东西丢给 AI上下文会被撑爆回答质量也会被垃圾信息拖垮。所以要先做一个蒸馏动作抽取、清洗、结构化、归档最后变成一份干净的 Markdown 或 JSON再喂给 AI 使用。我个人的理解是模型蒸馏是把能力从一个模型搬到另一个模型而 skill 蒸馏是把散落在业务系统里的知识变成 AI 可复用的“技能包”。这也是为什么社区里会同时出现“知识蒸馏代码”、“skill 蒸馏”这些搜索词——大家都在探索同样一件事只是叫法不同。1.2 为什么选 WorkBuddy 当载体市面上的 AI 代理工具有不少Codex 有飞书插件Claude Code 也有人接 cc-connect 连飞书为什么我最终选了 WorkBuddy主要是三个原因。第一WorkBuddy 是本地优先的代理工作台核心功能个人使用免费。这一点很重要因为蒸馏飞书是个反复试错的过程API 调用次数不少如果用按量计费的工具跑成本会失控。第二它有完善的 Skill 机制。Skill 不是简单的一段提示词而是“描述文件 脚本 资源文件”的组合可以封装一个完整的自动化任务。仓颉.Skill 2.5 这种技能包放进去就能用系统会自己读取技能说明按步骤执行。第三WorkBuddy 可以自定义全局指令。这意味着你可以定一套规则让后续所有任务都生效不用每次重复交代。比如说“蒸馏结果必须输出到指定目录”“遇到飞书 API 限频就自动等待重试”这些规则写到全局配置里整个工作流都会遵守。我把 WorkBuddy 和同类方案做了个对比方便你判断方案Skill 机制免费额度本地脚本支持飞书接入方式WorkBuddy完善支持技能包加载核心功能免费强可直接跑 Python通过 MCP / HTTP APICodex 飞书插件依赖插件按量收费为主一般插件自带Claude Code cc-connect有但配置略重受账号限制强通过 MCP Server当然工具这东西没有绝对的“最好”只有“最适合”。如果你已经深度使用某个工具也不一定非要换但如果你想专门搞一条低成本的飞书蒸馏流水线WorkBuddy 这套组合确实顺滑。1.3 仓颉.Skill 2.5 在里面扮演什么角色仓颉.Skill 从名字就能看出来它管的是“整理文字”这件事。2.5 版本的核心能力是让 AI 自动处理本地文档尤其是用来做知识结构化的那套 Python 脚本。它在蒸馏流水线里承担三个职责一是读取原始内容不管是本地 Markdown 还是飞书 API 返回的 JSON二是做清洗和分块把长文本拆成适合送给大模型处理的片段同时去掉无效格式三是输出结构化结果通常是一份带层级标题的 Markdown或者一份字段规整的 JSON。我为什么要强调 2.5因为在实测中它对长文档的分块策略明显更稳。之前的版本容易出现标题错位、代码块丢失2.5 在分块时会保留上下文关联不再是一个无脑按字数切片的工具。这直接影响蒸馏质量——清洗环节做得不干净后面喂给 AI 的知识就是一团乱麻。2. 环境准备先把三样东西凑齐2.1 WorkBuddy 安装与目录规划WorkBuddy 的安装不算难Windows、Linux、Ubuntu 都有对应的安装包热词里大量出现“WorkBuddy 安装教程”“WorkBuddy Linux 安装包”说明很多人在第一步就卡住了。其实核心就两步下载正确版本的安装包然后设置一个专门的工作目录。有两点体验值得先说。第一很多人问“WorkBuddy 系统缓存目录能不能改到 D 盘”——可以在配置里自定义缓存路径就行尤其是你会用它跑大量蒸馏任务时默认的 C 盘空间很容易被撑爆。第二网上流传的“WorkBuddy 国际版”和本地版没有本质区别只是中文文档完整度不同功能上不用太纠结。我建议目录按这个结构规划后面跑蒸馏会很省心workbuddy/ skills/ # 技能包目录 cangjie_2.5/ # 仓颉.Skill 2.5 knowledge_base/ # 蒸馏后的知识库 feishu_docs/ feishu_tables/ feishu_messages/ exports/ # 临时导出文件 logs/ # 流水线日志目录规划的核心目的是让 AI 知道“什么东西放哪里”。否则蒸馏完了结果散落在各个临时文件夹里AI 想用也用不上。2.2 仓颉.Skill 2.5 的接入方式把仓颉.Skill 2.5 放进 skills 目录后还需要在 WorkBuddy 里确认它被正确加载。一般可以在对话里直接问“当前加载了哪些技能”或者输入“列出技能”这样的指令看系统能不能识别到“仓颉.Skill 2.5”这个名字。Skill 包的内部结构通常是这样的cangjie_2.5/ SKILL.md # 技能描述文件AI 靠它理解技能用途 scripts/ cangjie_tool.py # Python 实现负责清洗和结构化 data/ # 可选的参考数据 requirements.txt # Python 依赖如果你的环境缺少依赖先装一下 requirements.txt 里的库。我在新环境里跑的时候踩过坑直接调用技能报了 ModuleNotFoundError其实就是少了一个 requests。装完之后可以先用一个本地测试文档跑一遍“整理文档”的功能确认 Python 脚本能正常执行再接飞书。还有一个小技巧如果你希望这套规则对所有任务都生效可以把它写进 WorkBuddy 的全局指令比如“执行前先检查技能是否可用不可用则提示安装”。这样就不用每次手动指定了。2.3 飞书侧的准备机器人、应用凭证与权限想访问飞书内容必须走飞书开放平台的 API。你要做的第一件事是在飞书开放平台创建一个企业自建应用然后拿到两个关键凭证App ID 和 App Secret。这两个值放在配置里或环境变量里不要硬编码在脚本里方便后续替换。接着是开通权限这是整个过程中最容易糊涂的一步。我整理了一份对照表以当时实测可用的权限名为准想蒸馏的内容需要的权限飞书云文档查看文档内容docx:document:readonly多维表格记录查看多维表格数据bitable:app:readonly群消息记录查看消息内容im:message:readonly给群里发结果发送消息im:message:send权限开通后不是立刻生效的需要在应用“版本管理与发布”里创建一个新版本并发布权限才会真正生效。很多人卡在“403 permission denied”这一步排查了半天才发现权限根本没发布出去。如果准备蒸馏群消息还需要把机器人拉进对应的群里不然机器人读不到消息。文档和表格则只要应用有权限可以通过 URL 里的 token 直接访问。另外提醒一下如果你是个人开发者在自己的测试群里玩尽量用测试企业的管理员账号给自己开权限不要直接在生产团队里操作避免把线上数据搞乱。2.4 把访问凭证理清避免第一步就 401飞书 API 的访问凭证有两种tenant_access_token 和 user_access_token。蒸馏常规内容用 tenant_access_token 就行它是应用身份凭证获取方法是拿 App ID 和 App Secret 换 token。import requests app_id your_app_id app_secret your_app_secret url https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal resp requests.post(url, json{ app_id: app_id, app_secret: app_secret }).json() tenant_access_token resp.get(tenant_access_token) print(tenant_access_token[:20])这个 token 一般有两个小时的时效过期后要重新获取。我习惯在脚本里封装一个 refresh_token 的函数每次调用 API 前检查一下有效期省得跑大批量任务时突然断掉。网络里很多“飞书没有 CLI 权限”的搜索其实就源于这一步没有理清——访问飞书内容是靠 HTTP API不是靠终端里敲命令。3. 蒸馏实操从飞书到 AI 技能包3.1 蒸馏文档把飞书云文档拉成本地 Markdown飞书文档的 URL 一般长这样https://xxx.feishu.cn/docx/Wdxxxxxx结尾这串字符就是 document_id接下来调用文档接口把文档的 block 全部拉出来。文档内容是分块存储的每个块有自己的类型比如标题、段落、列表、代码块需要遍历并转换。我封装了一个简版函数方便你直接改着用import requests def fetch_doc_content(document_id, token): headers { Authorization: fBearer {token}, Content-Type: application/json } url fhttps://open.feishu.cn/open-apis/docx/v1/documents/{document_id}/blocks blocks [] page_token while True: params {page_size: 100} if page_token: params[page_token] page_token resp requests.get(url, headersheaders, paramsparams).json() blocks.extend(resp.get(data, {}).get(items, [])) page_token resp.get(data, {}).get(page_token, ) if not page_token: break return blocks拿到 blocks 之后就是仓颉.Skill 2.5 的主场了。把原始 block 数据交给它做清洗它会根据 block 的样式字段去还原 Markdown 结构。这一步特别关键因为直接拼接 block 的纯文本内容会把层级关系全部丢掉蒸馏出来的文档连标题层级都是乱的。我建议先小批量试一篇文章跑通后再放开到整个目录。实测下来一篇 5000 字的飞书文档从拉取到清洗成 Markdown几秒就能搞定。真正耗时的是大批量文档的网络请求和 API 限频。3.2 蒸馏多维表格让记录变成结构化 JSON多维表格的蒸馏和文档不一样文档是纯文本结构表格则强依赖字段类型。飞书多维表格的字段可能是文本、数字、单选、多选、日期、人员、附件、公式、关联字段API 返回的 JSON 里人员是一个对象数组日期是一个时间戳附件是一个带 URL 的数组。直接原样保存会有问题。比如你蒸馏一份“客户信息表”里面的“负责人”字段返回的是[{id: xxx, name: 张三}]这样的结构后面 AI 读取时还得解析对象凭空增加出错概率。所以我会在蒸馏时做一个字段归一化文本字段直接取值人员字段只留 name日期字段转成YYYY-MM-DD附件字段下载到本地并在 JSON 里保留相对路径。多维表格记录接口GET https://open.feishu.cn/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records注意这个接口也是分页的而且有 page_token 机制。我强烈建议先拉一条记录打印出来看字段结构再写批量转换逻辑千万别凭感觉写字段名映射。我在实际项目里遇到过公式字段返回结果和预期不一致的情况这种东西不能靠猜必须以实际返回值为准。蒸馏完的多维表格数据可以输出成 JSON也可以转成 CSV。我一般两者都保留JSON 喂给 AI 做分析CSV 用飞书机器人发送表格到群里方便不写代码的同事直接用。3.3 消息流与知识库沉淀群消息的蒸馏比文档和表格更“脏”因为消息天然是碎片化的可能还有大量表情、回复串、文件分享。我的做法是按话题聚合先把一段时间内的消息拉下来按时间排序然后用仓颉脚本做轻度聚类把同一主题的讨论归到一起再提取“问题-结论-负责人”这样的结构。这种蒸馏结果特别适合做团队 FAQ 和新人手册。你可以让 AI 在一个“知识库沉淀”任务里同时处理多个群的近期消息按周生成一份《群聊精华周报》。消息里的高频问题能直接转成 FAQ 条目负责人信息也能保留到字段里。这里要提醒一句消息内容涉及团队隐私生产环境的群消息处理一定要先确认合规最好只处理你明确有权限的数据。蒸馏工具本身是中性的用在哪里、怎么用边界要清楚。我会在蒸馏消息时经常用到的过滤规则写在脚本里长度少于 20 字的消息直接跳过只保留信息量足够的片段连续打招呼、表情类内容忽略带链接的消息单独标注“待人工确认”。这样能让最终的产出干净很多。3.4 用 Python 脚本和仓颉.Skill 把结果喂给 AI蒸馏的产物不是终点让 AI 能随时用起来才是终点。我的做法是把蒸馏结果放到一个固定目录然后在 WorkBuddy 的全局指令里写明所有任务开始前先检查 ~/workbuddy/knowledge_base/index.md。 如果任务涉及飞书知识优先从知识库中查找已有蒸馏结果。index.md 是一个索引文件记录了每个蒸馏产物是什么、来源是哪里、更新时间是什么。我有一段脚本自动更新这个索引每次蒸馏完就追加一行。这样 AI 在开始任务时就知道“手上有什么料”而不是每次都要重新去飞书拉一遍。整套蒸馏流水线的伪代码大致是1. 从飞书 API 拉取原始内容 2. 调用仓颉.Skill 2.5 的清洗脚本输出结构化 Markdown / JSON 3. 将产物写入 knowledge_base 对应子目录 4. 更新 index.md 索引 5. 按需用机器人消息 API 发送结果摘要到飞书群把这一步固化下来后我基本不用再手动操作。每天定时跑一次飞书里新增的文档和表格就会被自动蒸馏进知识库。所谓“让 AI 自动整理本地文档”本质上就是把这一条流水线跑顺。4. 常见问题与排查技巧实录4.1 飞书“没有 CLI 权限”到底怎么破热词里频繁出现“飞书没有 CLI 权限”这个说法其实有点误导。飞书开放平台从来没有提供过官方 CLI 工具你想在终端里直接敲命令操作飞书内容本来就不存在这个通道。真正的问题不是“没有权限”而是“不知道走 HTTP API”。解决思路有两种。一种是在脚本里用 requests 直接调飞书 REST API这也是我前文采用的方式。另一种是把飞书 API 封装成 MCP Server注册到 WorkBuddy 里让 AI 通过工具调用的方式直接读飞书。后者更“AI 原生”但对调试能力要求更高适合熟悉 MCP 的人。如果你在调用时遇到权限报错先用这个顺序排查报错原因处理方式401 invalid_tokentoken 过期或错误重新获取 tenant_access_token403 permission denied权限未授权或未发布检查应用权限并发布新版本400 invalid_param参数格式不对对照 API 文档检查参数名和类型其中 403 最常见的坑就是权限发布了但应用版本没审核通过导致线上环境依然用旧权限。4.2 文档越来越多蒸馏任务经常中断大批量蒸馏时最常见的现象是任务跑到一半就停了报超时或者限频错误。这不是脚本逻辑的问题而是没有考虑 API 的调用频率限制和长任务的稳定性。我的实战经验是三个词分批、断点、重试。分批就是一次任务只处理一定数量的文档比如 20 篇一批断点是每处理完一篇就在本地记录状态下次从断点继续重试是遇到限频错误时用指数退避等待后重试而不是直接失败退出。日志这块我也建议留一份格式虽然简单但救过我好几次doc_id: Wdxxxxxx | status: success | time: 2025-01-01 10:00:00 | output: faq_01.md有了日志任务中断后能一眼看出哪些成功哪些失败不用重新扫描全部数据。4.3 多维表格导出的字段对不上多维表格导出后字段值“变了样”通常是字段类型映射的问题。比如日期字段在 API 里是毫秒时间戳你直接用str()转字符串得到的就是一长串数字人员字段是一个对象数组直接拼进文本里会变[object Object]附件字段返回的是下载链接根本不含文件内容。我的统一做法是先解析字段元信息再写一个类型处理函数def normalize_field_value(value, field_type): if field_type datetime: return datetime.fromtimestamp(value / 1000).strftime(%Y-%m-%d) if field_type in (person, user): return value[0][name] if value else if field_type attachment: return ;.join([f[name] for f in value]) if field_type in (select, multiSelect): return value if isinstance(value, str) else ,.join(value) return value这种“字段解析器”写一次就能复用到所有表格上。另外提醒一句导出时间字段要注意时区飞书存的是 UTC 时间戳你如果直接用本地时间格式输出早晚会被早八点的记录坑一次。4.4 蒸馏之后的 skill 怎么让 AI 长期“记住”很多人蒸馏完就完了结果下次开新会话AI 又把飞书知识忘光了。原因是蒸馏产物只存在某个临时目录里AI 根本不知道它的存在自然没法用。要让 AI“长期记住”核心是把蒸馏产物变成可重复加载的资源。我在全局指令里给 WorkBuddy 定了几条规则对所有任务都生效第一条任何涉及飞书的请求先查knowledge_base索引第二条索引里找不到的内容才允许现场调用飞书 API第三条现场调用得到的原始内容必须经过仓颉.Skill 清洗后再进上下文。这三条规则一加AI 的行为就稳定很多。另外建议用版本目录管理蒸馏产物比如faq_v20250101.md不要覆盖旧文件。因为知识是不断迭代的保留历史快照能随时回退也能让 AI 比较不同时间点的差异。这里我没有用复杂的工具就是一个带日期的文件命名习惯效果却出奇地好。5. 进阶玩法把蒸馏流水线固化下来跑通单次蒸馏之后我很推荐往前再走一步把整个流程做成一条定时流水线。你不需要手动去点击每一次蒸馏而是让 WorkBuddy 按计划任务触发自动完成“拉取 → 清洗 → 归档 → 通知”的闭环。具体做的时候我会把任务拆成两个层级调度层和执行层。调度层负责定时触发比如每天凌晨两点开始跑执行层就是仓颉.Skill 2.5 封装的 Python 脚本负责处理飞书 API 调用和文档清洗。执行完成后让 WorkBuddy 调用飞书机器人接口把蒸馏摘要发送到指定的群里这样团队早上打开飞书就能看到昨天新增了什么知识条目。还有一个可以扩展的方向把蒸馏结果直接转成可训练的数据集。如果你在做模型微调或者评估飞书里的真实文档、表格和对话记录经过清洗后就是一批高质量的业务语料。仓颉.Skill 2.5 输出的 JSON 格式天然适合做微调样本只要你做好脱敏和权限确认这套流水线就能从“个人知识库”升级成“团队模型原料车间”。我个人在实际操作中的体会是不要一开始就追求“任何内容”和“全量自动化”。把范围缩小到某个文件夹、某几个群、某一张表先跑通再扩量。蒸馏这件事最怕的就是贪多一次喂给 AI 太多脏数据最后模型记住了不该记住的噪声反而比不蒸馏更糟。最后再分享一个小技巧我会给 WorkBuddy 定一条规则让它每次执行蒸馏任务前先列一个“待处理内容清单”给我确认。这样它不会自作主张地把草稿文档、临时表格甚至群里的闲聊全部收进知识库。有了这道人工闸门整个蒸馏流程既省心又可控。