# 大批掃描 PDF 變成可搜尋的檔案庫：依需求選工具，附六百多頁的實際費用 > 手上有一大批只有影像的掃描 PDF，想讓它可以搜尋、可以分類歸檔？這篇依需求分成四條路：不寫程式的桌面軟體、免費的 OCRmyPDF、雲端 OCR，以及我這次用的 AI 逐頁轉寫加 OCR。附六百多頁的實際費用（新增用量費約 7 美元：AI 轉寫每 1,000 頁約 US$9.6，雲端 OCR 每 1,000 頁 US$1.50）、免費與雲端 OCR 的實測差距，以及上傳前要確認的資料政策。 - Author: Paul Kuo（郭曜郎） - Date: 2026-10-24 - Pillar: 創造與建構 / Creation & Enterprise - Tags: 掃描檔數位化, OCR, 可搜尋 PDF, OCRmyPDF, Azure AI Document Intelligence, Claude Batch API, 實錄 - Canonical: https://paulkuo.tw/articles/scan-to-searchable-archive/ - Site index for LLMs: https://paulkuo.tw/llms.txt --- > **TL;DR**：大批掃描 PDF 只要能搜尋，一套 OCR（把圖片裡的字認成電腦文字的工具）就夠：不想寫程式，用桌面 PDF 軟體；要免費、檔案不出門，用 OCRmyPDF；頁數多、可以上雲端，用雲端 OCR，每 1,000 頁約 1.5 美元。還要知道每頁寫什麼、分類編目的話，再加 AI 逐頁轉寫，兩邊互相對照抓錯。我這次六百多頁走最後這條，新增的用量費約 7 美元，不含原本就在付的 AI 訂閱和人力時間；收到的原始掃描檔另外保存，完全沒改。 傍晚六點多，我下載到一份 90 MB 的 PDF：六百多頁的英文紙本文件掃描檔，每一頁都只是一張圖。在 PDF 裡搜尋任何一個字，結果都是零。隨檔附了一份頁碼索引，列出哪幾頁是哪份文件。 一開始只打算把內容轉成文字。晚上九點多，決定再進一步，整理成一套有代碼的檔案庫，交給同事用。到了半夜十二點多，它變成八十多份各自獨立、可以全文搜尋的 PDF，每份配一個 Word 文字檔（方便搜尋和複製，但不能當正本），最上層一份總目錄 Excel 和一份使用說明。 處理大批掃描 PDF 是常見的需求，所以我把這次的經驗整理成選擇指引：先依你要的結果選一條路，每條路有做法、費用和限制；這次的實際經過放在第四條路，當作佐證。這篇不是逐步操作手冊，這次寫的程式也沒有公開。 動手的大多是 Claude：程式是它寫的，組檔和驗證也是它跑的。我負責定範圍和拍板，也自己開了雲端帳號，用到帳號金鑰的那一步由我在自己電腦上執行。不會寫程式的人，也可以這樣分工：把這篇的選擇表、轉寫規則和官方文件連結，交給會寫程式的 AI 代理人（能在你電腦上寫程式、跑程式的 AI，例如 Claude 或 Codex），請它照著做。要注意，AI 代理人讀到的檔案內容會送到那家 AI 服務，敏感文件請先看下面的提醒。 ## 你要的是哪一種結果？先選一條路 先問自己兩件事：只要能搜尋，還是要分類編目？檔案能不能上傳到雲端？ | | 你要的結果 | 做法 | 要寫程式嗎 | 檔案上雲端嗎 | 費用 | 我測過嗎 | |---|---|---|---|---|---|---| | 第一條路 | 只要能搜尋 | 桌面 PDF 軟體的文字辨識功能 | 不用 | 多半不用，以各軟體說明為準 | 軟體訂閱或授權費 | 沒測 | | 第二條路 | 只要能搜尋，要免費、檔案不出門 | OCRmyPDF（底層是 Tesseract） | 要開終端機、裝工具、打指令 | 不用 | 免費 | 測過 Tesseract | | 第三條路 | 只要能搜尋，頁數多、可以上雲端 | 雲端 OCR | 要，或請 AI 代理人寫 | 要 | 每 1,000 頁約 US$1.50 | 測過 Azure | | 第四條路 | 還要讀懂每頁、分類、編目 | AI 逐頁轉寫加 OCR，再用程式組檔 | 要，或請 AI 代理人寫 | 要，而且是兩家雲端 | 這次每 1,000 頁約 US$11 | 這次的做法 | > **上傳之前先問三件事**：檔案裡有沒有身分證字號、病歷或未公開的商業資料？公司規定或資料的主人允不允許上傳？那家服務的資料會存多久，會不會拿去訓練，能不能提早刪除？任何一題答不出來，就先別上傳：走第二條路，或改用確定完全在自己電腦上處理的桌面軟體。另外，請 AI 代理人幫忙時，它讀到的檔案內容、畫面和錯誤訊息，也會送到那家 AI 服務；敏感文件請自己執行指令，別讓 AI 代理人打開檔案。 不管走哪一條，都先把原始檔複製一份，所有處理都在副本上做。然後挑 5 頁最難的試跑：有表格的、手寫的、轉了方向的、小字多的。跑完打開搜尋幾個字，再對照原圖，確定品質可以接受才整批做。 ## 第一條路：只要能搜尋、不想寫程式，用桌面 PDF 軟體 打開 PDF，執行軟體裡的文字辨識（OCR）功能，存檔，就有一份可以搜尋的 PDF。 以 Adobe Acrobat Pro 為例（免費的 Acrobat Reader 沒有這個功能）：開啟掃描 PDF 的副本，依序點 All tools（所有工具）→ Scan & OCR → Recognize Text → In This File，按下 Recognize Text。設定裡如果有輸出類型，選 Searchable Image (Exact)：文字疊在原圖上，原圖不動；Editable Text and Images 會把掃描圖換成重新排過的文字，Searchable Image 也會重新取樣影像。跑完用「另存新檔」存成新的檔名，例如「原檔名_可搜尋.pdf」，不要直接按儲存蓋掉原檔。這是英文介面的名稱，中文介面找「掃描」和「識別文字」相關的選項；Adobe 的中文說明頁標題是〈[識別掃描文件中的文字](https://helpx.adobe.com/tw/acrobat/desktop/create-documents/scan-documents-to-pdfs/recognize-text.html)〉。ABBYY FineReader PDF 等軟體也有同樣的功能。 這條路我這次沒有實測，步驟依 Adobe 說明頁與兩份大學圖書館的教學（[操作步驟](https://kb.uwstout.edu/155829)、[輸出類型](https://guides.lib.ku.edu/ocr/acrobat)）整理，版本不同選單也可能不同；價格依方案和地區不同。 ## 第二條路：免費、檔案不出門，用 OCRmyPDF [OCRmyPDF](https://github.com/ocrmypdf/OCRmyPDF) 是免費的開源工具，一行指令就能替整份 PDF 加上文字層，檔案不會離開你的電腦。要用的是「終端機」，也就是電腦上輸入指令的視窗：Mac 在「應用程式」裡的「工具程式」資料夾，也可以用 Spotlight 搜尋「終端機」打開。 Mac 上先照 [Homebrew 官網](https://brew.sh/)的說明裝好 Homebrew（Mac 上安裝這類工具的程式），再在終端機依序執行： ```bash brew install ocrmypdf ocrmypdf --version ``` 第二行會印出版本號，代表裝好了。要辨識英文以外的語言，再執行 `brew install tesseract-lang`。 接著建一個工作資料夾，把 PDF 的副本放進去。在終端機輸入 `cd` 和一個空格，把這個資料夾拖進終端機視窗，按 Enter，就切換到這個資料夾了。再執行： ```bash ocrmypdf -l eng input.pdf output.pdf ``` `input.pdf` 換成你的檔名；檔名有空格的話，前後加上引號，例如 `"我的 掃描檔.pdf"`。`output.pdf` 是加好文字層的新檔，原檔不會被覆蓋。繁體中文把 `eng` 改成 `chi_tra`，中英混排寫 `eng+chi_tra`（代碼見 [OCRmyPDF 語言說明](https://ocrmypdf.readthedocs.io/en/latest/languages.html)與 [Tesseract 語言代碼表](https://tesseract-ocr.github.io/tessdoc/Data-Files-in-different-versions.html)）。跑完打開新檔搜尋幾個字，確認找得到。 有頁面放反、橫躺或歪掉的話，可以在 `-l eng` 後面加上 `--rotate-pages`（轉正）和 `--deskew`（拉直）。這兩個選項會改到新檔的頁面樣子，想保留原貌就不要加。Windows 的裝法見[官方安裝說明](https://ocrmypdf.readthedocs.io/en/latest/installation.html)，裝到能執行 `ocrmypdf --version` 為止；其他選項見[官方範例](https://ocrmypdf.readthedocs.io/en/latest/cookbook.html)。 OCRmyPDF 預設用的辨識引擎是 Tesseract。我這次是直接呼叫 Tesseract，沒有透過 OCRmyPDF，品質可以參考第四條路裡的比較：大多數頁讀得不錯，難頁讀得差。 選用、我沒測：用 Mac 的人還可以試 [AppleOCR 外掛](https://github.com/mkyt/OCRmyPDF-AppleOCR)，改用 macOS 內建的文字辨識。它要用 Python 的安裝工具 pip 裝（`pip install ocrmypdf-appleocr`，需要 Python 3.11 以上），要明確指定時在指令加上 `--ocr-engine appleocr`（OCRmyPDF 17 版以上才有這個選項）。不裝它，前面的 OCRmyPDF 也能用；想試的話，拿幾頁跟原圖比對再決定。 ## 第三條路：頁數多、可以上雲端，用雲端 OCR 微軟 Azure、AWS、Google 三家的雲端 OCR 牌價都是每 1,000 頁 US$1.50。三家裡只有 Azure 能直接回傳可搜尋的 PDF，我這次用的就是它。要注意的是，Azure 的官方資料說明沒有寫會不會拿去訓練（見後面「各家的資料政策」）；照開頭的停損規則，敏感文件要先向微軟或你的公司確認，不然就走本機的路。以下是 2026 年 10 月的官方資訊： | 服務 | 費用 | 免費額度 | 可搜尋 PDF | 我測過嗎 | |---|---|---|---|---| | Azure AI Document Intelligence 的 Read 模型 | 每 1,000 頁 US$1.50（[定價頁](https://azure.microsoft.com/pricing/details/ai-document-intelligence/)、[價格 API](https://prices.azure.com/api/retail/prices?$filter=productName%20eq%20%27Azure%20Document%20Intelligence%27%20and%20meterName%20eq%20%27S0%20Read%20Pages%27)） | 免費方案（F0）一次只分析[前兩頁](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/service-limits) | 直接回傳，[不另收費](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/read) | 測過 | | [AWS Textract](https://aws.amazon.com/textract/pricing/) | 每 1,000 頁 US$1.50 | 新客戶前三個月，每月 1,000 頁 | 要自己接程式，官方部落格有[範例](https://aws.amazon.com/blogs/machine-learning/generating-searchable-pdfs-from-scanned-documents-automatically-with-amazon-textract/) | 沒測 | | [Google Document AI](https://cloud.google.com/products/document-ai/pricing) | 每 1,000 頁 US$1.50 | 定價表第一級（0 到 1,000）標示免費，沒寫是每月還是一次 | 官方工具箱可以轉成 [hOCR](https://docs.cloud.google.com/document-ai/docs/samples/documentai-toolbox-document-to-hocr) 格式，還要再接工具做成 PDF | 沒測 | 用 Azure 的步驟： 1. 開一個隨用隨付的 Azure 帳號。免費試用不一定有，我的帳號就不符合資格。 2. 建一個 Document Intelligence 資源，選付費的 S0 方案；免費方案只會處理前兩頁。 3. 在資源頁面找到「端點」和「金鑰」。端點是這個服務的網址，金鑰是一串密碼，程式兩樣都要用到。金鑰的用途跟信用卡號差不多：不要寫進程式，不要傳給別人，也不要貼進 AI 的聊天視窗。 4. 請寫程式的人或 AI 代理人照[官方文件](https://learn.microsoft.com/en-us/azure/ai-services/document-intelligence/prebuilt/read)寫一支小程式。給他的規格：用 Read 模型（prebuilt-read），API（讓程式呼叫雲端服務的介面）版本 2024-11-30，送出分析時加上 output=pdf；送出後隔幾秒查一次結果，完成了再呼叫下載 PDF 的網址。程式要在執行時才跳出提示請你輸入金鑰，或從你自己在終端機設定的環境變數讀取，不顯示、不存檔。先拿 5 頁跑一次，打開下載的 PDF 搜尋幾個字，確認有文字層再整批送。 5. 設預算警示，花到某個比例就寄信通知你。警示預設是寄信，本身不會停用服務或停止計費（[官方說明](https://learn.microsoft.com/en-us/azure/cost-management-billing/costs/tutorial-acm-create-budgets)）。 我開帳號時卡了兩個地方。我的帳號曾被別的組織邀請過，登入時跑到對方的空間（微軟叫它「目錄」），在那裡被要求設定多重要素驗證，簡訊驗證碼收到了，註冊卻出錯；改成指定從自己帳號所屬的目錄登入，就能正常使用。重點在確認登入的是自己的目錄；多重要素驗證是保護帳號用的，自己的帳號一樣建議開著。另一個是帳單頁的金額只寫「$」，沒標幣別，我要等第一筆費用入帳才能確定是哪種貨幣。畫面上的「$」不一定是美元，在意的話，整批送出前先查清楚帳單幣別。 這次六百多頁，伺服器端只處理了 37 秒，牌價約 US$0.95。花時間的反而是傳檔：結果檔有 92 MB，下載速度只有每秒兩三百 KB，照這個速度要六分鐘上下。終端機一動也不動，我一度以為它停住了。這個服務我先留著，之後如果補來新的掃描，同一支程式再跑一次就好。 ## 第四條路：還要讀懂、分類、編目，加上 AI 逐頁轉寫 讓 AI 把每一頁照原樣轉成文字，拿來分類和編目；OCR 負責搜尋；兩份結果逐頁對照，挑出要人去看的頁。這是我這次的做法，下面是實際經過。 ### 這批掃描檔的狀況 每頁是一張影像，絕大多數是黑白，只有 5 頁是彩色。打字的內文、表格數字和勾選框都清楚，難的是其他東西：有 3 頁是橫式內容直著掃，要轉 90 度才看得懂；頁邊有手寫的星號和問號；有些頁首被切掉一截，日期跟著少了；照片和圖表在黑白掃描裡變成網點。 隨附的索引是起點，但它自己也註明可能有小錯。後來逐頁核對，找到一封信的日期寫錯，兩份文件的分界差了一頁，兩張被當成空白頁的紙是手寫的分隔頁，另一份被註明不完整的文件，核對後是完整的。 用途也先定了：內部閱讀、搜尋、找出處，不當成正式文件交給外部單位。 ### 為什麼要拆成兩件事做？ 因為「讀懂每一頁」和「讓 PDF 可以搜尋」要的輸出不同，擅長的工具也不同。 第一件是 AI 逐頁轉寫。把每一頁的影像交給大型語言模型（Claude、ChatGPT 這類能看圖、會寫字的 AI），請它照原樣轉成有結構的文字：表格還是表格，勾選框照實標出有沒有打勾，螢光筆和手寫都標出來，看不清楚、沒把握的字也要標記。這份文字拿來分類和編代碼，也拿來做 Word 文字版。它的限制是不知道每個字在頁面上的位置，沒辦法疊回 PDF 讓人搜尋、選字。 第二件是 OCR 文字層。OCR 會記下每個字在頁面上的位置，在影像上疊一層看不見的字，這就是「文字層」：平常看不到，搜尋和複製時才用得到。它的限制是不理解內容，表單、手寫和轉向的頁，常常讀成一串亂碼。 兩份結果還有第三個用處：互相檢查。兩套工具的原理不同，出錯的地方通常也不同，逐頁比對之後，對不上的頁就是該由人去看的頁。 ### 轉寫的規則怎麼定？ 先挑 5 頁最難的試跑：封面、有螢光筆的頁、滿是勾選框的表單、粗斜體混排的問答頁，以及轉了 90 度的表格。目視核對過，只錯了一個被切掉一截的日期，才送出全部六百多頁。給 AI 的指令重點有五條： - 照原樣一字不改，錯字也照抄，不修正、不摘要、不翻譯，也不補字。 - 標題、清單和表格的結構都保留。 - 勾選框、螢光筆、手寫和簽名，用固定的記號標出來。 - 頁首、印章和頁碼，也照原位置抄下來。 - 看不清楚的標「看不清」，沒把握的字照最可能的讀法寫，後面加問號。 後面會看到，這些標記正好指出人該看的地方。
完整英文指令　要自己寫程式的人再看（點開複製） ```text Transcribe this scanned page into GitHub-flavored Markdown, verbatim. Rules: - Reproduce every printed word exactly as it appears, including typos, numbering, units, dates and punctuation. Do not correct, summarize, translate, reorder or add anything. - Keep the structure: headings, numbered and bulleted lists, indentation levels, and tables (use Markdown tables). For complex forms, write one "Field label: value" line per field in reading order. - Keep emphasis: **bold**, *italic*, underline. - Checkboxes: [x] for checked, [ ] for unchecked. - Highlighter marks: wrap the highlighted text in ==double equals==. Handwritten ticks or marks in margins: [handwritten mark]. - Handwriting: transcribe it if legible and prefix it with [handwritten]. Signatures: [signature]. - Fax headers, stamps, page numbers, headers and footers: include them on their own lines, in place. - Illegible text: [illegible]. A word you are unsure of: write your best reading followed by [?]. - If the page is blank or nearly blank, output exactly: [blank page] - Output only the transcription. No preface, no comments, no code fences. ``` 影像先縮到長邊 2,500 像素以內，轉成灰階 JPEG 再送，控制每頁的費用。刪除線不在指令裡，模型照 GitHub Markdown 的寫法自己標了出來。
### 實際花了多少錢？ 新增的用量費約 US$7，其中約 US$6 花在 AI 逐頁轉寫，換算每 1,000 頁約 US$9.6，一頁約 1 美分；雲端 OCR 每 1,000 頁 US$1.50。 | 步驟 | 工具 | 用量與時間 | 費用 | |---|---|---|---| | AI 逐頁轉寫 | Claude Sonnet 5.5，批次送出（不急著要結果時用，半價） | 六百多頁分 6 批，5 分鐘內全部回來 | 約 US$6.04 | | 可搜尋文字層（第一版） | Tesseract（免費、開源的 OCR 程式） | 在 AI 的雲端工作環境上跑約 36 分鐘 | 軟體免費 | | 頁面方向偵測 | PaddleOCR 的方向判斷模型（免費、開源） | 約 4 分鐘 | 軟體免費 | | 可搜尋文字層（第二版） | Azure 的 Read 模型，直接回傳可搜尋 PDF | 上傳 90 MB，伺服器端處理 37 秒 | 牌價約 US$0.95，帳單待入帳 | 這 7 美元只算按用量付給兩家雲端服務的錢，不含我原本就在付的 AI 訂閱（寫程式、組檔、驗證的 Claude，以及幫忙審查的 Codex 和 Antigravity），也不含人力時間。沒有這類訂閱、或要請人寫程式的話，要另外算。免費的開源工具，也要有人會安裝、會下指令。 轉寫是按 tokens 計費的。tokens 是 AI 計算文字和圖片用量的單位，不等於頁數或字數。Sonnet 5.5 批次的單價是每百萬 tokens 輸入 US$1、輸出 US$5（[官方定價](https://platform.claude.com/docs/en/about-claude/pricing)）。這次輸入 3,189,072 tokens、輸出 569,843 tokens，平均每頁約 5,000 和 900，換算每 1,000 頁約 US$9.6。頁上字越多、影像越細，費用越高；要估自己的檔案，最準的方法是試跑 5 頁再乘以頁數。官方說批次[大多在一小時內完成](https://platform.claude.com/docs/en/build-with-claude/batch-processing)，24 小時內沒處理到的請求會過期、不收費；這次五分鐘內就全部回來了。 > **📊 關鍵數據** > - **AI 逐頁轉寫**：每 1,000 頁約 US$9.6（一頁約 1 美分）；六百多頁約 US$6.04（Claude Sonnet 5.5 批次） > - **雲端 OCR**：每 1,000 頁 US$1.50；六百多頁約 US$0.95，伺服器端處理 37 秒 > - **免費 OCR**：Tesseract 軟體免費，跑約 36 分鐘（含把 PDF 轉成影像） > - **經過時間**：從下載到第二版約 6 小時，有 AI 代理人寫程式，不是第一次做的人的工時估計 這 6 小時大致分成四段：試跑 5 頁並核對，約 45 分鐘；整批轉寫和逐頁比對，約 45 分鐘；決定整理成檔案庫之後的第一版，約 1 小時 10 分；開雲端帳號、跑雲端 OCR、做出第二版，約 1 個半小時。中間有一段在處理別的事。 ### 免費的 Tesseract 和雲端 OCR 差多少？ 看中位數差不多，看最差的那幾頁就差很多。 Claude 拿 AI 轉寫當對照，看兩套 OCR 讀出來的字，有多少跟轉寫對得上。只算有連續內文的 557 頁： | | Tesseract（免費） | Azure Read（雲端） | |---|---|---| | 對得上的比例（中位數） | 98.0% | 99.5% | | 對不上的字超過一成的頁數 | 66 | 3 | | 比另一套多對上超過 2 個百分點的頁數 | 0 | 185 | 中位數只差 1.5 個百分點。Tesseract 有 66 頁對不上的字超過一成，換成雲端 OCR 只剩 3 頁；兩套差距超過 2 個百分點的 185 頁，全部是雲端那一邊比較好。 這個比例量的是兩套工具的一致度：對照組是 AI 的轉寫，它自己也可能錯，所以拿來挑出該回去看原圖的頁，不能當成正確率。這也只是一批英文打字文件的結果，中文、直書或大量手寫的文件，結果可能完全不同。 ![四格漫畫：Claude 拿 AI 轉寫當對照，看兩套 OCR 讀出來的字，有多少跟轉寫對得上；只算有連續內文的 557 頁。對得上的比例（中位數）：Tesseract（免費）98.0%，Azure Read（雲端）99.5%，中位數只差 1.5 個百分點。Tesseract 有 66 頁對不上的字超過一成，換成雲端 OCR 只剩 3 頁。這個比例量的是兩套工具的一致度，不能當成正確率；這也只是一批英文打字文件的結果。看中位數差不多，看最差的那幾頁就差很多。](/images/articles/scan-to-searchable-archive/01-worst-pages.svg) 時間上，Tesseract 在兩顆 CPU 的雲端工作環境上，轉影像加辨識跑了約 36 分鐘；雲端 OCR 在伺服器端只花 37 秒。 ### 兩套結果怎麼互相抓錯？ 逐頁比對，把對不上的頁挑出來一頁一頁看。這次兩邊都抓到對方的問題。 **OCR 抓到轉寫的錯。** 轉寫完，Claude 又跑了一份免費 OCR 的全文，兩份逐頁比對。有一頁的轉寫只剩一行頁首，OCR 卻讀出整頁內文：AI 在這一頁整頁漏掉了，批次結果卻顯示成功。這一頁後來對照原圖重新轉寫。只看轉寫本身，這種錯很難發現。 **轉寫也抓到 OCR 的問題。** 有兩頁是手寫的表單，免費 OCR 讀成一串亂碼，轉寫逐格標出了手寫的內容。前面那張表，也是拿轉寫當尺，才找得出 Tesseract 讀得最差的那 66 頁。 **轉寫自己標出沒把握的地方。** 轉寫在兩個地方標了不確定：一處是一個標準編號，最後一碼沒讀出來；另一處標了看不清。第一處，雲端 OCR 讀出完整的編號，信心值 0.948（OCR 對自己讀法的把握，最高是 1），放大原圖確認是對的。第二處放大原圖後，看出是修訂追蹤的註解編號，跟同一份文件後面的編號連號。 **方向偵測只能當提示。** 開源的方向判斷模型標出 7 頁沒擺正，其中 3 頁是真的，另外 4 頁它自己的把握都很低，看過全是誤判；雲端 OCR 回報有角度的頁裡，也有 2 頁只是字寫斜了。有標出來的頁，都要看一眼再決定轉不轉。 ### 整理成檔案庫，要定哪些規則？ 先定規則，再動手： - **代碼**：每一批用該批文件的日期開頭，批內序號照該批自己的清單編；清單上有但掃描裡找不到的，也先保留一個代碼，這次約有兩成的代碼是先保留的。日後補來新文件，接得上，也不會打亂舊編號。 - **原件不動**：收到的原始掃描檔放在獨立的資料夾，完全不改。整理出來的 PDF 沿用原本的影像，不重新壓縮；頁碼印記印在每頁下方另外加的一條窄邊上，不蓋到原件；橫式的頁直接用閱讀方向組頁。 - **分開放**：PDF、Word 文字版和原始掃描各放一個資料夾，避免開錯檔。 - **文字版標明身分**：Word 檔方便搜尋和複製，但可能有錯，每份開頭固定一句「引用以 PDF 或原始掃描為準」。 - **總目錄**：一份 Excel，放文件清單、每頁的文字核對分數、找不到的文件與缺頁、跟原索引不同的地方，以及每個檔案的「指紋」（SHA-256 雜湊值，用來確認檔案傳過去之後沒有變）。 規則定好、還沒動手之前，我請另外兩個 AI 工具（OpenAI 的 Codex、Google 的 Antigravity）各自挑錯，兩邊互不知道對方的意見，各提了十幾條。上面幾條規則，大多是這輪審查之後定下或修過的。Codex 還抓到索引裡那封信的日期寫錯：原件上三個地方的日期都一致，是索引寫錯了，批次的順序因此改過。它指出的事實錯誤，都回頭對照原件核實過才採用，做法跟我之前寫的[讓 codex 挑 Claude 的錯，但不照它說了算](/articles/ai-second-opinion-independence)一樣。 ### 交件前要驗什麼？ 要交給別人用、或要長期存檔的話，交件前至少驗這幾件： - 每一頁都有歸屬：屬於哪份文件、是分隔頁，還是重複的影本，逐頁對帳。 - 整理後 PDF 裡的影像，逐張跟原檔比對，完全相同。 - 每一頁都搜得到字；抽幾頁把看不見的字改成紅字疊回去，看位置對不對，轉向的頁一定要抽。 - 檔案清單附上每個檔案的指紋，傳到對方電腦後重算一次，確認沒有傳壞；壓縮檔裡不要夾帶 Mac 的隱藏檔。 這些檢查都是 Claude 寫程式跑的。只是自己要搜尋的話，抽幾頁對照原圖就夠了。驗證程式本身也會出錯，這次就遇過一次誤報，所以檢查失敗時，量尺和被量的東西都要查。 ## 有沒有更便宜的 AI 轉寫，或免費的開源模型？ 有，品質要另外試。以下是 2026 年 10 月的官方單價，只有 Sonnet 是我實測的： | 選項 | 官方單價（批次） | 每 1,000 頁（只有 Sonnet 是實測，其他是粗估） | 說明 | |---|---|---|---| | Claude Sonnet 5.5 | 每百萬 tokens 輸入 US$1、輸出 US$5 | 約 US$9.6（實測） | 我這次用的 | | Claude Haiku 5.5 | 每百萬 tokens 輸入 US$0.05、輸出 US$0.25 | 粗估約 US$0.5 | 單價是 Sonnet 的二十分之一；沒測，先試跑再換 | | Claude Opus 5.5 | 每百萬 tokens 輸入 US$2、輸出 US$10 | 粗估約 US$19 | 單價是 Sonnet 的兩倍；沒測 | | Gemini 3.1 Flash-Lite | 每百萬 tokens 輸入 US$0.125、輸出 US$0.75 | 粗估約 US$0.8 | 沒測；Google [公告](https://ai.google.dev/gemini-api/docs/deprecations)最早 2027 年 5 月 7 日停用 | | Gemini 3.5 Flash-Lite | 每百萬 tokens 輸入 US$0.15、輸出 US$1.25 | 粗估約 US$1.3 | Google 建議用來取代 3.1 Flash-Lite；沒測 | | Gemini 3.8 Flash | 每百萬 tokens 輸入 US$0.375、輸出 US$1.875 | 粗估約 US$2；2027 年起約 US$4 | 2027 年 1 月起單價加倍，批次價也是；沒測 | | [Mistral OCR 4](https://mistral.ai/news/ocr-4) | 每 1,000 頁 US$4，批次 US$2 | US$2 至 4 | 專做文件 OCR，2026 年 6 月推出；沒測 | 粗估的前提：每頁產出的文字量跟這次一樣，約 900 tokens。Claude 的輸入沿用這次的每頁約 5,000 tokens；Gemini 的 PDF 每頁預設 [560 tokens](https://ai.google.dev/gemini-api/docs/media-resolution)，再加上指令約 350 tokens。Gemini 如果開了思考，思考的 tokens 也按輸出計價（[Gemini 定價頁](https://ai.google.dev/gemini-api/docs/pricing)），表中沒有算進去。 單價高低，說明不了品質。便宜的模型會不會漏字、會不會自己補字，只能用自己的文件試：拿那 5 頁最難的，同時丟給兩個模型，逐字對照原圖，再決定整批用哪個。 開源的 AI 辨識模型（olmOCR-2、PaddleOCR-VL 等）授權不用付費，但要有顯示卡（GPU），或花時間在自己電腦上架設。今年 7 月有一篇針對老舊掃描的評測，最高分的模型也只通過不到一半的檢查項，而且其中一類檢查會獎勵省略信頭和印章，要保留原貌的人要看細項（[原文](https://danielvanstrien.xyz/posts/2026/ocr-old-scans/)）。排行榜只能當線索。 ## 上傳到雲端之前，各家的資料政策怎麼寫？ 開頭那三個問題，這次用到的兩家，官方是這樣寫的： - **Azure AI Document Intelligence**：送進去的文件和分析結果，在分析完成後保存 24 小時，之後自動刪除，也可以呼叫 API 提早刪（[官方說明](https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/document-intelligence/data-privacy-security)）。會不會拿去訓練，這頁沒有寫。 - **Claude API**：商業產品的輸入和輸出，預設不拿來訓練模型（[隱私中心](https://privacy.claude.com/en/articles/7996868-is-my-data-used-for-model-training)）；後端在 30 天內刪除，但有例外情形（[保存期限說明](https://privacy.claude.com/en/articles/7996866-how-long-do-you-store-my-data)）。這兩頁沒提能不能提早刪；如果用批次處理，[批次處理文件](https://platform.claude.com/docs/en/build-with-claude/batch-processing)寫著請求和結果最多保存 29 天，處理完可以呼叫 API 刪除那一批，但沒寫刪除後資料是不是立刻清掉。 查資料時另外看到一條：AWS 的 AI 服務可能保存並使用客戶內容來改善服務，用途包括訓練模型，也可能存到你使用區域以外的機房。Textract 在[名單](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out_all.html#ai-opt-out-all-list)上，要透過 AWS Organizations 的 [AI 服務退出政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_ai-opt-out.html)關掉。官方頁沒寫的部分，就是還沒確認，不等於安全。 ## 照這次的經驗，順序可以怎麼排？ 回頭看，有兩步可以省： - 第一版的 Tesseract 文字層，一個半小時後就被雲端 OCR 換掉，第一版也沒交出去，直接進了垃圾桶。檔案可以上雲端的話，一開始就用雲端 OCR，可以少做一輪組檔和驗證。 - 雲端 OCR 本身會回報頁面角度。用了它，獨立的方向判斷模型可以省掉，把有角度的頁看一眼就好。 建議的順序：先挑 5 頁最難的試跑，決定轉寫用哪個模型，便宜的先試；文字層交給雲端 OCR，檔案不能出門就用 OCRmyPDF；兩份結果逐頁對照，挑出要人看的頁；最後才組檔和驗證。 ## 收到的原始掃描檔完全沒改 收到的原始掃描檔，原封不動放在檔案庫的獨立資料夾裡。整理出來的每一份 PDF，都沿用原本的影像，沒有重新壓縮；多出來的東西都加在影像之外：一層看不見的字、每頁下方印著代碼的窄邊、書籤，另外每份配一個 Word 文字檔，最上層一份總目錄，標出哪裡缺頁、哪裡跟原索引不同。 不管你走哪一條路，原始檔都另外存一份，所有處理都在副本上做；OCRmyPDF 的轉正、拉直選項會調整頁面，輸出的影像不一定跟原檔相同。下一批掃描進來，照同一套代碼接著編，同一支程式再跑一次。更多工具實作的紀錄，放在「[創造與建構 → 工具與實作](/topics/startup/)」。