PDF 餵 AI 為什麼容易讀歪？文字層健檢與 Markdown 中繼的整備工作法

把一份三百頁的年報丟進 Claude Code 或 Codex，問它「合併營收年增率是多少」，模型回答的數字跟財報附註對不起來。再問一次，它翻到的是目錄頁的頁碼而非本文裡那張表。這類經驗在導入 AI 的辦公室裡並不罕見：資料取得容易，模型也讀得動 PDF，可是讀出來的東西常常就是歪的。本文把焦點放在材料這一端：與其歸因於模型能力，不如先檢查餵進去的文件結構對不對。這篇指南從整備方法的角度出發，談怎麼在文件進入模型之前先做一次文字層健檢，用開源工具把 PDF 轉成整齊的 Markdown 中繼檔，再交給代理工具接手，讓每一次的問答都建立在可驗收的文件底盤上。

直覺做法的代價：四種典型翻車現場

把 PDF 原檔拖進對話視窗，是最符合直覺的操作，也是大多數翻車的起點。整理我們在輔導團隊導入 AI 工作流程時反覆遇到的狀況，可以歸納成四種類型，先對號入座，後面的解法才有施力點。

讀取順序翻車

雙欄版面的內文被逐行讀過去，左欄一句接右欄一句，整段語意接不起來。頁首頁尾與浮水印穿插在正文之間，段落被腰斬。模型收到的是一串照座標掃出來的字元流，它沒有辦法知道原版面上哪個區塊屬於誰，只能照單全收，於是引用出來的句子出處錯亂，回答自然跟著錯。更麻煩的是這種錯誤外表看不出來：句子通順、用詞正常，只有對照原文才會發現兩段話根本不是鄰居。

表格翻車

財務報表的四欄數字被壓成一行長文字，小數點黏在一起，欄位對應關係消失。跨頁表格只讀到前半，後半的合計數字不見了。這是知識工作者最痛的一種：數字還在，但結構沒了，模型看起來回答得頭頭是道，其實欄位早就錯位，核對時才發現差一個位數。信手讓模型做「把這季的月營收整理成表」這類任務時，表格翻車的傷害最直接，因為產出還是表格，只是欄位對不上原始文件，錯得很有說服力。

掃描頁翻車

未附文字層的掃描 PDF，整頁內容對抽取器來說是一張圖片。模型端若走文字路線，讀到的是空白或亂碼；若走視覺路線，每一頁都要燒大量的影像 token 去辨識，一份三百頁的掃描文件成本立刻失控，而且表格辨識的正確率依然不穩。最常見的悲劇組合是混合型文件：正文讀得到、蓋章頁讀不到，模型把讀不到的部分安靜略過，答案看似完整，其實缺了一角。

成本翻車

目錄頁的點線、每頁的頁碼、版權聲明、浮水印文字，這些對理解毫無貢獻的內容全數進入上下文視窗。長文件的可用脈絡被垃圾內容吃掉一大塊，真正重要的正文反而被擠到邊緣，模型的注意力分配跟著失衡。這種浪費平時看不出來，等到管線要跑幾百個檔案時，帳單與延遲會誠實反映一切。

四種翻車背後是同一個根因：PDF 這個格式從設計之初就不是為了讓程式理解內容而生的。與其怪模型，不如回頭把進料這一關做好。

問題根源：PDF 是座標的集合，不是文件結構

要理解轉檔這一步為何值得做，得先看清 PDF 內部的真實樣貌。PDF 的設計目標是讓印刷版面在任何裝置上長得一模一樣，它的核心是一連串繪製指令：在哪個座標、用哪個字型、畫出哪個字，以及在哪裡拉出線條矩形。換句話說，多數 PDF 並不以程式可直接利用的形式記載「段落」「標題」「表格」這些結構，檔案裡更多是大量帶著位置資訊的字元片段與圖形指令。

人眼看到的表格，在檔案深處其實是幾條線段的繪製紀錄，加上一批位置湊巧對齊的字。人眼看到的標題，只是一串字號比內文大的字。所謂的讀取順序，多半是人依視覺經驗推斷出來的，許多檔案並未明確記載這件事。這就是文字抽取容易失序的根本原因：抽取器必須從座標反推結構，而反推就會有猜錯的時候。

