飛書文件一鍵轉 Markdown 的開源擴充實測，能看見就能帶走

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

飛書（國際版叫 Lark）的雲端文件一直有個尷尬的問題：內容住在別人家，想搬走只能靠官方給的匯出格式。Cloud Document Converter 這個開源瀏覽器擴充給了另一條路，把飛書文件一鍵匯出成 Markdown。實測的結論先講：這是目前飛書生態裡唯一認真維護的開源 Markdown 匯出管道，轉換全程在頁面內完成、不經任何第三方伺服器，而且公開分享的文件連帳號都不用登入就能轉；代價是長文件要先捲動載入、圖片用複製模式轉出來連結會失效，以及一個還沒有人處理的資安邊界。

它解決的是「搬不走」這件事

飛書文件在官方流程裡的匯出選項以 Word、PDF 這類排版格式為主，對把筆記當資產的人不太友善。排版格式轉移的是「長相」，Markdown 轉移的是「結構」：標題階層、清單、表格、程式碼區塊都還是活的，丟進任何工具都能繼續編輯。把文件轉成 Markdown 等於把內容從飛書的排版體系裡解放出來，放進 他牌 Markdown 編輯器、通用文件轉換工具 或 把知識來源整批餵給 AI 的管線 都能直接接上。

這個擴充由中國前端工程師 Julian Lu 一人開發，2024 年 2 月開源，程式碼以 MIT 授權放在 GitHub（帳號 whale4113）。Chrome 線上應用程式商店顯示約 30,000 位使用者、42 則評分平均約 4.7 顆星；Firefox 附加元件商店有 196 位使用者、5 顆滿分但只有 2 則評分；Edge 商店也找得到同名上架。三個商店的最後更新日期都停在 2026 年 7 月 3 日，與程式碼最後一版發布同一天，供貨鏈是一致的。它只做一件事：在飛書或 Lark 的文件頁面上，把文件轉成 Markdown，讓你複製、預覽或整份下載。

Pin

轉換器就住在飛書的編輯器裡

理解這個工具的優缺點，關鍵在它的取資料方式。大多數「文件下載工具」會想辦法打雲端 API，那條路要申請應用、過管理員這一關、還要談權限範圍，個人帳號幾乎走不通。Cloud Document Converter 完全不走這條路：它把轉換腳本注入到飛書文件頁面本身，直接讀取網頁編輯器記憶體裡那份區塊樹（頁面物件上的 PageMain.blockManager.rootBlockModel），也就是你在畫面上看到的文件的本體，然後在頁面內把這棵樹逐塊組裝成 Markdown 文字。對使用者的意義很實際：能打開的文件就能轉，組織裡沒有任何關卡要過。

這個設計同時決定了它的乾淨與脆弱。乾淨的部分：文件內容不會送給任何第三方。整個原始碼掃過，對外請求只打飛書自家網域，唯一的外部連結是讓使用者反應問題用的 GitHub 網址；權限清單也只有右鍵選單、腳本注入、本機儲存三項，沒有讀取分頁、沒有攔截網路請求那類高敏感權限，想要自己驗證的人可以從原始碼一層層看。脆弱的部分：它的命運跟飛書網頁版綁在一起，飛書哪天改了內部結構，擴充就會失效。這也部分解釋了它 2026 年上半年連發七個版本的節奏，一部分是在追著飛書的改版跑。

觸發方式有三種：文件頁面右下角出現的浮動按鈕（複製、預覽、下載三顆）、滑鼠右鍵選單裡的三個對應項目，以及 1.11.0 版加入的批次下載介面。批次介面做成檔案總管式的樹狀清單，把陸續打開的文件收集進來、勾選後一次打包，還會自動跳過重複加入的文件，對整個知識庫搬家的人很實用。

圖片的處理分成兩條路，差別值得記住。複製模式只把圖片換成暫時的公開連結，官方文件明講這些連結兩小時後就無法存取；這些連結的產生方式本身就是寄生式設計的展示，擴充用專案裡預先編譯好的編碼演算法把圖片代號簽成臨時下載網址，再請飛書伺服器把這批網址設為有效。也就是說，複製出來的 Markdown 裡，圖片連結的壽命是飛書伺服器說了算，不是擴充能控制的。下載模式則會把圖片逐一抓成本地檔案，與 Markdown、附件一起打包存檔。要長期保存的內容，一律走下載模式。

實測：公開文件免登入，轉出內容與作者的測試期望逐字一致

開發者在專案裡留了一套自動化測試，測試目標是他自己開在飛書上的幾份公開文件，每份的期望輸出都寫在測試程式裡、公開可查，這給了外部驗證一個現成又公平的入口：期望值不是我自己說了算。我安裝官方針對 Chrome 釋出的 1.11.0，打開其中一份公開測試文件，全程沒有登入任何帳號。文件頁面在約 4 秒後完成初始化，頁面物件裡的區塊樹確實存在，接著透過擴充右鍵選單背後的同一條注入路徑觸發轉換，轉出的內容是「源內容」三個字，與開發者自己寫在測試程式裡的期望值一字不差。

Pin

這個結果確認了兩件事。其一，機制屬實：它真的在讀編輯器的記憶體區塊樹，不是某種繞路的爬取。其二，「能看見就能帶走」不只是形容：任何拿到公開分享連結的人，都可以把整份文件變成 Markdown 帶走，過程不需要飛書帳號，文件擁有者也收不到任何通知。

