第一次看到“用 WorkBuddy 倉頡.Skill 2.5 免費(fèi)蒸餾飛書的任何內(nèi)容”這個玩法我第一反應(yīng)是標(biāo)題黨吧后來花了幾周時間把 WorkBuddy、倉頡.Skill 2.5 和飛書開放 API 串在一起真正跑通了文檔、多維表格、群消息三條蒸餾流水線才發(fā)現(xiàn)這條路不僅可行而且成本確實能被壓到零。所謂“蒸餾飛書”本質(zhì)上就是把飛書當(dāng)成知識原料庫用 AI 代理去讀、去清洗、去結(jié)構(gòu)化最后沉淀成一份 AI 能長期調(diào)用的技能包而不是簡單地把文檔下載到本地。這套玩法適合兩類人一類是天天泡在飛書里、文檔和表格多到翻不過來的團(tuán)隊成員想把這些存量知識變成 AI 的上下文另一類是搞自動化流程的開發(fā)者希望讓 AI 定時去飛書“收菜”自動整理周報、FAQ、SOP。只要你能拿到飛書開放平臺的應(yīng)用憑證整個過程不花一分錢。接下來我就把這套組合拳拆開從安裝到踩坑完整走一遍。1. 一套玩法拆解為什么是 WorkBuddy 倉頡.Skill 2.51.1 蒸餾這個詞用在飛書上到底是什么意思“蒸餾”原本是模型訓(xùn)練里的概念指的是把大模型教師網(wǎng)絡(luò)學(xué)到的知識遷移到小模型學(xué)生網(wǎng)絡(luò)里典型的有白盒蒸餾、黑盒蒸餾。但在飛書這個場景里我們借用了同一個字面意思把大量原始信息“收汁”留下精華。飛書里的原始內(nèi)容有一個共同問題——噪聲太多。文檔里有大量重復(fù)的目錄、過時的版本、口語化的碎碎念多維表格里字段類型五花八門人員、日期、附件摞在一起群消息更是碎片化重災(zāi)區(qū)。直接把這些東西丟給 AI上下文會被撐爆回答質(zhì)量也會被垃圾信息拖垮。所以要先做一個蒸餾動作抽取、清洗、結(jié)構(gòu)化、歸檔最后變成一份干凈的 Markdown 或 JSON再喂給 AI 使用。我個人的理解是模型蒸餾是把能力從一個模型搬到另一個模型而 skill 蒸餾是把散落在業(yè)務(wù)系統(tǒng)里的知識變成 AI 可復(fù)用的“技能包”。這也是為什么社區(qū)里會同時出現(xiàn)“知識蒸餾代碼”、“skill 蒸餾”這些搜索詞——大家都在探索同樣一件事只是叫法不同。1.2 為什么選 WorkBuddy 當(dāng)載體市面上的 AI 代理工具有不少Codex 有飛書插件Claude Code 也有人接 cc-connect 連飛書為什么我最終選了 WorkBuddy主要是三個原因。第一WorkBuddy 是本地優(yōu)先的代理工作臺核心功能個人使用免費(fèi)。這一點很重要因為蒸餾飛書是個反復(fù)試錯的過程API 調(diào)用次數(shù)不少如果用按量計費(fèi)的工具跑成本會失控。第二它有完善的 Skill 機(jī)制。Skill 不是簡單的一段提示詞而是“描述文件 腳本 資源文件”的組合可以封裝一個完整的自動化任務(wù)。倉頡.Skill 2.5 這種技能包放進(jìn)去就能用系統(tǒng)會自己讀取技能說明按步驟執(zhí)行。第三WorkBuddy 可以自定義全局指令。這意味著你可以定一套規(guī)則讓后續(xù)所有任務(wù)都生效不用每次重復(fù)交代。比如說“蒸餾結(jié)果必須輸出到指定目錄”“遇到飛書 API 限頻就自動等待重試”這些規(guī)則寫到全局配置里整個工作流都會遵守。我把 WorkBuddy 和同類方案做了個對比方便你判斷方案Skill 機(jī)制免費(fèi)額度本地腳本支持飛書接入方式WorkBuddy完善支持技能包加載核心功能免費(fèi)強(qiáng)可直接跑 Python通過 MCP / HTTP APICodex 飛書插件依賴插件按量收費(fèi)為主一般插件自帶Claude Code cc-connect有但配置略重受賬號限制強(qiáng)通過 MCP Server當(dāng)然工具這東西沒有絕對的“最好”只有“最適合”。如果你已經(jīng)深度使用某個工具也不一定非要換但如果你想專門搞一條低成本的飛書蒸餾流水線WorkBuddy 這套組合確實順滑。1.3 倉頡.Skill 2.5 在里面扮演什么角色倉頡.Skill 從名字就能看出來它管的是“整理文字”這件事。2.5 版本的核心能力是讓 AI 自動處理本地文檔尤其是用來做知識結(jié)構(gòu)化的那套 Python 腳本。它在蒸餾流水線里承擔(dān)三個職責(zé)一是讀取原始內(nèi)容不管是本地 Markdown 還是飛書 API 返回的 JSON二是做清洗和分塊把長文本拆成適合送給大模型處理的片段同時去掉無效格式三是輸出結(jié)構(gòu)化結(jié)果通常是一份帶層級標(biāo)題的 Markdown或者一份字段規(guī)整的 JSON。我為什么要強(qiáng)調(diào) 2.5因為在實測中它對長文檔的分塊策略明顯更穩(wěn)。之前的版本容易出現(xiàn)標(biāo)題錯位、代碼塊丟失2.5 在分塊時會保留上下文關(guān)聯(lián)不再是一個無腦按字?jǐn)?shù)切片的工具。這直接影響蒸餾質(zhì)量——清洗環(huán)節(jié)做得不干凈后面喂給 AI 的知識就是一團(tuán)亂麻。2. 環(huán)境準(zhǔn)備先把三樣?xùn)|西湊齊2.1 WorkBuddy 安裝與目錄規(guī)劃WorkBuddy 的安裝不算難Windows、Linux、Ubuntu 都有對應(yīng)的安裝包熱詞里大量出現(xiàn)“WorkBuddy 安裝教程”“WorkBuddy Linux 安裝包”說明很多人在第一步就卡住了。其實核心就兩步下載正確版本的安裝包然后設(shè)置一個專門的工作目錄。有兩點體驗值得先說。第一很多人問“WorkBuddy 系統(tǒng)緩存目錄能不能改到 D 盤”——可以在配置里自定義緩存路徑就行尤其是你會用它跑大量蒸餾任務(wù)時默認(rèn)的 C 盤空間很容易被撐爆。第二網(wǎng)上流傳的“WorkBuddy 國際版”和本地版沒有本質(zhì)區(qū)別只是中文文檔完整度不同功能上不用太糾結(jié)。我建議目錄按這個結(jié)構(gòu)規(guī)劃后面跑蒸餾會很省心workbuddy/ skills/ # 技能包目錄 cangjie_2.5/ # 倉頡.Skill 2.5 knowledge_base/ # 蒸餾后的知識庫 feishu_docs/ feishu_tables/ feishu_messages/ exports/ # 臨時導(dǎo)出文件 logs/ # 流水線日志目錄規(guī)劃的核心目的是讓 AI 知道“什么東西放哪里”。否則蒸餾完了結(jié)果散落在各個臨時文件夾里AI 想用也用不上。2.2 倉頡.Skill 2.5 的接入方式把倉頡.Skill 2.5 放進(jìn) skills 目錄后還需要在 WorkBuddy 里確認(rèn)它被正確加載。一般可以在對話里直接問“當(dāng)前加載了哪些技能”或者輸入“列出技能”這樣的指令看系統(tǒng)能不能識別到“倉頡.Skill 2.5”這個名字。Skill 包的內(nèi)部結(jié)構(gòu)通常是這樣的cangjie_2.5/ SKILL.md # 技能描述文件AI 靠它理解技能用途 scripts/ cangjie_tool.py # Python 實現(xiàn)負(fù)責(zé)清洗和結(jié)構(gòu)化 data/ # 可選的參考數(shù)據(jù) requirements.txt # Python 依賴如果你的環(huán)境缺少依賴先裝一下 requirements.txt 里的庫。我在新環(huán)境里跑的時候踩過坑直接調(diào)用技能報了 ModuleNotFoundError其實就是少了一個 requests。裝完之后可以先用一個本地測試文檔跑一遍“整理文檔”的功能確認(rèn) Python 腳本能正常執(zhí)行再接飛書。還有一個小技巧如果你希望這套規(guī)則對所有任務(wù)都生效可以把它寫進(jìn) WorkBuddy 的全局指令比如“執(zhí)行前先檢查技能是否可用不可用則提示安裝”。這樣就不用每次手動指定了。2.3 飛書側(cè)的準(zhǔn)備機(jī)器人、應(yīng)用憑證與權(quán)限想訪問飛書內(nèi)容必須走飛書開放平臺的 API。你要做的第一件事是在飛書開放平臺創(chuàng)建一個企業(yè)自建應(yīng)用然后拿到兩個關(guān)鍵憑證App ID 和 App Secret。這兩個值放在配置里或環(huán)境變量里不要硬編碼在腳本里方便后續(xù)替換。接著是開通權(quán)限這是整個過程中最容易糊涂的一步。我整理了一份對照表以當(dāng)時實測可用的權(quán)限名為準(zhǔn)想蒸餾的內(nèi)容需要的權(quán)限飛書云文檔查看文檔內(nèi)容docx:document:readonly多維表格記錄查看多維表格數(shù)據(jù)bitable:app:readonly群消息記錄查看消息內(nèi)容im:message:readonly給群里發(fā)結(jié)果發(fā)送消息im:message:send權(quán)限開通后不是立刻生效的需要在應(yīng)用“版本管理與發(fā)布”里創(chuàng)建一個新版本并發(fā)布權(quán)限才會真正生效。很多人卡在“403 permission denied”這一步排查了半天才發(fā)現(xiàn)權(quán)限根本沒發(fā)布出去。如果準(zhǔn)備蒸餾群消息還需要把機(jī)器人拉進(jìn)對應(yīng)的群里不然機(jī)器人讀不到消息。文檔和表格則只要應(yīng)用有權(quán)限可以通過 URL 里的 token 直接訪問。另外提醒一下如果你是個人開發(fā)者在自己的測試群里玩盡量用測試企業(yè)的管理員賬號給自己開權(quán)限不要直接在生產(chǎn)團(tuán)隊里操作避免把線上數(shù)據(jù)搞亂。2.4 把訪問憑證理清避免第一步就 401飛書 API 的訪問憑證有兩種tenant_access_token 和 user_access_token。蒸餾常規(guī)內(nèi)容用 tenant_access_token 就行它是應(yīng)用身份憑證獲取方法是拿 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 一般有兩個小時的時效過期后要重新獲取。我習(xí)慣在腳本里封裝一個 refresh_token 的函數(shù)每次調(diào)用 API 前檢查一下有效期省得跑大批量任務(wù)時突然斷掉。網(wǎng)絡(luò)里很多“飛書沒有 CLI 權(quán)限”的搜索其實就源于這一步?jīng)]有理清——訪問飛書內(nèi)容是靠 HTTP API不是靠終端里敲命令。3. 蒸餾實操從飛書到 AI 技能包3.1 蒸餾文檔把飛書云文檔拉成本地 Markdown飛書文檔的 URL 一般長這樣https://xxx.feishu.cn/docx/Wdxxxxxx結(jié)尾這串字符就是 document_id接下來調(diào)用文檔接口把文檔的 block 全部拉出來。文檔內(nèi)容是分塊存儲的每個塊有自己的類型比如標(biāo)題、段落、列表、代碼塊需要遍歷并轉(zhuǎn)換。我封裝了一個簡版函數(shù)方便你直接改著用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 數(shù)據(jù)交給它做清洗它會根據(jù) block 的樣式字段去還原 Markdown 結(jié)構(gòu)。這一步特別關(guān)鍵因為直接拼接 block 的純文本內(nèi)容會把層級關(guān)系全部丟掉蒸餾出來的文檔連標(biāo)題層級都是亂的。我建議先小批量試一篇文章跑通后再放開到整個目錄。實測下來一篇 5000 字的飛書文檔從拉取到清洗成 Markdown幾秒就能搞定。真正耗時的是大批量文檔的網(wǎng)絡(luò)請求和 API 限頻。3.2 蒸餾多維表格讓記錄變成結(jié)構(gòu)化 JSON多維表格的蒸餾和文檔不一樣文檔是純文本結(jié)構(gòu)表格則強(qiáng)依賴字段類型。飛書多維表格的字段可能是文本、數(shù)字、單選、多選、日期、人員、附件、公式、關(guān)聯(lián)字段API 返回的 JSON 里人員是一個對象數(shù)組日期是一個時間戳附件是一個帶 URL 的數(shù)組。直接原樣保存會有問題。比如你蒸餾一份“客戶信息表”里面的“負(fù)責(zé)人”字段返回的是[{id: xxx, name: 張三}]這樣的結(jié)構(gòu)后面 AI 讀取時還得解析對象憑空增加出錯概率。所以我會在蒸餾時做一個字段歸一化文本字段直接取值人員字段只留 name日期字段轉(zhuǎn)成YYYY-MM-DD附件字段下載到本地并在 JSON 里保留相對路徑。多維表格記錄接口GET https://open.feishu.cn/open-apis/bitable/v1/apps/{app_token}/tables/{table_id}/records注意這個接口也是分頁的而且有 page_token 機(jī)制。我強(qiáng)烈建議先拉一條記錄打印出來看字段結(jié)構(gòu)再寫批量轉(zhuǎn)換邏輯千萬別憑感覺寫字段名映射。我在實際項目里遇到過公式字段返回結(jié)果和預(yù)期不一致的情況這種東西不能靠猜必須以實際返回值為準(zhǔn)。蒸餾完的多維表格數(shù)據(jù)可以輸出成 JSON也可以轉(zhuǎn)成 CSV。我一般兩者都保留JSON 喂給 AI 做分析CSV 用飛書機(jī)器人發(fā)送表格到群里方便不寫代碼的同事直接用。3.3 消息流與知識庫沉淀群消息的蒸餾比文檔和表格更“臟”因為消息天然是碎片化的可能還有大量表情、回復(fù)串、文件分享。我的做法是按話題聚合先把一段時間內(nèi)的消息拉下來按時間排序然后用倉頡腳本做輕度聚類把同一主題的討論歸到一起再提取“問題-結(jié)論-負(fù)責(zé)人”這樣的結(jié)構(gòu)。這種蒸餾結(jié)果特別適合做團(tuán)隊 FAQ 和新人手冊。你可以讓 AI 在一個“知識庫沉淀”任務(wù)里同時處理多個群的近期消息按周生成一份《群聊精華周報》。消息里的高頻問題能直接轉(zhuǎn)成 FAQ 條目負(fù)責(zé)人信息也能保留到字段里。這里要提醒一句消息內(nèi)容涉及團(tuán)隊隱私生產(chǎn)環(huán)境的群消息處理一定要先確認(rèn)合規(guī)最好只處理你明確有權(quán)限的數(shù)據(jù)。蒸餾工具本身是中性的用在哪里、怎么用邊界要清楚。我會在蒸餾消息時經(jīng)常用到的過濾規(guī)則寫在腳本里長度少于 20 字的消息直接跳過只保留信息量足夠的片段連續(xù)打招呼、表情類內(nèi)容忽略帶鏈接的消息單獨(dú)標(biāo)注“待人工確認(rèn)”。這樣能讓最終的產(chǎn)出干凈很多。3.4 用 Python 腳本和倉頡.Skill 把結(jié)果喂給 AI蒸餾的產(chǎn)物不是終點讓 AI 能隨時用起來才是終點。我的做法是把蒸餾結(jié)果放到一個固定目錄然后在 WorkBuddy 的全局指令里寫明所有任務(wù)開始前先檢查 ~/workbuddy/knowledge_base/index.md。 如果任務(wù)涉及飛書知識優(yōu)先從知識庫中查找已有蒸餾結(jié)果。index.md 是一個索引文件記錄了每個蒸餾產(chǎn)物是什么、來源是哪里、更新時間是什么。我有一段腳本自動更新這個索引每次蒸餾完就追加一行。這樣 AI 在開始任務(wù)時就知道“手上有什么料”而不是每次都要重新去飛書拉一遍。整套蒸餾流水線的偽代碼大致是1. 從飛書 API 拉取原始內(nèi)容 2. 調(diào)用倉頡.Skill 2.5 的清洗腳本輸出結(jié)構(gòu)化 Markdown / JSON 3. 將產(chǎn)物寫入 knowledge_base 對應(yīng)子目錄 4. 更新 index.md 索引 5. 按需用機(jī)器人消息 API 發(fā)送結(jié)果摘要到飛書群把這一步固化下來后我基本不用再手動操作。每天定時跑一次飛書里新增的文檔和表格就會被自動蒸餾進(jìn)知識庫。所謂“讓 AI 自動整理本地文檔”本質(zhì)上就是把這一條流水線跑順。4. 常見問題與排查技巧實錄4.1 飛書“沒有 CLI 權(quán)限”到底怎么破熱詞里頻繁出現(xiàn)“飛書沒有 CLI 權(quán)限”這個說法其實有點誤導(dǎo)。飛書開放平臺從來沒有提供過官方 CLI 工具你想在終端里直接敲命令操作飛書內(nèi)容本來就不存在這個通道。真正的問題不是“沒有權(quán)限”而是“不知道走 HTTP API”。解決思路有兩種。一種是在腳本里用 requests 直接調(diào)飛書 REST API這也是我前文采用的方式。另一種是把飛書 API 封裝成 MCP Server注冊到 WorkBuddy 里讓 AI 通過工具調(diào)用的方式直接讀飛書。后者更“AI 原生”但對調(diào)試能力要求更高適合熟悉 MCP 的人。如果你在調(diào)用時遇到權(quán)限報錯先用這個順序排查報錯原因處理方式401 invalid_tokentoken 過期或錯誤重新獲取 tenant_access_token403 permission denied權(quán)限未授權(quán)或未發(fā)布檢查應(yīng)用權(quán)限并發(fā)布新版本400 invalid_param參數(shù)格式不對對照 API 文檔檢查參數(shù)名和類型其中 403 最常見的坑就是權(quán)限發(fā)布了但應(yīng)用版本沒審核通過導(dǎo)致線上環(huán)境依然用舊權(quán)限。4.2 文檔越來越多蒸餾任務(wù)經(jīng)常中斷大批量蒸餾時最常見的現(xiàn)象是任務(wù)跑到一半就停了報超時或者限頻錯誤。這不是腳本邏輯的問題而是沒有考慮 API 的調(diào)用頻率限制和長任務(wù)的穩(wěn)定性。我的實戰(zhàn)經(jīng)驗是三個詞分批、斷點、重試。分批就是一次任務(wù)只處理一定數(shù)量的文檔比如 20 篇一批斷點是每處理完一篇就在本地記錄狀態(tài)下次從斷點繼續(xù)重試是遇到限頻錯誤時用指數(shù)退避等待后重試而不是直接失敗退出。日志這塊我也建議留一份格式雖然簡單但救過我好幾次doc_id: Wdxxxxxx | status: success | time: 2025-01-01 10:00:00 | output: faq_01.md有了日志任務(wù)中斷后能一眼看出哪些成功哪些失敗不用重新掃描全部數(shù)據(jù)。4.3 多維表格導(dǎo)出的字段對不上多維表格導(dǎo)出后字段值“變了樣”通常是字段類型映射的問題。比如日期字段在 API 里是毫秒時間戳你直接用str()轉(zhuǎn)字符串得到的就是一長串?dāng)?shù)字人員字段是一個對象數(shù)組直接拼進(jìn)文本里會變[object Object]附件字段返回的是下載鏈接根本不含文件內(nèi)容。我的統(tǒng)一做法是先解析字段元信息再寫一個類型處理函數(shù)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這種“字段解析器”寫一次就能復(fù)用到所有表格上。另外提醒一句導(dǎo)出時間字段要注意時區(qū)飛書存的是 UTC 時間戳你如果直接用本地時間格式輸出早晚會被早八點的記錄坑一次。4.4 蒸餾之后的 skill 怎么讓 AI 長期“記住”很多人蒸餾完就完了結(jié)果下次開新會話AI 又把飛書知識忘光了。原因是蒸餾產(chǎn)物只存在某個臨時目錄里AI 根本不知道它的存在自然沒法用。要讓 AI“長期記住”核心是把蒸餾產(chǎn)物變成可重復(fù)加載的資源。我在全局指令里給 WorkBuddy 定了幾條規(guī)則對所有任務(wù)都生效第一條任何涉及飛書的請求先查knowledge_base索引第二條索引里找不到的內(nèi)容才允許現(xiàn)場調(diào)用飛書 API第三條現(xiàn)場調(diào)用得到的原始內(nèi)容必須經(jīng)過倉頡.Skill 清洗后再進(jìn)上下文。這三條規(guī)則一加AI 的行為就穩(wěn)定很多。另外建議用版本目錄管理蒸餾產(chǎn)物比如faq_v20250101.md不要覆蓋舊文件。因為知識是不斷迭代的保留歷史快照能隨時回退也能讓 AI 比較不同時間點的差異。這里我沒有用復(fù)雜的工具就是一個帶日期的文件命名習(xí)慣效果卻出奇地好。5. 進(jìn)階玩法把蒸餾流水線固化下來跑通單次蒸餾之后我很推薦往前再走一步把整個流程做成一條定時流水線。你不需要手動去點擊每一次蒸餾而是讓 WorkBuddy 按計劃任務(wù)觸發(fā)自動完成“拉取 → 清洗 → 歸檔 → 通知”的閉環(huán)。具體做的時候我會把任務(wù)拆成兩個層級調(diào)度層和執(zhí)行層。調(diào)度層負(fù)責(zé)定時觸發(fā)比如每天凌晨兩點開始跑執(zhí)行層就是倉頡.Skill 2.5 封裝的 Python 腳本負(fù)責(zé)處理飛書 API 調(diào)用和文檔清洗。執(zhí)行完成后讓 WorkBuddy 調(diào)用飛書機(jī)器人接口把蒸餾摘要發(fā)送到指定的群里這樣團(tuán)隊早上打開飛書就能看到昨天新增了什么知識條目。還有一個可以擴(kuò)展的方向把蒸餾結(jié)果直接轉(zhuǎn)成可訓(xùn)練的數(shù)據(jù)集。如果你在做模型微調(diào)或者評估飛書里的真實文檔、表格和對話記錄經(jīng)過清洗后就是一批高質(zhì)量的業(yè)務(wù)語料。倉頡.Skill 2.5 輸出的 JSON 格式天然適合做微調(diào)樣本只要你做好脫敏和權(quán)限確認(rèn)這套流水線就能從“個人知識庫”升級成“團(tuán)隊模型原料車間”。我個人在實際操作中的體會是不要一開始就追求“任何內(nèi)容”和“全量自動化”。把范圍縮小到某個文件夾、某幾個群、某一張表先跑通再擴(kuò)量。蒸餾這件事最怕的就是貪多一次喂給 AI 太多臟數(shù)據(jù)最后模型記住了不該記住的噪聲反而比不蒸餾更糟。最后再分享一個小技巧我會給 WorkBuddy 定一條規(guī)則讓它每次執(zhí)行蒸餾任務(wù)前先列一個“待處理內(nèi)容清單”給我確認(rèn)。這樣它不會自作主張地把草稿文檔、臨時表格甚至群里的閑聊全部收進(jìn)知識庫。有了這道人工閘門整個蒸餾流程既省心又可控。