掃描件又是另一個世界。掃描器吐出來的是整頁影像，連一點文字片段都不留，要恢復文字只能靠光學辨識。混合類文件則兩者皆有：正文帶著可抽取的字元，蓋章頁與附件則是影像。處理路線完全不同，卻共用同一種副檔名，這也是整備的第一步為何永遠是分類，而非直接動轉檔。

模型端的兩條讀法

再從模型端看。今天的模型讀 PDF 有兩條路：一條是文字抽取，平台先把 PDF 抽成文字再送進模型，速度快、成本低，但抽取品質你無從控制；另一條是視覺理解，把頁面轉成圖片讓模型用眼睛讀，版面關係看得清楚，但每一頁的影像 token 成本高昂，而且不同平台對頁數、解析度各有上限。兩條路的共同問題是：處理發生在你看不見的地方，同一份材料換到別的平台、換個版本，讀法可能就變了。整備方法本質上就是把這一步從平台手裡拿回來自己做，做一次，所有平台共用。

用編輯的角度比喻：把 PDF 直接丟給模型，像是把帶殼的食材整籃倒進鍋裡。廚具再好，火候再準，殼終究是殼。先把材料處理成該有的形狀，後面的每一次烹調才有意義。文件整備就是這道前置工，而 Markdown 是目前最通用的備料完成形。

看懂文件的血統：PDF 是怎麼被生出來的

同一種副檔名底下，藏著四種截然不同的出生方式，而出生方式幾乎決定了整備的難易。辨識血統不需要拆檔案，看來源系統與檔案資訊就能推個八九不離十，這一步判斷做得快，後面的路線選擇就少走冤枉路。

第一種是文書軟體直接匯出。Word、Google 文件、試算表轉存的 PDF，文字資訊完整、結構相對規律，是整備成功率最高的一類，年報的本文與多數公務文件都屬於此。第二種是排版軟體輸出。設計導向的工具做出的 PDF，可抽取的字元也在，但版面自由、欄位關係複雜，表格可能沒有框線只靠對齊，轉換要靠啟發式判斷，抽驗要更勤。第三種是掃描或影印轉檔，多半沒有可抽取的文字，只能走辨識；少數掃描檔在產出時已附加辨識文字層，仍以偵測結果為準。第四種是混合血統，最典型的是「正文數位產出、附件掃描貼入」的標案文件，一份檔案裡兩個世界共存。

血統判斷還有一個實務線索：檔案大小與頁數的比值。掃描影像會讓檔案明顯膨脹，異常肥大的檔案值得先有心理準備。大小只是初步線索，不能證明文字資訊健在，路線仍要交給偵測指令與抽驗來定。

Markdown 中繼的三個工程理由

選 Markdown 當中繼格式，背後是三個工程理由。

結構從隱含變明示

一號標題、二號標題、清單破折號、表格直線分隔，這些符號讓文件結構從座標裡的暗示變成文字裡的明示。模型無需再猜哪一行是標題、哪些數字屬於同一張表，摘要、問答與引用的錨點都有了明確邊界。之後如果要進一步做檢索或建立文件庫，切段邏輯也才有乾淨的切點，這對講求引用精準的 GEO 工作也有幫助：AI 引擎解析內容時仰賴清楚的段落邊界，結構亂的內容在檢索與引用階段比較容易吃虧。

token 花在刀口上

Markdown 把版面還原收斂成標題、清單、表格這幾類語意元素，去掉大量的座標與字型資訊；頁碼與點線則依轉換規則與旗標處理，長點線會被摺疊。以 pdf-inspector 為例，它提供精簡輸出模式，主動把目錄頁的長點線壓縮掉，官方文件直接把這個模式稱為節省 token 的輸出。大量文件管線裡，這些節省會直接反映在 API 成本與脈絡視窗的可用空間上。反過來想更有感：目錄越長、頁碼越密，混進上下文的無效內容就越多，每次問答都在為這些垃圾內容付費。

