把飞书里的文档、多维表格、会议纪要沉淀成自己的知识库我以前靠的是最笨的办法手动复制、粘贴、排版十几篇文档整理下来一下午就没了。后来我把 WorkBuddy 和仓颉.Skill 2.5 组合起来做“内容蒸馏”流程变成了这样飞书侧负责同步导出仓颉.Skill 负责清洗结构化WorkBuddy 负责调度和归档整套链路不花一分钱订阅费。这套玩法适合所有在飞书里积压了大量内容、又想让这些内容变成 AI 可检索资产的人不管你是做知识管理的运营还是每天被各类周报、文档、表格淹没的职场人都值得花一个下午把链路跑通。1. 这套组合到底是干什么的从“复制粘贴”到“内容蒸馏”1.1 WorkBuddy 到底是什么它和普通客户端有什么区别WorkBuddy 在我理解里更像一个本地化的 AI 任务工作台。它不是一个聊天框那么简单而是把“模型调用、文档处理、外部工具接入、定时任务”都收拢到一个界面里让你可以用一套规则去驱动 AI 干活。市面上同类工具很多偏代码生成比如 CodeBuddy 那类更贴合 IDE 场景但 WorkBuddy 的重心明显在“任务流”上从本地文件夹读取文档、按 Skill 规则加工、再把结果写回指定位置整个过程是流水线式的。很多人第一次打开 WorkBuddy 会有点懵因为它的界面不像聊天软件那样只有一个输入框而是分为任务区、文件区、Skill 区、日志区。这个设计其实是对的因为你要处理的不是一句话而是一批文件、一批任务。我自己用下来的感觉是把它当成“能跑批处理的 AI 助手”而不是“聊天机器人”思路一下子就顺了。1.2 仓颉.Skill 2.5 在中间扮演了什么角色Skill 这个词现在很火你可以把它理解成“给 AI 预装的一套行为模板”。仓颉.Skill 就是一套专门针对文档处理场景开发的技能包它把常见的文档操作拆成了很多细粒度能力长文分块、标题层级识别、关键信息抽取、表格结构还原、Markdown 转写、摘要生成等等。2.5 这个版本我重点体验下来主要是三类改进第一是长文档分段时不再轻易“断句”能跨段落保留上下文第二是对飞书导出的复杂表格识别更准了不会出现列错位第三是支持批量任务队列可以一次丢进去几十篇文档排队处理。如果把 WorkBuddy 比作厨房那仓颉.Skill 2.5 就是一套预制好的菜谱。它告诉你每一道菜先放什么、后放什么、火候怎么控制你不用每次从零开始指挥 AI。1.3 “蒸馏飞书”的本质是知识蒸馏思维“蒸馏”这个词来自 AI 领域的知识蒸馏用一个大的、复杂的模型教师模型去指导一个小的、精简的模型学生模型把核心能力提炼出来。放到飞书场景里所谓的“蒸馏”不是把文档复制一遍而是把原始内容里的有效信息提取出来、去噪、结构化最终产出一份比原文更精炼、更容易被检索和复用的知识资产。这一点很重要很多人误以为“蒸馏飞书”就是把飞书整个搬下来那是迁移不是蒸馏。真正的蒸馏结果是一篇 50 页的飞书文档最后变成一张 500 字的知识卡片、一张准确的参数表、一份可执行的清单。信息密度提升了查找成本下降了这才是蒸馏的意义。2. 为什么这套搭配能成立方案选型与核心设计2.1 飞书、WorkBuddy、仓颉.Skill 三者的分工边界任何自动化方案最怕的就是一个工具既要管采集、又要管加工、还要管存储最后什么都做不好。这套方案把分工拆得很干净飞书是数据源负责提供原始内容和开放接口WorkBuddy 是执行器负责调度模型、读写文件、调用外部服务仓颉.Skill 2.5 是加工规则负责定义“原文进来之后变成什么样子”。这个分工带来的直接好处是可替换性。今天你飞书里的内容想换成本地 Markdown 文件夹或者换成其他协作平台的导出文件你只需要换数据源Skill 和 WorkBuddy 的加工链路完全不用动。明天你想换一个更合适的大模型接口WorkBuddy 侧改一下配置就行仓颉.Skill 的规则模板照样复用。这就像搭积木边界清晰了每一块都能单独升级。2.2 为什么选 WorkBuddy而不是手动整理或纯脚本纯手动整理的问题不用多说量大之后根本不现实。纯脚本方案呢你要自己处理 API 鉴权、分页拉取、文本清洗、格式转换光是把飞书多维表格的数据结构摸清楚就可能耗掉一整天更别提后续要维护脚本的稳定性。WorkBuddy 在这里解决的是“胶水问题”它已经把任务编排、并发控制、错误重试这些通用逻辑做好了你只需要关注业务规则本身。另外一点是交互成本。脚本跑完给你一堆 JSON 文件你还得自己打开看WorkBuddy 可以把处理结果直接写回飞书机器人或者生成一份 Markdown 报告。它更像一个“能干活的下属”而不是一个“需要你翻译需求的编译器”。2.3 版本升级到 2.5 后真正的变化点在哪里先说结论2.5 版本最值得关注的是“批量任务”能力而不是某个单一功能点的增强。以前用 Skill 处理文档基本是开一个任务、等它跑完、再看结果2.5 引入了任务队列你可以一次性提交多个蒸馏任务它会按顺序执行单个任务失败不会影响后面任务的继续。对于飞书里动辄几十篇文档的批量整理场景这个能力直接决定了方案可不可用。第二个变化点是对“长上下文”的处理策略。飞书文档很容易写得又长又杂直接塞给大模型经常前面还记得、后面就忘了。2.5 里的分块策略更聪明它先做章节层级分析再按语义边界切分而不是机械地按字数切。处理出来的结果前后逻辑连贯性明显比老版本好。第三个变化是自定义指令的全局生效。你可以在 WorkBuddy 里预设几条通用规则比如“所有蒸馏结果统一使用中文小标题”“所有表格输出为 Markdown 格式”“禁止输出主观评价”这些规则会叠加到每一次 Skill 调用的底层 prompt 里。这个机制非常实用相当于你给 AI 定了几条“职场规矩”之后所有任务都自动遵守不用每次重复交代。2.4 必须先说清楚的边界只蒸馏你有权访问的内容我知道这个标题很容易让人兴奋但有一句话我必须放在前面整个蒸馏流程只能处理你账号权限范围内可见的内容。飞书的开放接口、机器人能力、文档导出功能都是围绕“授权”设计的你能够拿到的数据本身就是你有权访问的数据。不要试图用任何方式去获取别人私有文档、群聊私密信息也不要把它用在考勤打卡、刷数据这类灰色场景上一旦出问题责任完全是自己的。从合规角度讲更稳妥的做法是优先处理自己创建的文档、自己参与编辑的多维表格、自己所在团队明确授权可以导出的知识库。飞书后台的“权限管理”里可以看到每个文档的可见范围蒸馏之前先确认范围这是一个好习惯。做自动化不是做黑客把权限边界想清楚工具才能用得长久。3. 从零开始跑通“飞书内容蒸馏”的完整实操3.1 环境准备与安装Windows 和 Linux 都要注意什么WorkBuddy 目前的安装包区分 Windows 和 Linux 两个体系下载后解压即可运行依赖项很少。Windows 上安装没什么特别要说的双击启动、跟着初始化向导走就行。Linux 下如果跑在服务器或者 Ubuntu 桌面上需要注意给启动脚本加执行权限同时在系统里装好 Python 3.10 以上版本因为仓颉.Skill 2.5 的底层文档清洗逻辑依赖于几个 Python 库。有一个和安装相关的常见问题我提前说一下WorkBuddy 默认会把模型缓存和中间产物放在系统盘的用户目录下跑批处理任务时会高速增长。如果你和我一样系统盘紧张可以在配置文件的路径设置里把 work_dir 改成 D 盘或者独立数据盘改完重启一次生效。这个操作非常值得做我第一周跑蒸馏任务就吃了这个亏C 盘直接红了改完路径后才安下心来。3.2 接入飞书应用创建、API 凭据与机器人配置接入飞书的第一步是去飞书开放平台创建一个“企业自建应用”。创建时注意记录 App ID 和 App Secret这两个就是后续所有接口的身份证。创建完成后进入“权限管理”页面按需开通你实际会用到的权限读取文档内容、读写多维表格记录、发送机器人消息这三个是核心其他权限能不开就不开权限越小越安全。然后是机器人能力在“应用能力”里启用机器人拿到机器人本身的 webhook 地址。这个 webhook 会让你在群里发消息变成一件极其简单的事只要往这个地址 POST 一段 JSON 就能把处理结果推送到群里。在 WorkBuddy 的配置界面里有一个“外部服务”区把 App ID、App Secret、机器人 webhook 填进去保存后它会自动帮你换取 tenant access token后续调用飞书 API 的时候不需要自己手动管理 token 续期。这一步省了很多事我最初是打算写脚本自己处理 token 的后来发现 WorkBuddy 已经内置了接入成本比预想低不少。3.3 首次蒸馏实操以一篇飞书文档为例跑通的第一步建议找一篇结构比较完整的飞书文档练手不要一上来就玩多维表格。先把文档从飞书导出为 Markdown 或纯文本存到 WorkBuddy 指定的输入目录里。然后在仓颉.Skill 2.5 的配置文件中为这次任务指定一个输出模板比如output_template: title: ## 知识卡片{doc_title} summary: ### 核心摘要\n{summary} key_points: ### 关键要点\n{key_points} tables: ### 结构化表格\n{tables} action_items: ### 后续动作\n{action_items}这个模板的作用是告诉 Skill 最终产出的知识卡片长什么样。接下来在 WorkBuddy 的任务区新建一个“蒸馏任务”选择仓颉.Skill 2.5指定输入文件和输出目录点击运行。任务执行时日志区会显示每一步的处理状态读取文档、章节识别、分块、信息抽取、结果渲染。第一次跑完打开输出目录看结果。如果发现存在“核心摘要太泛”“关键要点漏掉了具体数字”这类问题不要急着改模板先检查原文的标题层级是否清晰。仓颉.Skill 的章节识别非常依赖 Markdown 标题如果原始导出的文档没有标题层级它会按段落硬拆效果自然差一截。所以实操里我习惯先在原文里把标题层级理顺再交给 Skill 蒸馏效果能提升一大截。3.4 批量场景多维表格内容整理与机器人回传飞书多维表格是一个数据密集型场景手动整理很容易出错。批量蒸馏的基本思路是通过飞书 API 把多维表格的记录拉下来以 JSON 或 CSV 形式存到本地然后用仓颉.Skill 做一个“逐行清洗”的任务。清洗规则因人而异我这里给一个最常用的组合去除空记录、统一日期格式、把长文本字段按规则缩写、对数字字段做合理性校验。跑完一批之后把清洗结果转换成一张干净的 Markdown 表格再由机器人推回飞书群。机器人回传这个环节非常提气。你可以在 WorkBuddy 里创建一个“发布任务”把蒸馏后的文件内容读取出来组装成飞书机器人可以识别的消息体POST 到 webhook。飞书机器人支持发送文本、富文本、图片和表格卡片实测下来把 Markdown 表格转成飞书消息卡片是最直观的展示方式群里的同事一眼就能看到整理后的结果不用再点附件、下载文件。4. 常见问题与排查技巧实录4.1 高频问题速查表这里整理了我实际使用中遇到率最高的几个问题以及对应的排查方向。注意同一个问题的表象可能相同但根因千差万别排查时按下表的顺序逐项确认。问题现象可能原因解决思路飞书文档拉不下来API 权限未开通或 token 过期检查“权限管理”里是否包含对应文档读取权限重新获取 token提示没有 CLI 权限当前账号未开通飞书 CLI 相关能力优先走开放 API 和机器人通道不依赖 CLI 工具长文档处理到一半截断单次处理内容超过模型上下文启用 Skill 的分块策略按章节逐段蒸馏最后合并表格输出后列错位原表格结构复杂或存在合并单元格改用多维表格 API 返回结构化 JSON不依赖 OCR 或图转表机器人消息发送失败群未添加机器人或 webhook 地址填错确认机器人已添加进目标群webhook 不带额外字符Skill 规则不生效自定义指令权重低于默认指令检查规则优先级设置把自定义指令提到最高级别中间产物占用磁盘过大缓存目录在系统盘修改 work_dir 到其他盘符重启 WorkBuddy4.2 五个踩坑细节常规文档里不会写第一个坑是“一次喂太多”。刚开始用批量队列时我直接扔了五十篇文档进去结果跑到一半某个文档里有个特殊符号导致解析异常后面的任务全部卡住。2.5 版本虽然支持失败隔离但我的建议还是小批量试跑确认没问题后再放大到全量。稳妥比速度重要。第二个坑是“文件编码”。从飞书导出的内容如果是旧文档可能会出现 GBK 和 UTF-8 混用的情况。Windows 下尤其明显。处理方法很简单在预处理阶段统一转成 UTF-8我用 WorkBuddy 里的“编码自动识别”功能基本能覆盖绝大多数情况实在不行的就手动转换一次。第三个坑是 Skill 命名。仓颉.Skill 2.5 的规则匹配是支持按名称调用的但如果你的 Skill 名字里带了空格、特殊符号某些内部调用环节可能会出问题。我后来统一改成“拼音或英文连字符”命名例如cangjie-doc-v2.5再没出过匹配不上或者加载失败的问题。第四个坑是“多维表格里的公式字段”。飞书多维表格的公式字段在 API 返回值里可能只是计算结果也可能是空值取决于字段配置。所以清洗时不要假设公式列一定有值要有兜底逻辑。我一般会在 Skill 规则里加一条“公式字段为空时输出‘待计算’标记”而不是直接丢弃。第五个坑是“机器人消息长度限制”。飞书机器人对单条消息的文本长度有限制如果你把整篇蒸馏结果一股脑塞进一条消息发送会失败。正确做法是把长内容拆成多条或者只发送摘要链接完整内容存本地。这个和写文章做分栏是同一个道理信息要分层递送。4.3 自定义指令的几种推荐写法WorkBuddy 里有一个让我觉得特别值钱的机制自定义指令的全局生效。你可以给 AI 定几条规则之后所有任务都会自动遵守。这里分享几个我实测有效的写法格式上注意每条指令要足够具体不要写“你要负责一点”这种模糊话。第一类是格式钳制型所有蒸馏输出统一使用 Markdown 格式 表格必须保留表头 小标题层级从 ## 开始禁止使用 # 一级标题。第二类是内容范围型只输出原文中有依据的信息 禁止添加主观评价 涉及数字时保留原始单位和精度 如果原文信息不足输出“原文未提及”不要自行脑补。第三类是处理策略型先读完整篇文档再开始结构化 对超过 3000 字的文档按章节分块处理 每个章节的蒸馏结果保留原文的章节编号。这些规则叠加以后蒸馏出的内容质量会稳定很多。我甚至会把一些行业特定术语写进全局指令里比如“渠道成本统一缩写为 CAC”“用户获取统一缩写为 UA”AI 在蒸馏时就自动做了术语归一化后续做检索和聚合的时候省了非常多力气。5. 再往前一步蒸馏后的内容怎么反哺工作流5.1 从“蒸馏”到“知识库”中间还差一个组织动作蒸馏完成只是第一步蒸馏出来的知识卡片如果不做组织散落在一堆 Markdown 文件里检索效率依然很低。我常用的方法是用“MOC内容地图”索引每蒸馏完一个主题就生成一张总览索引文件里面按主题列明每张知识卡片的路径和一句话摘要。这样当你需要找“某个方案的背景数据”时不用打开所有卡片先看索引定位到对应卡片再打开详情。更进一步的做法是把蒸馏后的卡片接入支持 RAG 的应用里做语义检索。WorkBuddy 蒸馏输出的 Markdown 文件结构干净、主题单一非常适合作切片后灌入知识库。我实际测下来蒸馏后的卡片检索命中率远高于直接把原始飞书文档切片的效果因为“噪声被去掉了”。5.2 做一个半自动化的“飞书内容订阅器”有了前面的基础就可以再往前走半步让系统每隔一段时间自动去飞书拉取新增内容、执行蒸馏、更新索引。WorkBuddy 支持定时触发器你可以配置一个每天凌晨执行的策略调用飞书 API 增量拉取指定文件夹下新增文档交给仓颉.Skill 2.5 蒸馏结果追加进本地知识库最后给飞书群推一条当日新增摘要。这里提醒一点自动化跑顺手之后很容易有一种“内容已经在整理了”的错觉。实际上蒸馏只是帮你把信息压缩了真正的“知识”还得靠人去判断和连接。我会把自动化定位成“替我完成重复的体力活”而不是“替我做决策”。每天花十分钟浏览蒸馏日报比每天花两小时整理原始文档轻松太多了而且这个时间投入是可持续的。我个人在实际操作中的体会是不要一上来就追求“全自动、全量、全覆盖”。先把一条线跑通比如先只蒸馏一个文件夹、一类文档跑顺了再扩到第二个场景。我见过太多人第一天就搭了一整套复杂工作流结果第二周就因为维护成本放弃了。从一篇文档开始到批量整理再到定时自动化每一步都能稳稳接住的时候这套方案才真正属于你。最后再分享一个小技巧蒸馏不是一次性的。你隔一段时间再回看之前产出的知识卡片会发现当初觉得重要的内容现在已经不关键了用仓颉.Skill 2.5 重新蒸馏一遍旧卡片能得到一版更符合当下视角的摘要。这个“反复蒸馏”的动作才是内容管理工作流里最值钱的环节。
飞书内容蒸馏实战：WorkBuddy+仓颉.Skill 2.5打造AI知识库
把飞书里的文档、多维表格、会议纪要沉淀成自己的知识库我以前靠的是最笨的办法手动复制、粘贴、排版十几篇文档整理下来一下午就没了。后来我把 WorkBuddy 和仓颉.Skill 2.5 组合起来做“内容蒸馏”流程变成了这样飞书侧负责同步导出仓颉.Skill 负责清洗结构化WorkBuddy 负责调度和归档整套链路不花一分钱订阅费。这套玩法适合所有在飞书里积压了大量内容、又想让这些内容变成 AI 可检索资产的人不管你是做知识管理的运营还是每天被各类周报、文档、表格淹没的职场人都值得花一个下午把链路跑通。1. 这套组合到底是干什么的从“复制粘贴”到“内容蒸馏”1.1 WorkBuddy 到底是什么它和普通客户端有什么区别WorkBuddy 在我理解里更像一个本地化的 AI 任务工作台。它不是一个聊天框那么简单而是把“模型调用、文档处理、外部工具接入、定时任务”都收拢到一个界面里让你可以用一套规则去驱动 AI 干活。市面上同类工具很多偏代码生成比如 CodeBuddy 那类更贴合 IDE 场景但 WorkBuddy 的重心明显在“任务流”上从本地文件夹读取文档、按 Skill 规则加工、再把结果写回指定位置整个过程是流水线式的。很多人第一次打开 WorkBuddy 会有点懵因为它的界面不像聊天软件那样只有一个输入框而是分为任务区、文件区、Skill 区、日志区。这个设计其实是对的因为你要处理的不是一句话而是一批文件、一批任务。我自己用下来的感觉是把它当成“能跑批处理的 AI 助手”而不是“聊天机器人”思路一下子就顺了。1.2 仓颉.Skill 2.5 在中间扮演了什么角色Skill 这个词现在很火你可以把它理解成“给 AI 预装的一套行为模板”。仓颉.Skill 就是一套专门针对文档处理场景开发的技能包它把常见的文档操作拆成了很多细粒度能力长文分块、标题层级识别、关键信息抽取、表格结构还原、Markdown 转写、摘要生成等等。2.5 这个版本我重点体验下来主要是三类改进第一是长文档分段时不再轻易“断句”能跨段落保留上下文第二是对飞书导出的复杂表格识别更准了不会出现列错位第三是支持批量任务队列可以一次丢进去几十篇文档排队处理。如果把 WorkBuddy 比作厨房那仓颉.Skill 2.5 就是一套预制好的菜谱。它告诉你每一道菜先放什么、后放什么、火候怎么控制你不用每次从零开始指挥 AI。1.3 “蒸馏飞书”的本质是知识蒸馏思维“蒸馏”这个词来自 AI 领域的知识蒸馏用一个大的、复杂的模型教师模型去指导一个小的、精简的模型学生模型把核心能力提炼出来。放到飞书场景里所谓的“蒸馏”不是把文档复制一遍而是把原始内容里的有效信息提取出来、去噪、结构化最终产出一份比原文更精炼、更容易被检索和复用的知识资产。这一点很重要很多人误以为“蒸馏飞书”就是把飞书整个搬下来那是迁移不是蒸馏。真正的蒸馏结果是一篇 50 页的飞书文档最后变成一张 500 字的知识卡片、一张准确的参数表、一份可执行的清单。信息密度提升了查找成本下降了这才是蒸馏的意义。2. 为什么这套搭配能成立方案选型与核心设计2.1 飞书、WorkBuddy、仓颉.Skill 三者的分工边界任何自动化方案最怕的就是一个工具既要管采集、又要管加工、还要管存储最后什么都做不好。这套方案把分工拆得很干净飞书是数据源负责提供原始内容和开放接口WorkBuddy 是执行器负责调度模型、读写文件、调用外部服务仓颉.Skill 2.5 是加工规则负责定义“原文进来之后变成什么样子”。这个分工带来的直接好处是可替换性。今天你飞书里的内容想换成本地 Markdown 文件夹或者换成其他协作平台的导出文件你只需要换数据源Skill 和 WorkBuddy 的加工链路完全不用动。明天你想换一个更合适的大模型接口WorkBuddy 侧改一下配置就行仓颉.Skill 的规则模板照样复用。这就像搭积木边界清晰了每一块都能单独升级。2.2 为什么选 WorkBuddy而不是手动整理或纯脚本纯手动整理的问题不用多说量大之后根本不现实。纯脚本方案呢你要自己处理 API 鉴权、分页拉取、文本清洗、格式转换光是把飞书多维表格的数据结构摸清楚就可能耗掉一整天更别提后续要维护脚本的稳定性。WorkBuddy 在这里解决的是“胶水问题”它已经把任务编排、并发控制、错误重试这些通用逻辑做好了你只需要关注业务规则本身。另外一点是交互成本。脚本跑完给你一堆 JSON 文件你还得自己打开看WorkBuddy 可以把处理结果直接写回飞书机器人或者生成一份 Markdown 报告。它更像一个“能干活的下属”而不是一个“需要你翻译需求的编译器”。2.3 版本升级到 2.5 后真正的变化点在哪里先说结论2.5 版本最值得关注的是“批量任务”能力而不是某个单一功能点的增强。以前用 Skill 处理文档基本是开一个任务、等它跑完、再看结果2.5 引入了任务队列你可以一次性提交多个蒸馏任务它会按顺序执行单个任务失败不会影响后面任务的继续。对于飞书里动辄几十篇文档的批量整理场景这个能力直接决定了方案可不可用。第二个变化点是对“长上下文”的处理策略。飞书文档很容易写得又长又杂直接塞给大模型经常前面还记得、后面就忘了。2.5 里的分块策略更聪明它先做章节层级分析再按语义边界切分而不是机械地按字数切。处理出来的结果前后逻辑连贯性明显比老版本好。第三个变化是自定义指令的全局生效。你可以在 WorkBuddy 里预设几条通用规则比如“所有蒸馏结果统一使用中文小标题”“所有表格输出为 Markdown 格式”“禁止输出主观评价”这些规则会叠加到每一次 Skill 调用的底层 prompt 里。这个机制非常实用相当于你给 AI 定了几条“职场规矩”之后所有任务都自动遵守不用每次重复交代。2.4 必须先说清楚的边界只蒸馏你有权访问的内容我知道这个标题很容易让人兴奋但有一句话我必须放在前面整个蒸馏流程只能处理你账号权限范围内可见的内容。飞书的开放接口、机器人能力、文档导出功能都是围绕“授权”设计的你能够拿到的数据本身就是你有权访问的数据。不要试图用任何方式去获取别人私有文档、群聊私密信息也不要把它用在考勤打卡、刷数据这类灰色场景上一旦出问题责任完全是自己的。从合规角度讲更稳妥的做法是优先处理自己创建的文档、自己参与编辑的多维表格、自己所在团队明确授权可以导出的知识库。飞书后台的“权限管理”里可以看到每个文档的可见范围蒸馏之前先确认范围这是一个好习惯。做自动化不是做黑客把权限边界想清楚工具才能用得长久。3. 从零开始跑通“飞书内容蒸馏”的完整实操3.1 环境准备与安装Windows 和 Linux 都要注意什么WorkBuddy 目前的安装包区分 Windows 和 Linux 两个体系下载后解压即可运行依赖项很少。Windows 上安装没什么特别要说的双击启动、跟着初始化向导走就行。Linux 下如果跑在服务器或者 Ubuntu 桌面上需要注意给启动脚本加执行权限同时在系统里装好 Python 3.10 以上版本因为仓颉.Skill 2.5 的底层文档清洗逻辑依赖于几个 Python 库。有一个和安装相关的常见问题我提前说一下WorkBuddy 默认会把模型缓存和中间产物放在系统盘的用户目录下跑批处理任务时会高速增长。如果你和我一样系统盘紧张可以在配置文件的路径设置里把 work_dir 改成 D 盘或者独立数据盘改完重启一次生效。这个操作非常值得做我第一周跑蒸馏任务就吃了这个亏C 盘直接红了改完路径后才安下心来。3.2 接入飞书应用创建、API 凭据与机器人配置接入飞书的第一步是去飞书开放平台创建一个“企业自建应用”。创建时注意记录 App ID 和 App Secret这两个就是后续所有接口的身份证。创建完成后进入“权限管理”页面按需开通你实际会用到的权限读取文档内容、读写多维表格记录、发送机器人消息这三个是核心其他权限能不开就不开权限越小越安全。然后是机器人能力在“应用能力”里启用机器人拿到机器人本身的 webhook 地址。这个 webhook 会让你在群里发消息变成一件极其简单的事只要往这个地址 POST 一段 JSON 就能把处理结果推送到群里。在 WorkBuddy 的配置界面里有一个“外部服务”区把 App ID、App Secret、机器人 webhook 填进去保存后它会自动帮你换取 tenant access token后续调用飞书 API 的时候不需要自己手动管理 token 续期。这一步省了很多事我最初是打算写脚本自己处理 token 的后来发现 WorkBuddy 已经内置了接入成本比预想低不少。3.3 首次蒸馏实操以一篇飞书文档为例跑通的第一步建议找一篇结构比较完整的飞书文档练手不要一上来就玩多维表格。先把文档从飞书导出为 Markdown 或纯文本存到 WorkBuddy 指定的输入目录里。然后在仓颉.Skill 2.5 的配置文件中为这次任务指定一个输出模板比如output_template: title: ## 知识卡片{doc_title} summary: ### 核心摘要\n{summary} key_points: ### 关键要点\n{key_points} tables: ### 结构化表格\n{tables} action_items: ### 后续动作\n{action_items}这个模板的作用是告诉 Skill 最终产出的知识卡片长什么样。接下来在 WorkBuddy 的任务区新建一个“蒸馏任务”选择仓颉.Skill 2.5指定输入文件和输出目录点击运行。任务执行时日志区会显示每一步的处理状态读取文档、章节识别、分块、信息抽取、结果渲染。第一次跑完打开输出目录看结果。如果发现存在“核心摘要太泛”“关键要点漏掉了具体数字”这类问题不要急着改模板先检查原文的标题层级是否清晰。仓颉.Skill 的章节识别非常依赖 Markdown 标题如果原始导出的文档没有标题层级它会按段落硬拆效果自然差一截。所以实操里我习惯先在原文里把标题层级理顺再交给 Skill 蒸馏效果能提升一大截。3.4 批量场景多维表格内容整理与机器人回传飞书多维表格是一个数据密集型场景手动整理很容易出错。批量蒸馏的基本思路是通过飞书 API 把多维表格的记录拉下来以 JSON 或 CSV 形式存到本地然后用仓颉.Skill 做一个“逐行清洗”的任务。清洗规则因人而异我这里给一个最常用的组合去除空记录、统一日期格式、把长文本字段按规则缩写、对数字字段做合理性校验。跑完一批之后把清洗结果转换成一张干净的 Markdown 表格再由机器人推回飞书群。机器人回传这个环节非常提气。你可以在 WorkBuddy 里创建一个“发布任务”把蒸馏后的文件内容读取出来组装成飞书机器人可以识别的消息体POST 到 webhook。飞书机器人支持发送文本、富文本、图片和表格卡片实测下来把 Markdown 表格转成飞书消息卡片是最直观的展示方式群里的同事一眼就能看到整理后的结果不用再点附件、下载文件。4. 常见问题与排查技巧实录4.1 高频问题速查表这里整理了我实际使用中遇到率最高的几个问题以及对应的排查方向。注意同一个问题的表象可能相同但根因千差万别排查时按下表的顺序逐项确认。问题现象可能原因解决思路飞书文档拉不下来API 权限未开通或 token 过期检查“权限管理”里是否包含对应文档读取权限重新获取 token提示没有 CLI 权限当前账号未开通飞书 CLI 相关能力优先走开放 API 和机器人通道不依赖 CLI 工具长文档处理到一半截断单次处理内容超过模型上下文启用 Skill 的分块策略按章节逐段蒸馏最后合并表格输出后列错位原表格结构复杂或存在合并单元格改用多维表格 API 返回结构化 JSON不依赖 OCR 或图转表机器人消息发送失败群未添加机器人或 webhook 地址填错确认机器人已添加进目标群webhook 不带额外字符Skill 规则不生效自定义指令权重低于默认指令检查规则优先级设置把自定义指令提到最高级别中间产物占用磁盘过大缓存目录在系统盘修改 work_dir 到其他盘符重启 WorkBuddy4.2 五个踩坑细节常规文档里不会写第一个坑是“一次喂太多”。刚开始用批量队列时我直接扔了五十篇文档进去结果跑到一半某个文档里有个特殊符号导致解析异常后面的任务全部卡住。2.5 版本虽然支持失败隔离但我的建议还是小批量试跑确认没问题后再放大到全量。稳妥比速度重要。第二个坑是“文件编码”。从飞书导出的内容如果是旧文档可能会出现 GBK 和 UTF-8 混用的情况。Windows 下尤其明显。处理方法很简单在预处理阶段统一转成 UTF-8我用 WorkBuddy 里的“编码自动识别”功能基本能覆盖绝大多数情况实在不行的就手动转换一次。第三个坑是 Skill 命名。仓颉.Skill 2.5 的规则匹配是支持按名称调用的但如果你的 Skill 名字里带了空格、特殊符号某些内部调用环节可能会出问题。我后来统一改成“拼音或英文连字符”命名例如cangjie-doc-v2.5再没出过匹配不上或者加载失败的问题。第四个坑是“多维表格里的公式字段”。飞书多维表格的公式字段在 API 返回值里可能只是计算结果也可能是空值取决于字段配置。所以清洗时不要假设公式列一定有值要有兜底逻辑。我一般会在 Skill 规则里加一条“公式字段为空时输出‘待计算’标记”而不是直接丢弃。第五个坑是“机器人消息长度限制”。飞书机器人对单条消息的文本长度有限制如果你把整篇蒸馏结果一股脑塞进一条消息发送会失败。正确做法是把长内容拆成多条或者只发送摘要链接完整内容存本地。这个和写文章做分栏是同一个道理信息要分层递送。4.3 自定义指令的几种推荐写法WorkBuddy 里有一个让我觉得特别值钱的机制自定义指令的全局生效。你可以给 AI 定几条规则之后所有任务都会自动遵守。这里分享几个我实测有效的写法格式上注意每条指令要足够具体不要写“你要负责一点”这种模糊话。第一类是格式钳制型所有蒸馏输出统一使用 Markdown 格式 表格必须保留表头 小标题层级从 ## 开始禁止使用 # 一级标题。第二类是内容范围型只输出原文中有依据的信息 禁止添加主观评价 涉及数字时保留原始单位和精度 如果原文信息不足输出“原文未提及”不要自行脑补。第三类是处理策略型先读完整篇文档再开始结构化 对超过 3000 字的文档按章节分块处理 每个章节的蒸馏结果保留原文的章节编号。这些规则叠加以后蒸馏出的内容质量会稳定很多。我甚至会把一些行业特定术语写进全局指令里比如“渠道成本统一缩写为 CAC”“用户获取统一缩写为 UA”AI 在蒸馏时就自动做了术语归一化后续做检索和聚合的时候省了非常多力气。5. 再往前一步蒸馏后的内容怎么反哺工作流5.1 从“蒸馏”到“知识库”中间还差一个组织动作蒸馏完成只是第一步蒸馏出来的知识卡片如果不做组织散落在一堆 Markdown 文件里检索效率依然很低。我常用的方法是用“MOC内容地图”索引每蒸馏完一个主题就生成一张总览索引文件里面按主题列明每张知识卡片的路径和一句话摘要。这样当你需要找“某个方案的背景数据”时不用打开所有卡片先看索引定位到对应卡片再打开详情。更进一步的做法是把蒸馏后的卡片接入支持 RAG 的应用里做语义检索。WorkBuddy 蒸馏输出的 Markdown 文件结构干净、主题单一非常适合作切片后灌入知识库。我实际测下来蒸馏后的卡片检索命中率远高于直接把原始飞书文档切片的效果因为“噪声被去掉了”。5.2 做一个半自动化的“飞书内容订阅器”有了前面的基础就可以再往前走半步让系统每隔一段时间自动去飞书拉取新增内容、执行蒸馏、更新索引。WorkBuddy 支持定时触发器你可以配置一个每天凌晨执行的策略调用飞书 API 增量拉取指定文件夹下新增文档交给仓颉.Skill 2.5 蒸馏结果追加进本地知识库最后给飞书群推一条当日新增摘要。这里提醒一点自动化跑顺手之后很容易有一种“内容已经在整理了”的错觉。实际上蒸馏只是帮你把信息压缩了真正的“知识”还得靠人去判断和连接。我会把自动化定位成“替我完成重复的体力活”而不是“替我做决策”。每天花十分钟浏览蒸馏日报比每天花两小时整理原始文档轻松太多了而且这个时间投入是可持续的。我个人在实际操作中的体会是不要一上来就追求“全自动、全量、全覆盖”。先把一条线跑通比如先只蒸馏一个文件夹、一类文档跑顺了再扩到第二个场景。我见过太多人第一天就搭了一整套复杂工作流结果第二周就因为维护成本放弃了。从一篇文档开始到批量整理再到定时自动化每一步都能稳稳接住的时候这套方案才真正属于你。最后再分享一个小技巧蒸馏不是一次性的。你隔一段时间再回看之前产出的知识卡片会发现当初觉得重要的内容现在已经不关键了用仓颉.Skill 2.5 重新蒸馏一遍旧卡片能得到一版更符合当下视角的摘要。这个“反复蒸馏”的动作才是内容管理工作流里最值钱的环节。
