你把一份 PDF 丟給 AI，它回你「這份文件沒有內容」。不是 AI 偷懶，是那份 PDF 根本沒有文字層。
一句話結論：pdf-inspector 是 Firecrawl 開源的 Rust 函式庫，用約 10–50 毫秒判斷一份 PDF 是文字版還是掃描版，讓你只把真正需要 OCR 的頁面送去付費辨識。Firecrawl 說這能省下約 54% 的 OCR 呼叫。
最後更新：2026 年 8 月 6 日。工具版本與數據以官方 GitHub 為準。
pdf-inspector 是什麼？一分鐘看懂
它是一個「PDF 體檢器」。你給它一份 PDF，它在幾十毫秒內告訴你四件事之一：這是文字版（TextBased）、掃描版（Scanned）、純圖片（ImageBased），還是兩者混合（Mixed）。順便附一個 0 到 1 的信心分數，以及一份「哪幾頁需要 OCR」的頁碼清單。
| 專案 | firecrawl/pdf-inspector |
| 語言 / 授權 | Rust／MIT（可商用） |
| 熱度 | 約 9,000–10,300 星，2026-08-03 首度登上 GitHub Trending 第 1 名 |
| 核心能力 | PDF 分類、位置感知文字抽取、轉乾淨 Markdown |
| 它不做的事 | 不做 OCR、不含 AI 模型、不呼叫外部服務 |
| 可以怎麼用 | Rust crate、Python、Node.js、瀏覽器 WebAssembly、命令列 |
注意最後兩行。它自己不會辨識任何一個字，它只負責判斷「這份要不要送去辨識」。這個定位是理解整個工具的關鍵。
為什麼「先檢查」這件小事值得一個專案？
因為業界的預設做法是「全部送 OCR」。
你做一個文件問答系統，使用者上傳的東西什麼都有：合約、財報、掃描的收據、政府表格。你分不出哪些有文字層，最省事的寫法就是統統丟去 OCR 服務。一次 2 到 10 秒，一頁一頁計費。
問題是，多數 PDF 本來就是電腦生成的，文字好端端躺在檔案裡。Firecrawl 給的數字是約 54% 的 PDF 完全不需要 OCR。這些檔案送進辨識流程，你付的是「把已經存在的文字重新猜一次」的錢，而且猜得可能比原本還差。
先花 20 毫秒問一句「這份需要嗎」，比直接花 5 秒去辨識划算太多。這就是整個工具的全部主張。
它怎麼在幾十毫秒內分辨掃描版和文字版？
靠讀檔案結構，不靠算圖。流程是這樣：
- 解析 PDF 的 xref 表和頁面樹，不載入完整物件
- 依掃描策略挑要看的頁
- 在內容流裡找文字運算子（
Tj／TJ）和圖片運算子（Do） - 看抽樣頁面有沒有文字運算子，據此分類
沒有渲染、沒有模型推論，所以連 300 頁以上的文件也是毫秒級。
掃描策略有四種，這是實務上最該調的參數：EarlyExit（預設，遇到第一個非文字頁就停，適合只想快速分流）、Full（全掃，要準確區分「混合」和「純掃描」時用）、Sample(n)（抽樣幾頁，超大檔用）、Pages(vec)（只看你指定的頁）。
回傳結果裡的 pages_needing_ocr 是最實用的一欄。它讓你做到逐頁分流，而不是整份文件二選一。一份 210 頁的財報，如果只有 60 頁是掃描件，你就只為那 60 頁付費。
跟其他本地 PDF 工具比，它贏在哪？
贏在表格和速度，但整體分數其實是險勝。以下是官方在 opendataloader-bench 語料庫（200 份 PDF）上的成績，2026 年 7 月 31 日於 Apple M4 Pro 重跑，分數 0–1，愈高愈好：
| 引擎 | 總分 | 閱讀順序 | 表格 | 標題 | 跑完 200 份 |
|---|---|---|---|---|---|
| pdf-inspector | 0.875 | 0.915 | 0.814 | 0.788 | 0.470 秒 |
| liteparse | 0.873 | 0.913 | 0.693 | 0.811 | 0.750 秒 |
| opendataloader | 0.831 | 0.902 | 0.489 | 0.739 | 2.569 秒 |
| pymupdf4llm | 0.735 | 0.886 | 0.401 | 0.424 | 17.117 秒 |
| markitdown | 0.589 | 0.844 | 0.273 | 0.000 | 16.165 秒 |
把這張表看仔細一點，故事跟宣傳語不太一樣。
總分 0.875 對 liteparse 的 0.873，差距是 0.002，實務上就是打平。閱讀順序也幾乎一樣。標題那一欄 pdf-inspector 還輸了。
真正的差距在兩個地方：表格 0.814 對 0.693，這一項領先幅度是實打實的；以及速度，跑完同一批 200 份文件只要 0.47 秒，比最慢的對手快了 36 倍。如果你處理的是財報、發票、法律文件這類表格密集又要跑量的東西，這兩項就是全部的理由。如果你要的是漂亮的標題階層，liteparse 反而更適合。
這能幫你省多少錢？自己算一次
省多少完全看你的文件組成。下面填自己的數字，馬上看到差別：
把比例拉到 0，你會看到省下的是零。這正好說明一件事：如果你的文件幾乎都是掃描件，這個工具幫不了你什麼。它的價值完全建立在「你有一批本來就不用 OCR 的檔案」這個前提上。
不會寫程式也能試嗎？五步驟上手
命令列工具那條路不用寫任何程式，會複製貼上就行。
- 裝 Rust 工具鏈：到 rust-lang.org 照官方指示裝好
cargo。 - 安裝命令列工具：終端機輸入
cargo install pdf-inspector，等它跑完。 - 先體檢一份檔案：
detect-pdf 你的檔案.pdf，它會回你這份是文字版還是掃描版。 - 轉成 Markdown：
pdf2md 你的檔案.pdf，輸出可以直接餵給 AI 的乾淨文字。加--compact會把目錄那種長串點點壓掉，省 token。 - 只挑需要的頁：
pdf2md 檔案.pdf --select-pages 1,3,5-10，長文件不用整份處理。
要接進程式的話：Python 是 pip install maturin 之後 maturin develop --release；Node.js 是 npm install @firecrawl/pdf-inspector；瀏覽器有 WebAssembly 版本，檔案不用上傳到任何伺服器就能在本機分析完。最後這點對處理合約、病歷這類敏感文件的人有實際意義。
誰該裝、誰不用裝？
| 你的情況 | 建議 | 理由 |
|---|---|---|
| 做 RAG 或文件問答，每月上千份 PDF | 值得裝 | 分流省下的 OCR 費用和延遲最直接 |
| 處理財報、發票、法律文件 | 值得裝 | 表格分數 0.814 是它領先最多的一項 |
| 文件幾乎全是掃描件或照片 | 沒必要 | 它只會告訴你「都要 OCR」，然後你還是得去 OCR |
| 一個月才處理幾份 PDF | 沒必要 | 省下的錢不夠付你研究它的時間 |
| 要的是漂亮的標題階層 | 先看 liteparse | 標題項 0.811 對 0.788，對手贏 |
| 本來就用 Firecrawl 的 API | 什麼都不用做 | Fire-PDF 已經內建，每份 PDF 自動走這條路 |
哪些說法目前還沒有證據？
這一段是我覺得最該寫的。工具介紹文最常見的毛病是把廠商的數字照抄一遍，所以我把還站不住腳的部分挑出來。
- 54% 這個數字是 Firecrawl 自己的統計。它來自 Firecrawl 平台上流過的檔案，沒有公開抽樣方法，也不是第三方稽核過的產業數字。你的檔案組成可能完全不同，試算機裡那條比例請自己拉。
- 跑分是廠商自己跑的。語料庫、對手名單、參數都由 Firecrawl 選定。它比多數廠商誠實的地方在於公開了可重現結果的分支、五個引擎的確切版本號和硬體（Apple M4 Pro），這讓人可以驗證，但選擇權仍在廠商手上。
- 那張表沒有回答多數人真正的問題。官方明講「只列不含模型的本地引擎，且 OCR 已關閉」。所以它完全沒告訴你，面對難搞的文件時，pdf-inspector 跟人們真的會考慮的雲端 VLM 解析器比起來如何。
- 總分領先是打平，不是碾壓。0.875 對 0.873。宣傳會說「總分第一」，但實際可用的差距在表格和速度，不在總分。
- 速度數字跑在 Apple M4 Pro 上。那是一台快機器。你在便宜的 VPS 上不會拿到同樣的 0.47 秒。
- 星數各家對不上。GitHub 官方頁 2026-08-06 顯示 9.0k，第三方追蹤站 Trendshift 同日記錄 10.3k。快照時間差造成，所以本文寫區間而不寫單一數字。
- README 有個小陷阱。手動加相依套件那段還寫著
pdf-inspector = "0.1"，但跑分用的是 0.2.6。用cargo add pdf-inspector才會拿到最新版。
這些不代表工具不好。它 MIT 授權、相依套件只有一個、跑起來確實快。只是你決定要不要導入的時候，該根據能驗證的部分決定，而不是根據標題數字。
不想用它，還有什麼選擇？
- liteparse：跑分幾乎並駕齊驅，標題處理更好。表格需求不高就選它。
- pymupdf4llm：Python 生態最成熟、資料最多，跑分和速度輸一截，但你可能已經裝了。
- markitdown：微軟出品，支援格式最廣（不只 PDF）。純 PDF 品質是這批裡最低的。
- 直接用 Firecrawl 的 Fire-PDF API：不想自己維護就付錢。分類這層本來就是 pdf-inspector，掃描頁會再走神經版面模型和 GLM-OCR。
- 什麼都不換：每月十幾份文件的話，現有流程就夠了。
這件事怎麼接到「多一條出路」？
把視角換一下。這個工具真正示範的，是一種現在很值錢的思路：在昂貴的那一步之前，加一道幾乎免費的判斷。
同樣的邏輯到處都能套。丟給大模型之前先用小模型篩一遍；呼叫付費 API 之前先查本地快取；請人工審核之前先跑規則過濾。多數公司的 AI 帳單失控，原因不是模型太貴，是什麼都往最貴的那條路送。
如果你想靠 AI 接案或做副業，這是很好切入的題目。幫中小企業看一遍他們的文件處理流程、算出哪些呼叫是白花的、把分流那層裝起來，成果可以用省下的金額直接量化。客戶看得懂省了多少錢，比看不懂的技術名詞好談價太多。上面那個試算機就是現成的談案工具，把客戶的數字填進去給他看。
常見問題
pdf-inspector 可以取代 OCR 嗎？
不行，它本身完全不做 OCR。它的工作是判斷哪些頁面需要 OCR，掃描頁還是得送去辨識服務。把它當成分流的路由器，不是辨識引擎。
它是免費的嗎？可以商用嗎？
MIT 授權，免費且可商用。程式碼在 GitHub 上，也發佈在 crates.io、npm 和 PyPI。
中文 PDF 支援嗎？
支援。它處理 Type0／Identity-H 這類 CID 字型的 ToUnicode CMap 解碼，中日韓字元有專門處理，也支援從右到左的文字。遇到字型編碼壞掉的檔案它會標記出來，讓你改走 OCR。
不會寫程式的人用得上嗎？
命令列的 detect-pdf 和 pdf2md 兩個指令不用寫程式，裝好就能用。但要裝 Rust 工具鏈，對完全沒碰過終端機的人還是有一點門檻。
跟 Firecrawl 的 Fire-PDF 是什麼關係？
pdf-inspector 是 Fire-PDF 裡面的分類層。Fire-PDF 是 Firecrawl 的完整解析引擎，跑五個階段：分類、渲染、版面偵測、抽取、組裝，掃描頁會送進神經版面模型和 GLM-OCR。pdf-inspector 就是第一階段，被單獨開源出來。
五個動作，今天就能收尾
- ☐ 拿三份你平常在處理的 PDF，跑一次
detect-pdf，看看有幾份根本不用 OCR - ☐ 把上面試算機的比例改成你剛剛量到的真實數字，重算一次金額
- ☐ 如果省下的錢一年超過幾百美元，把分流那層排進待辦
- ☐ 文件很長的話，先試
--select-pages和--compact，token 帳單會有感 - ☐ 敏感文件不想外傳，改用瀏覽器 WebAssembly 版本，全程留在本機
延伸閱讀
- Firecrawl 是什麼？一個 API 把網站變成 AI 讀得懂的資料
- RAGFlow 是什麼？主打深度文件理解的開源 RAG 引擎
- awesome-llm-apps：100+ 個真的能跑起來的 RAG／AI Agent 範例
- OfficeCLI：一行指令讓 AI 直接做完 Word、Excel、PPT
參考資料
- firecrawl/pdf-inspector — GitHub 官方倉庫與跑分表
- Introducing Fire-PDF — Firecrawl 官方部落格，Eric Ciarla，2026-04-14
- firecrawl/pdf-inspector — Trendshift 趨勢紀錄
利益揭露：本文不含本工具的推薦連結，pdf-inspector 為 MIT 授權的免費開源專案。文中數據截至 2026 年 8 月 6 日，取自官方 GitHub 與 Firecrawl 部落格；跑分為廠商自行執行，已於文中標註限制。工具版本與定價變動快速，導入前請以官方文件為準。本文為技術工具介紹，不構成任何投資或採購建議。
發表迴響