可驗收、可比對、可版本化

以文字形式落地的另一個好處，是每一份產出都可以被檢驗。轉檔結果可以放進版本控制，兩次轉換的差異一眼可比，哪個段落漏了、哪張表格塌了，都能定位到行。相較之下，原檔直餵的路徑裡，進了模型就進了黑盒子，錯了也不知道錯在哪一頁。我們長年做內容管線的經驗是：不能驗收的步驟等於沒做，而可驗收的第一步就是讓產出變成可比對的純文字內容。

順帶一提，Markdown 扮演的是輸入端的角色，產出端的選擇是另一回事，後文談工作規範時會一併交代。

整備流程：盤點、分類、轉換、驗收、歸檔

把整備看成一條五步流程，有別於一次性的轉檔動作，後續才能重複、才能交接、才能讓代理工具自己跑。

盤點排在最前面：這批材料從哪裡來、有幾份、未來是常態進件還是一次性專案。一次性專案用手動指令跑一遍就結束；常態進件則值得把後面四步寫成腳本，放進倉庫一起版控。分類是決策點：先用偵測指令判斷每個檔案的類型與健康度，再決定它走快速轉換路線還是光學辨識路線。轉換把可解析的內容落成 Markdown 檔。驗收抽樣對讀，確認結構沒有塌陷。歸檔則決定這些中繼檔住在哪裡、怎麼命名，讓之後的問答與引用找得到根據。

五步裡最容易被跳過的是驗收，最容易被低估的是歸檔。中繼檔若沒有固定位置與命名規則，代理工具每次都要重新找路徑，工作規範也寫不起來。實務上我們會在專案底下開一個專門收來源文件的資料夾，檔名對應原 PDF，轉出來的 Markdown 就住在旁邊，任何人接手都能對照。命名建議保持機器友善：小寫、連字號分隔、去掉空格，之後寫進規範或讓代理工具引用時，路徑永遠穩定。

常態進件的場景，五步可以收斂成一支很小的批次腳本：迴圈讀資料夾裡的每份 PDF，先跑偵測拿到 JSON 結果，依類型分流，帶字的那批直接轉成 Markdown，掃描類登記到待辨識清單，混合型兩邊都做，收尾時把清單與產出一起寫回資料夾。這種腳本二十行以內寫得完，卻把整條整備從手工活變成基礎設施，之後每一批新文件都直接受惠。

盤點本身值得一張固定欄位的清單：來源系統、取得日期、版本別、授權狀態、敏感等級。五個欄位填完，這批文件能不能進 AI 流程、要不要先遮蔽敏感資訊、誰可以碰，答案已經出來一大半。台灣的企業環境裡，授權與敏感等級尤其不能省：客戶交付的材料、含個資的人事資料、未公開的財務數字，各自對應不同的處理邊界，先分級再動工，能大幅降低事後補救的風險。

第一步健檢：先分類，再決定路線

分類交給工具做。由 Firecrawl 團隊釋出的 pdf-inspector 開源專案把「判別文件類型」與「抽出可讀文字」兩件事做成了一套 Rust 工具，採 MIT 授權，本機執行，預設不做光學辨識，只負責把「需不需要辨識、哪些頁需要」這件事查清楚。它的偵測器會取樣部分頁面的內容流，檢查有沒有文字繪製算子與影像算子，再據此分類，三百頁的巨冊也只要毫秒等級的時間。

分類結果是四種樣貌：天生帶字、掃描成像、圖片構成，以及混合前述幾種。天生帶字的那批可以直接走快速轉換；掃描與圖片兩類需要光學辨識；混合類文件則交給逐頁判斷，工具會附帶輸出一份清單，標明哪幾頁缺乏文字本體，讓你只對那些頁面做辨識，不必讓整本文件跟著陪葬時間。這份頁面清單是整條流程的樞紐：它把「要不要辨識」從整份檔案的二選一，細化成逐頁的路由決策，成本差異由此拉開。要留意預設取樣只看了部分頁面，清單反映的是取樣結果；需要完整逐頁盤點時，改用全文掃描策略再跑一次，清單才是全貌。

