做 RAG 和 AI Agent 開發的朋友，應該都經歷過這種絕望：
業務單位丟過來一個壓縮檔，裡面 Word、PPT、Excel、PDF 什麼格式都有，你的任務是把它們全部轉成乾淨的 Markdown 餵給 LLM。用 LibreOffice 轉一份文件要等一秒多，Pandoc 雖然快一點，但只支援 5 種格式。最後你只能針對每種格式個別寫一套解析邏輯，維護成本高到讓人懷疑人生。
最近開源社群冒出來的這個專案，可能會徹底改變這件事。
一、它是什麼？
anydoc 是 Firecrawl 團隊開源的文件轉換函式庫，以純 Rust 實作，能把 14 種辦公文件格式轉成乾淨的 GitHub Flavored Markdown。
支援格式清單：
Word：.doc、.docx、.docm
PowerPoint：.ppt、.pps、.pot、.pptx、.pptm、.ppsx、.ppsm
Excel：.xls、.xlsx、.xlsm、.xlsb
OpenDocument：.odt、.ods、.odp
RTF、EPUB、CSV、PDF
背後是 Firecrawl——就是那家做網站轉 Markdown API 的公司。anydoc 已經在正式環境跑了很長一段時間，Firecrawl Parse 的文件解析底層就是它。
專案採用 MIT 授權條款，程式碼在 GitHub 上完全公開。
二、最核心的設計：一個模型，統一輸出
這是 anydoc 和所有競品最本質的差異。
大多數轉換工具的做法是「每種格式各自寫一個解析器直接輸出 Markdown」。docx 走一套邏輯，pptx 走另一套，rtf 又是另一套。輸出品質參差不齊，修好了一種格式的 bug，其他格式該有的問題依然存在。
anydoc 的做法完全不同：
每種格式的解析器先把文件解析成同一個中間表示，然後所有格式共用同一個 Markdown 序列化器。
架構示意：
檔案位元組
│
├─► 格式偵測（根據內容特徵，不靠副檔名）
│
├─► 格式解析器（doc/docx/ppt/pptx/xls/xlsx/odt/ods/odp/rtf/epub/csv）
│ │
│ └─► Document Model（統一的中間表示：區塊、行內元素、表格、腳註、資源）
│ │
│ └─► GFM 序列化器 → Markdown
│
└─► PDF → pdf-inspector → 直接轉 Markdown
這代表什麼？一個表格跳脫字元規則的修復，會同時修好 docx、rtf、odt 等所有格式的輸出。輸出的一致性有保障，維護成本也降到最低。
Document Model 裡保留的資訊相當完整：
帶錨點的標題層級
粗體、斜體、刪除線
行內程式碼和程式碼區塊
連結和內部交叉參照
保留原始編號的項目符號清單、編號清單、巢狀清單、待辦清單
含合併儲存格和表頭的表格
區塊引用、腳註、尾註
演講者備註
嵌入式資源的處理也很乾淨：圖片渲染成 Markdown 的 alt 文字，原始位元組保留在 Document Model 中，並附上 media type 標記，方便你後續自行處理。
三、格式偵測：不看副檔名，看內容
很多轉換工具靠檔案副檔名判斷格式。但實際情況是，副檔名經常被改錯——明明是 PDF 卻被人改成 .doc。
anydoc 的格式偵測直接從檔案內容讀取特徵：
PDF：讀取 PDF 檔頭
RTF：讀取 RTF 開頭標記
OLE 格式（.doc、.ppt、.xls）：讀取 OLE 串流名稱
ZIP 套件格式（.docx、.pptx、.xlsx）：讀取 ZIP 壓縮包的 mimetype 和 content types
像 CSV 這種沒有內嵌標記的格式，才需要明確指定副檔名或格式參數。
Rust、Node.js 和 Python 都提供了 format_from_bytes、format_from_extension、format_from_path 三個 API。
四、效能：不是空談，是輾壓
直接看數據。
anydoc 官方做了一組 benchmark，在 100 份真實文件上比較 6 個同類工具。評分由 Claude Sonnet 5 進行盲測，從完整性、結構保留、格式保真度、輸出整潔度四個維度打分，每組輸出會以交換順序的方式各評判兩次以消除位置偏差，總共 481 次評判。
綜合得分（0-100）：
工具｜支援格式｜中位數耗時｜綜合得分
anydoc｜14/14｜4.4 ms｜81
libreoffice｜12/14｜1129.5 ms｜39
unstructured｜8/14｜572.9 ms｜62
markitdown｜6/14｜134.8 ms｜64
pandoc｜5/14｜102.1 ms｜56
docling｜4/14｜513.6 ms｜57
mammoth｜1/14｜52.5 ms｜69
中位數耗時 4.4 毫秒，比第二快的 pandoc（102ms）快了一個數量級。以這個速度，500 個 DOCX 檔案大約 2.2 秒就能處理完畢。
依格式逐一比較（分數越高越好）：
格式｜anydoc｜libreoffice｜unstructured｜markitdown｜pandoc｜docling｜mammoth
doc｜87｜57｜67｜－｜－｜－｜－
docm｜85｜45｜－｜－｜－｜－｜－
docx｜86｜54｜53｜73｜67｜71｜69
epub｜77｜－｜72｜72｜52｜－｜－
odp｜86｜23｜－｜－｜－｜－｜－
ods｜82｜38｜－｜－｜－｜－｜－
odt｜80｜52｜68｜－｜60｜－｜－
ppt｜80｜26｜－｜－｜－｜－｜－
pptx｜75｜24｜－｜61｜－｜52｜－
rtf｜88｜54｜45｜－｜44｜－｜－
xls｜80｜38｜66｜62｜－｜－｜－
xlsm｜76｜32｜－｜－｜－｜－｜－
xlsx｜72｜30｜66｜55｜－｜47｜－
anydoc 是唯一涵蓋全部 14 種格式的工具，在每一個有比較的格式上都拿下最高分。
速度測試環境：Ryzen 9 9950X3D、Windows 11、64GB DDR5-6400。anydoc 和 Python 函式庫的計時排除了行程啟動開銷；CLI 工具則包含行程啟動，因為那才是實際的使用方式。
五、PDF 支援：不依賴 OCR 服務
anydoc 對文字型 PDF 透過內建的 pdf-inspector 直接轉換，不需要呼叫任何外部 OCR 服務。
市面上大約 54% 的 PDF 是純文字的，這部分可以直接在本機轉換，零網路延遲、零 API 費用。
至於掃描版 PDF 或圖片型 PDF（anydoc 會回傳 Unsupported 錯誤），有兩種選擇：
先用其他 OCR 工具處理，再把文字餵給 anydoc
使用 Firecrawl 的託管 API 版本，內建 OCR 模型
六、多語言綁定：Node.js、Python、瀏覽器、Rust
anydoc 不只是 Rust 函式庫，還提供了完整的跨語言支援。
CLI（一行指令搞定）：
npx @firecrawl/anydoc report.docx
npx @firecrawl/anydoc slides.pptx -o slides.md
npx @firecrawl/anydoc - --format csv < data.csv # 從 stdin 讀取
首次執行會自動下載預先編譯好的二進位檔，全域安裝請用 npm install -g @firecrawl/anydoc。
Node.js（轉換在執行緒池中執行，不會阻塞事件迴圈）：
import { toMarkdown } from '@firecrawl/anydoc';
const markdown = await toMarkdown('report.docx');
Python（轉換時釋放 GIL，其他執行緒可以繼續跑）：
import anydoc
markdown = anydoc.to_markdown("report.docx")
瀏覽器（WebAssembly）（檔案在本機轉換，不上傳到任何伺服器）：
import init, { toMarkdownBytes } from '@firecrawl/anydoc-wasm';
await init();
const markdown = toMarkdownBytes(bytes);
官方還有線上 Demo：，在瀏覽器裡直接跑 WASM，檔案不會離開你的電腦。
Rust（直接以 crate 整合）：
let markdown = anydoc::to_markdown("report.docx")?;
七、Agent Skill：AI 編程助手直接讀文件
anydoc 還內建了 Agent Skill 支援：
npx skills add firecrawl/anydoc
這條指令會讓 Claude Code、Codex、Cursor、OpenCode 等 AI 編程助手學會用 anydoc 讀取文件。你的 Agent 遇到 Word 或 PDF 檔案時，可以直接呼叫 anydoc 轉成 Markdown 再處理。
八、錯誤處理：精細化的失敗分類
anydoc 的轉換失敗分類得很細：
錯誤類型｜意義
Unsupported｜未知格式或無法轉換（如圖片型 PDF）
Malformed｜結構損壞，無法擷取有意義的內容
Encrypted｜已加密或受密碼保護
ResourceLimit｜超出安全限制（解壓縮、巢狀深度、節點數）
MissingPart｜缺少必要的組成部分
Io｜檔案讀取失敗
Node.js 和 WASM 透過 error.code 公開錯誤類型；Python 則拋出對應的 anydoc.ConvertError 子類別。
這種精細化的錯誤分類，在正式環境的 pipeline 裡非常實用——你可以針對不同錯誤做不同處理，例如把加密檔案另外記錄下來，而不是讓整個流程崩潰。
九、適用場景
anydoc 最適合的是需要批次處理混合格式文件的 pipeline：
RAG 系統的文件前處理
AI Agent 的檔案讀取能力
企業內部文件的索引建置
任何需要把辦公文件轉成 LLM 輸入的環節