掃描件變可搜尋的向量 PDF：一套開源 Agent 技能，示範了「腳本補位」的分工邏輯

一般 OCR 工具處理掃描文件的方式，是在原圖上疊一層看不見的文字，讓你能搜尋、能複製。但圖還是圖，放大照樣糊，流程圖照樣是一張照片。日前有開發者在 V2EX 分享了一個開源專案 scan-to-vector-skill，走的是另一條路：把掃描件或手機斜拍的文件整個重建成乾淨的 PDF，文字可搜尋複製，圖表與流程圖是真正的向量圖形，版式貼近原稿。

成績單：模型本來就不差，技能讓它更穩

作者附了一份對照實驗。測試頁由程式生成，每頁都有標準答案，涵蓋練習簿、表格、圖表、流程圖、表單與雙欄文章六種版式，其中一半是斜拍帶陰影的手機照片。同一個需求，每個模型跑兩次，一次不用技能、一次用，按文字、版式、圖形與向量比例逐頁計分，滿分 1.0。

結果相當一致：Haiku 5.5 從 0.841 升到 0.997，Fable 5.1 從 0.837 到 0.997，Sonnet 5.5 與 Opus 5.5 原本就有 0.99 上下的水準，套用技能後逼近滿分。值得注意的是耗時變化並不同向：Sonnet 處理 9 頁從 25.7 分鐘縮短到 16.2 分鐘，Haiku 基本持平，但 Opus 和 Fable 反而變慢。作者也明說每個模型只測了兩份文件，耗時數據僅供參考。

換句話說，這份成績單真正說的不是「模型很強」，而是模型已經很強的情況下，剩下那零點幾的差距出在哪，以及怎麼補。

真正起作用的部分：把機器做不好的交回腳本

作者在分享中坦承，最早的版本只是一份寫得很詳細的操作說明，效果不明顯。後來有效的改動，是把 agent 容易出錯的三個步驟抽出來交給腳本。

第一是測量。模型看到的其實是縮小後的圖，位置座標和小字只能用估的。現在改由腳本按像素實測，沒把握的詞裁出來放大，每頁彙總成一張校對圖給模型核對。這有點像請人描述一張縮小到郵票大小的圖面，再要求他報出每個字的座標，與其訓練他目測更準，不如直接給他一把尺。

第二是查漏。模型自己發現不了漏了什麼，於是每次重建後腳本會把成品與原稿逐頁疊圖比對，產出報告列出還缺哪些元素。第三是流程收攏：起草所有頁面只要一條命令，改一個錯字只要在 JSON 裡加一行，避免模型因為步驟繁瑣而自行省略。

這個分工邏輯與近期 Agent 開發圈的共識方向一致。我們先前在Agent 開發者踩出來的五道工程題中整理過，工具約束與效果回歸正是企業導入 Agent 時最常卡住的環節；這個專案剛好提供了一個具體而微的樣本。而在文件進入模型之前的解析品質問題，也是MinerU 被越來越多人採用的原因，兩者面對的是同一類地基工程。

失敗版本也寫進 README，這點值得記下

README 裡保留了失敗紀錄，其中一版反而讓 Sonnet 退步，原因是照片比例算錯了。這種把負結果一起開源的作法，在評渹氾濫的 AI 工具圈並不常見。對想評估這類工具的人，失敗案例往往比成功案例更有參考價值，因為它劃出了適用邊界。

邊界確實存在，作者自己列得很清楚：測試集是合成的英文印刷頁，手寫與中文都沒測過；起草腳本呼叫 Tesseract 時不指定語言、只內建西文字型，所以目前處理不了中文頁面，光裝中文語言包也不夠。另外它按頁消耗 agent 時間，如果你的需求只是「能搜尋就好」，作者建議直接用 OCRmyPDF 更省事。

給一般使用者的判斷

這個專案的意義可以分兩層看。對有大量掃描文件要整理的人，它目前只適合英文印刷文件，而且要有 Python 3.10 以上環境與 tesseract，門檻不算低。對正在做 Agent 應用的開發者，它的價值在方法論：與其寫一份更長的說明書，不如找出模型在哪幾步系統性出錯，把那幾步換成確定性的腳本，再用自動比對代替模型的自我感覺良好。

專案以 MIT 授權開源在 GitHub，評測程式碼一併附上，作者也歡迎用其他模型重跑實驗。安裝方式支援 Claude Code 與 Codex，一行命令即可。