↔ 左右捲動檢視完整表格

偵測結果	檔案內部實況	建議路線
天生帶字	文字以繪製指令存在，可直接抽取	快速轉換成 Markdown
掃描型	整份是紙本掃描影像	光學辨識後再轉換
圖片型	內容以圖片形式嵌入	光學辨識或改用視覺模型逐頁讀
混合類	部分頁面有文字內容、部分是掃描影像	文字頁直接轉出，其餘頁面單獨送辨識

取樣策略本身可以調。預設是從文件均勻抽八頁來判斷，取首頁、末頁與中間頁；要求更精確的混合類判定，可以改成全文掃描不提早退出；管線已經知道帶字檔案要快速放行時，也有碰上第一個非文字頁就停的策略可用。大型文件在乎速度就用抽樣，在乎精確就用全文，這是明碼標價的取捨，不是玄學。

指令面有兩條安裝路線。已經有 Rust 工具鏈的開發者，用 cargo 裝上官方 CLI：

cargo install pdf-inspector
detect-pdf report.pdf --json

只有 Node.js 環境的人，裝官方 npm 套件即可，它附了一支同名的命令列工具，子指令與旗標都齊備：

npm install -g @firecrawl/pdf-inspector
pdf-inspector detect report.pdf --json

加上 JSON 旗標後，輸出會包含分類結果、信心分數與需要辨識的頁碼清單，適合直接交給腳本做路由判斷。信心分數是零到一的小數，分數落在中間地帶的檔案值得人工看一眼再定路線，避免把半掃描文件誤判成帶字檔。

讀分類報告有個小訣竅：先看類型，再看信心，第三眼落在頁面清單的分布形態。清單若集中在文件尾端，可能是附錄掃描，但取樣並未覆蓋全部正文；要全貌就以全文掃描策略再確認一次，若散落在正文各處，要警惕文件經過多次編輯拼貼，這種拼貼文件的字元品質常有意想不到的坑，抽驗範圍要放大。文件中繼資料也值得掃一眼，cargo 路線以 pdf2md report.pdf --json 取得的輸出會列出標題、作者與產生器等欄位：產生器寫著文書軟體，血統判斷立刻得到印證；寫著掃描器型號，答案更明確。

若想連表格與欄位版面一起分析，cargo 路線還有一個版面分析旗標可用，偵測與分析一次做完。

專案說明裡有兩個重點值得記住：官方宣稱多數流通中的 PDF 本來就帶著可抽取文字、根本用不著光學辨識，而天生帶字的檔案在本機處理可以壓在兩百毫秒以內。這兩個數字合起來，就是「先分類再處理」這條路的經濟學：把昂貴的辨識留給真正需要的頁面，其餘的用近乎零成本的方式解決。

轉換實作：把可解析的內容落成 Markdown

分類確認屬於帶字或混合類之後，就可以轉換。cargo 路線的主指令是 pdf2md：

pdf2md report.pdf
pdf2md report.pdf --json
pdf2md report.pdf --compact
pdf2md report.pdf --pages
pdf2md report.pdf --select-pages 1,3,5-10

JSON 旗標會連同文件資訊一起輸出，包括標題、作者、產生器與日期這類中繼資料，對來源管理有幫助。精簡模式壓縮目錄點線這類排版雜訊。選頁旗標用範圍語法指定頁次，幾百頁的年報只想先處理財務章節時特別好用；頁面標記旗標則在輸出插入頁碼註記，方便事後把引用對照回原文件的第幾頁，對講究出處的報告工作價值極高。要注意 npm 版的 --pages 是選頁，與 cargo 版插入標記的 --pages 同名不同義，跨路線搬指令時別混用。

npm 路線的命令列工具走同樣的邏輯，語法更精簡：

pdf-inspector report.pdf
pdf-inspector report.pdf --pages 1,2,3
pdf-inspector report.pdf -o report.md