同一輪測試的第二份文件暴露了真實邊界。那份文件裡有表格與 LaTeX 公式，但轉出來的 Markdown 只有已經載入進記憶體的前幾個區塊：同步引用的底線文字（輸出成 <u> 標籤的原始 HTML）和一個空的公式區塊，表格不見了。原因很直觀：飛書的長文件是捲動到才載入後續內容的，編輯器記憶體裡沒有的東西，轉換器自然變不出來。實務對策是把文件捲到底再觸發，這也與官方提示「部分內容仍在載入中，暫時無法解析」互相印證。另外補一個測試環境的觀察：匿名狀態下文件頁面部分背景請求會被伺服器拒絕，浮動按鈕不一定每次都出現，右鍵選單是更穩的入口。

轉出品質與支援範圍

官方相容表列了二十多種區塊類型，能對應的比想像中齊：一到六級的標題、任務清單、表格、引用、程式碼區塊、圖片、數學公式都有對應的 Markdown 寫法；字體顏色與背景色會輸出成帶樣式的 HTML 標籤，下劃線樣式輸出成 <u> 標籤，這些是 Markdown 原生語言沒有的東西，只能靠 HTML 補。幾種特殊區塊則明確標了限制：高亮塊會降級成普通引用、流程圖與 UML 圖只在下載模式轉成圖片、電子表格與多維表格標註為待定、檔案附件同樣只有下載模式處理。舊版編輯器的 doc 格式整個不支援，遇到了會明確提示，不會安靜地轉出半套。

Pin

介面語言只有英文與簡體中文，沒有繁中，但整個介面就是三顆按鈕與一個設定頁，對文字的依賴很低。設定頁有幾個務實的選項值得看一眼：表格的轉法有三檔，從過濾後的純 Markdown 到整表保留 HTML；分欄版面的處理同樣有三種策略（攤平、轉表格、轉 HTML）；下載時可以啟用唯一檔名，批次轉同名的筆記時不會互相覆蓋。

沒有人處理的資安邊界

2026 年 9 月中，有人向專案提了一份寫得相當完整的資安報告（issue 編號 144），到 2026 年 10 月初仍然開著，沒有任何官方處理。問題出在內嵌網頁區塊：轉換器把文件裡儲存的網址，用字串直接拼接進 <iframe src="..."> 的 HTML 輸出，沒有跳脫處理、沒有限制可用的通訊協定。這代表任何有文件編輯權的協作者，可以在文件裡埋一個惡意網址，讓每個用擴充轉出這份文件的人，拿到一份夾帶任意 HTML 的 Markdown。提報人用實際程式碼驗證了攻擊可行，包括植入腳本標籤與 javascript: 協定網址兩種變體。我對照了目前版本的原始碼，這段拼接邏輯原樣存在，尚未修正。

風險要放對位置看。Markdown 本身是純文字，單純閱讀沒有事；危險出在下游，如果筆記軟體、部落格系統或知識庫會渲染 Markdown 裡的原始 HTML，轉出物就成了信任邊界的破口，別人文件裡的一個區塊，就變成你系統裡的一段可執行內容。自己寫的文件風險為零，但轉出「別人也能編輯的文件」時，餵給任何會執行 HTML 的系統之前，值得先打開原始檔看一眼。

同一個「能看見就能帶走」的特性，對文件擁有者是另一個需要知道的面向：在飛書裡開放檢視權，實際效果已經接近開放完整匯出。把公開分享連結當成「只能看不能存」的控管手段，在這類工具存在的前提下不再成立。這不是這個擴充獨有的問題，官方匯出、截圖、複製貼上都繞得過單純的檢視限制，但它把這條邊界畫得特別清楚：一份 Markdown，連圖片帶結構，一次帶走。

專案活性的現實

單人開發、開源、免費，這三個條件放在一起就要看維護節奏。專案體量不小：超過 1,200 顆星、180 多個 fork、近 350 次提交，還附了一套對著真實飛書頁面跑的自動化測試，這在同類小工具裡少見。好消息是 2026 年上半年相當勤奮，一月到七月發了七個版本，最後一版 1.11.0 在 2026 年 7 月 3 日與三家商店同步上架，批次下載功能就是這一版加入的。壞消息是那之後的三個月，程式碼沒有新提交，30 多個開啟中的議題大多是下載失敗、長文件轉不完整、影片素材抓不到這類使用問題，作者的處理節奏明顯跟不上，多篇只有使用者互相留言想辦法。

另一個小插曲是身分：專案最初的 GitHub 帳號是 lujunji4113，2024 年 10 月底之後改為 whale4113，舊網址會自動轉址到新位置，但用舊名搜尋會以為專案消失了。引用與取用時認準目前的名稱即可。

誰該現在用它，誰該先停一下

如果你的需求是把自己的飛書或 Lark 文件搬進 Markdown 生態，這是目前最乾淨的一條路：開源可審、零第三方上傳、免審核流程，Lark 國際版網域也在支援清單內，台灣用 Lark 的團隊同樣適用。用它做單向備份與搬遷完全成立，搭配 微信公眾號文章導出工具 或 第三方飛書文件搜尋引擎 這類周邊，可以把散落在各平台的中文知識來源收進自己的庫。

兩種情況要先停一下再決定。把轉出物餵給會渲染 HTML 的系統，而且來源文件還有其他協作者時，先面對上面的注入風險，至少看過原始檔再入庫。需要穩定自動化匯出的場景也要想清楚：單人專案加三個月的安靜期，不適合當唯一的依賴，重要文件轉完記得檢查圖片與表格是否完整，那份輸出才是你真正擁有的備份。