輸出可以直接寫進檔案，不必再靠 shell 重導。兩條路線功能有交集也有差異：npm 版安裝門檻低，適合大多數人；cargo 版旗標完整，還能輸出帶座標的字元項目層級資料，給需要自己畫版面分析的進階玩家，適合要進管線的自動化場景。

至於轉出來的品質，工具內建了一整套結構推斷規則，值得先知道它盡力做了什麼，驗收時才知道要看哪裡。標題層級靠字號比例分層推斷；清單靠常見項目符號與編號樣式辨認；等寬字型會被判成程式碼區塊；表格偵測走兩條路，一條從 PDF 的繪圖指令找矩形框線，一條從文字對齊關係做啟發式判斷，財務表格的跨頁接續也有專門處理；頁碼會被過濾，跨行斷字的連字號會被接回，圖表標題靠 Figure、Table、Source 這類常見前綴辨認。多欄配置有自動欄位偵測，照欄序重排讀取動線，右起左行的字串也在支援範圍。中文文件常見的字型編碼問題也有對策，專案對 Type0 字型提供映射表解碼，遇到解不開的編碼會明確標記，讓上層流程知道該退回光學辨識，免得默默輸出亂碼。

這些規則的原理不神祕：把「人眼怎麼看出結構」拆成一條條可執行的判斷。理解這一點，對輸出結果的期待就會務實：規則覆蓋得住的版面，轉換近乎自動；規則覆蓋不住的設計稿式版面，該換路線就換路線，不必硬轉。

台灣情境實戰：三種常見文件的地雷與解法

上市櫃公司年報

從公開資訊觀測站下載的年報是整備價值最高的文件品項之一：動輒兩三百頁，正文有完整的可選取文字，但目錄點線又長又密，財務附註走多欄版面，合併報表跨頁續表。原檔直餵的下場通常是：模型在目錄頁的頁碼堆裡打轉，數字引用對不上表格欄位。我們建議的走法是先用偵測確認類型，接著用選頁旗標只取需要的章節，搭配精簡模式壓掉點線，轉出來的 Markdown 通常已能直接拿來問答。驗收重點放在兩處：合併報表的欄位是否對齊，以及跨頁表格的合計數字是否接續完整。年報還有一個隱藏好處：轉一次，全公司重複用，投資一次攤提到每一個使用情境上。

政府計畫與標案文件

計畫結案報告與標案文件常見蓋章頁、掃描附件與浮水印，混有掃描頁的情況不少。這類文件的關鍵在分類輸出的頁碼清單：內文頁直接轉換，掃描附件那一批單獨送光學辨識或視覺模型，兩邊產出再合併。硬把整本當成帶字檔來轉，得到的是看似完整、實則缺頁的產出，比不轉還危險，因為缺損是安靜發生的。另要注意部分公文系統輸出的 PDF 帶權限限制，工具讀不動時先確認合法持有與使用權限，再處理檔案本身。

學位論文與技術報告

論文的前置頁常見掃描或美術版面，正文則是規規矩矩的文字本體，參考文獻格式密集。逐頁分類的能力在這裡發揮最大價值：不必為了封面那幾頁掃描影像整本送辨識。實務上正文轉換後，引用文獻區塊的格式雜訊可以靠精簡模式與事後清理處理，重點驗收在章節層級是否塌陷，因為論文的章節深度是後續引用定位的骨架。技術報告同理，圖表多的章節轉換後務必抽讀，確認圖說與正文沒有互串。

掃描頁的交界處理：辨識路線與視覺路線

pdf-inspector 的立場很清楚：預設本機純抽取，不做光學辨識；辨識是可選功能，Rust 與 CLI 使用者在安裝時以功能旗標開啟，Python 與 Node 的原生套件則已整合，走本地小型辨識模型，而且只對被路由到辨識的頁面執行，模型檔與執行環境放在外部，需要時才載入。辨識結果的 JSON 信封有版本編號，逐頁記載來源與信心度，連「哪些頁建議改走代管管線」都有欄位，工程上把可追溯性做足了。

不想在建置環境上折騰的團隊，還有一條更輕的路：把有待辨識的頁面轉成圖片，直接交給具備視覺能力的模型問答。少數幾頁蓋章文件、一張手寫簽核單，視覺路線通常最快；待辨識的頁數累積多了，就值得比較本機辨識與視覺模型的實測成本，再決定要不要建置辨識管線。判斷基準很簡單：一次性、頁數少，走視覺；常態性、批量，先做成本實測再定路線。

有一個邊界要先講清楚：無論哪條路，都別讓整備流程變成個資外洩管線。本機工具的直接價值，在於轉檔階段不必把文件上傳任何服務；至於後續把中繼檔交給哪個模型、要不要外送，仍依實際部署與設定另行確認。把掃描頁成批丟給外部視覺模型前，先想一下這批內容的敏感等級，這是資安治理的基本動作。

接上 Claude Code 與 Codex：把整備寫進工作規範

轉檔做完，價值才開始。讓代理工具把整備流程當成內建習慣，靠的並非每次口頭交代，重點是把規則寫進專案的工作規範檔。在 AGENTS.md 或等效的規範文件裡，把文件處理的規則寫死，例如：

## 文件處理規則
- 收到 PDF 一律先執行 detect，依類型決定路線
- 文字型與混合型的文字頁轉成 Markdown，存入 docs/sources/
- 轉換一律以 cargo 版 pdf2md --pages 加頁面標記，引用內容時附上原文件頁次
- 掃描頁不硬轉，登記清單交由人工或辨識管線處理
- 回答文件相關問題時，只引用 docs/sources/ 內的中繼檔

交辦還可以再分兩種劇本。第一種是整備交辦：請代理工具對資料夾裡新進的 PDF 逐份跑偵測與轉換，把掃描頁登記成清單回報，這是在鋪地基。第二種是使用交辦：地基鋪好之後，一切與文件有關的提問都指向中繼檔，附頁次引用，這是在蓋房子。兩種劇本分清楚，代理工具的回報格式就穩定，人不會被混雜的輸出干擾。

規範寫好之後，交辦的語句可以變得非常短：「讀來源資料夾裡的年報中繼檔，整理合併營收近三年變化，附頁次」。代理工具不必現場解析 PDF，直接讀整齊的 Markdown，答案有頁次可以回查。Claude Code 與 Codex 都支援這種把外部知識放進專案脈絡的做法，相關的觀念與操作，可以對照Claude Code 上手指南與OpenAI Codex 指南；命令列基礎不熟的讀者，CLI 入門先把終端機的門票拿到。關於規範檔怎麼建、怎麼驗證生效，AGENTS.md 入門指南有完整說明。

會用代理工具跑整備，還有一個常被忽略的好處：可重現。指令寫進規範，下次換一批文件，同一套流程原封不動再跑一遍，中繼檔進版本控制，誰轉的、何時轉的、跟原檔差在哪，全部有紀錄。相對地，在對話視窗手動上傳轉檔，每一次都是獨立事件，經驗無法累積。

輸入端用 Markdown，產出端則建議交給 HTML：要產出給人看的報表、摘要頁或文件成品時，HTML 的排版能力與列印表現都遠勝純 Markdown，這部分的論證與作法，寫在Claude Code 產出 HTML 的工作法一文裡。一進一出兩條路各司其職，文件工作迴路就齊了。對以 Markdown 為基底累積知識的讀者，Obsidian 入門則展示了中繼檔落地的另一種長期玩法。

驗收清單：轉完才是一半

轉換產出必須驗收，否則整備只是把一種不可控換成另一種不可控。這份清單是我們實際在用的版本，每次轉檔後逐項跑過：

↔ 左右捲動檢視完整表格

檢查項	看什麼	常見問題
標題層級	最大兩三層標題是否形成合理骨架	層級塌陷或全部擠在同一層
表格抽驗	隨機挑三張表對照原 PDF	欄位黏連、合計漏列、跨頁斷表
雜訊殘留	搜尋頁碼、頁尾、浮水印關鍵字	整排數字或重複文字混入正文
篇幅對帳	產出長度與原文件頁數概略對照	無聲缺頁，掃描頁整段消失
連結保留	點開輸出裡的連結抽測	網址被截斷或黏進標點
編碼健檢	中文段落抽讀是否出現替換符號	字型映射缺失造成的亂碼

六項裡最要緊的是篇幅對帳。缺頁在各種問題裡尤其容易被忽略：模型不會抱怨文件變短，它只會在少了的那部分上安靜地給出錯誤或不完整的答案。花三十秒對一次頁數與段落密度，用極低的成本換掉最貴的盲區。

對讀也有技巧。與其從第一頁開始讀，不如鎖定三個高風險位置：文件裡最大的那張表、任何跨頁續接的表、以及掃描與文字交界的前後頁。這三類位置值得優先抽驗，其他章節仍要依文件特性安排檢查。

驗收結果也值得留下紀錄。哪個檔案、哪一天轉的、抽驗了哪幾張表、發現過什麼問題，四個欄位寫進一份小日誌，價值在兩個月後才會顯現：當同一批文件因為來源改版要重轉時，日誌直接告訴你上次的地雷區在哪，抽驗可以直奔現場。這種紀錄習慣是從出版業的校對傳統借來的，換到機器轉檔的場景一樣成立，成本一分鐘，省下的是每次從零開始的摸索。

中繼檔的下一站：文件庫與檢索

整備出來的中繼檔，價值天花板取決於下一步怎麼用。最常見的進階路線是文件庫：把數百份 Markdown 餵進檢索系統，問答時先搜尋再回答。這條路對中繼品質的要求比直接問答更高，因為切段、嵌入與檢索每一環都在消費文件的結構：標題階層是切段的天然邊界，表格完整度決定數字檢索能不能命中，頁次標記則讓引用可以回溯到原始文件。

換句話說，整備做得好，文件庫就跟著好；整備做得隨便，檢索系統再先進也只能在垃圾裡翻找。這也是為什麼我們始終建議把中繼檔視為正式資產對待：進版本控制、有驗收紀錄、命名可預期。它們不是用完即丟的半成品，是整個知識系統的地基。

對做內容與做搜尋工作的團隊，這條經驗還有一層鏡像意義：你自己的網站內容也一樣。AI 搜尋引擎解析網頁時，面對的也是結構清楚與否的頁面，標題層級、表格語意、段落邊界，都影響內容被理解與引用的品質。把文件當資產整備的紀律，對內支撐文件庫品質，對外也有機會反映在搜尋表現上，同一套功夫，兩個戰場。

成本數學：兩百毫秒與十秒鐘的差距

把帳算出來，決策會自己浮現。以官方數據為例：分類一個文件只要數十毫秒，文字型文件本地抽取在兩百毫秒以內；相對地，把文件送進光學辨識服務，每份要價是二到十秒的等級。假設一批一千個檔案，其中六成本來就帶著文字，先分類再處理的做法，等於讓六百個檔案跳過昂貴的辨識流程，直接以近零成本完成，其餘四成才真正花錢。

再算脈絡帳。視平台實作而定，把 PDF 原檔餵進對話，每輪問答常要重新消化整份原檔內容；中繼檔路線把每輪重新計價的基礎，從動輒數百頁的原檔換成精煉後的中繼檔，若平台對重複讀取提供快取計價，成本還能再壓低一階。若中繼檔確實減少了每輪計費的輸入內容，重複問答會慢慢累積成本收益，幅度依平台計費與快取條件而異，值得用自己的文件實測一次。

還有一筆帳很少被算進去：錯誤的成本。引用錯一個數字，在對外報告裡的代價遠超重跑一次問答，賠上的是信用。看過太多案例，簡報裡的數據被質疑時，才回頭發現來源是模型讀歪的某張表，那時要花掉的不只是修正時間，還有重新建立信任的漫長過程。整備與驗收前置的成本，買的正是這種錯誤不發生的保險，而且保費低廉：它是機器時間與幾分鐘的人工抽驗，不是顧問專案。

時間帳則要看條件。本地抽取的吞吐量是每秒多個檔案的等級，辨識服務則受限於雲端排隊與併行度；批量越大，兩條路的總時程差距通常越明顯，實際差距依文件數量、複雜度與併行設定而定。對週期性任務，例如每季的財報季，先跑一小批實測時程，再決定整備節奏。

什麼情況不該繞這條路

整備方法是為重複與規模而生的，不是所有 PDF 都值得上管線。單張文件、通知函、一頁式報價單，扔進對話問完就放生，轉檔反而多一道手續。以視覺為主的檔案，例如海報、設計稿、資訊圖表，結構本來就不在文字內容裡，轉成 Markdown 只會得到一堆失去意義的零碎標籤，直接用視覺模型看圖才是正解。來源本來就是 Word 或試算表的檔案，回去拿原始檔，比從 PDF 繞一圈乾淨。

判斷的口訣：會重複使用的、要進文件庫的、要逐欄引用數字的，先整備；看一眼就結束的，直接問。工具的存在是為了服務流程。

工具地景與選擇判斷

PDF 轉 Markdown 的工具不只一家，值得用客觀基準看待。pdf-inspector 專案在開放語料上跑過一輪兩百個檔案的基準測試，整體分數、閱讀順序、表格結構與速度四個面向都列了成績，同場競技的包括幾套常見的本地轉換引擎：

↔ 左右捲動檢視完整表格

引擎	整體	閱讀順序	表格	速度（兩百份）
pdf-inspector	0.875	0.915	0.814	0.470 秒
liteparse	0.873	0.913	0.693	0.750 秒
opendataloader	0.831	0.902	0.489	2.569 秒
pymupdf4llm	0.735	0.886	0.401	17.117 秒
markitdown	0.589	0.844	0.273	16.165 秒

數字會隨版本演進，看趨勢就好：這批引擎在表格結構上差距尤其明顯，讀取順序也值得放進一起比較，而這兩件事正好是財務與法務文件最在乎的。已經深度使用 Python 生態的團隊，沿用原本熟悉的引擎完全合理；把表格正確率與處理速度放在第一順位、又要本地隱私的場景，pdf-inspector 的組合目前是突出的。它同時提供 Python、Node、瀏覽器與 Rust 四種整合介面，npm 套件頁對 Node 使用者是最快的切入點。

MIT 授權加上純本機執行，對台灣企業還有一層特殊意義：採購與資安審查少一輪雲端服務評估，含營業秘密的材料不出機器就能進入 AI 工作流程。工具鏈的開放性也代表被鎖定的風險低，哪天要換引擎，中繼檔格式是通用的，搬家成本近乎零。

常見問題

pdf-inspector 是免費的嗎？

是。MIT 授權允許免費取得、部署在自己的機器上，修改與商業應用都在授權範圍內，留意隨附授權條款即可。

使用時檔案會被上傳到雲端嗎？

不會。它是本機執行的工具，文件處理都在自己的電腦上完成，這正是它適合敏感文件的原因。

掃描版的 PDF 可以處理嗎？

它可以正確判斷文件屬於掃描型並列出需要辨識的頁面，但預設不執行光學辨識。辨識是可選功能，也可以改交給視覺模型處理那些頁面。

PDF 內的表格轉換後還留著嗎？

在。工具同時支援從繪圖框線與文字對齊兩種線索偵測表格，輸出成 Markdown 表格，財務表格與跨頁續表有專門處理，但複雜表格仍建議抽驗。

中文文件支援嗎？

支援。專案對中文常見的字型編碼提供映射解碼，原始碼內含中日韓文字處理工具，多欄中文排版的讀取動線也在處理範圍內。

和把 PDF 原檔丟進對話視窗比起來，差別在哪？

差在可驗收與可重複。直接丟只有一次性的答案；先整備再問答，答案有頁次可回查、流程可重跑、成本可預估，資料一多差距會越拉越大。

一定要安裝 Rust 嗎？

不必。日常使用裝 npm 套件就有命令列工具；Rust 安裝路線是給需要完整旗標或要從原始碼調整的開發者。

可以商業使用嗎？

可以。MIT 屬於寬鬆授權，商用、改作與再散布都沒有障礙，保留授權聲明是唯一的要求。