那張報價單上的「7」，掃描後被讀成了「1」

有一次，業務要幫一間靠海飯店的六月團體房報價，手上那份報價單是同業傳真掃描過來的，畫質不太好。系統把內容讀出來、按照往例結構化進資料表，價格那一欄顯示的數字比業務印象中低了一截。業務當下差點就直接照著報出去——幸好那一筆價格前面掛著「待核對」的黃色標記，照著流程點開對應的原始 PDF 核對，才發現紙本上那個模糊的「7」被讀成了「1」，一字之差，團費就差了一截。

這件事讓我更確定，「待核對」這個標記不是走個形式，是真的會被拿來擋下錯誤的機制。

飯店同業寄來的報價單，這幾年累積下來，歸檔的檔案總數已經到 2,270 份。客人問一句「宜蘭那間溫泉飯店雙人房多少」，業務得先翻資料夾、找到對的檔案、打開 PDF、確認效期還沒過、再看清楚這家對平日假日怎麼定義——一次大概十分鐘。

接下來三天，我把這套東西從頭拆開：今天講報價單怎麼變成可以查的資料，明天講入庫跟怎麼避免重複，後天講查詢頁跟追約清單。以下所有飯店名稱、房型、價格與地區都是示意值，不是真實資料。

報價單長什麼樣子，決定了這件事能不能做

一開始我以為難的是辨識，做下去才發現，真正決定成敗的是對方寄來的是什麼格式。

飯店直接提供的數位版 PDF，也就是文字可以反白選取的那種，辨識成功率接近百分之百。用傳真機掃描但畫質還清楚的，多數可以辨識，但數字部分我一律標成待核對。純粹用手機翻拍、或是掃描畫質很差的，經常整份讀不出來，只能列進待人工補登的清單。

這件事讓我體會到一句話：**跟飯店要報價的時候，盡量直接跟對方要 Email 附的數位版 PDF。**這句話對準確率的幫助，比任何演算法優化都有效。改流程往往比改程式便宜——這大概是整個系列裡我最常重複的一個心得。

辨識出來的東西，一律標「待核對」

技術上，報價單丟進指定的雲端硬碟資料夾，就會觸發一段腳本，把檔案交給 AI 的多模態能力去讀，不管是數位版 PDF 還是掃描圖檔都吃同一套流程。讀完之後轉成結構化的資料：飯店名稱、房型、期間、價格、適用對象，每一筆都連得回雲端硬碟上的原始 PDF 檔案連結。

判斷要不要標「待核對」，看的是兩件事：一是掃描畫質本身就不清楚，二是同一個欄位在文件裡出現超過一種可能的讀法。只要碰到其中一種，那一格就自動掛上待核對，不必等人工抽查才發現、也不是每一筆都要人工看過一遍。

這個標記不是形式。AI 讀數字會出錯，而且它出錯的方式特別討厭——不會報錯、不會當掉，就是安安靜靜給你一個看起來很合理的錯誤數字，像開頭那個「7」變成「1」的例子。所以它讀出來的東西在人核對之前，永遠不能被當成確定的價格。抽查確認無誤之後，才會把狀態改成「已核對」。

價格絕不猜測

有一條規則我寫得特別死：辨識不清楚的價格，顯示「—」，不填數字。

還有一種情況更麻煩：有些報價單上的某些期間根本沒有固定價格，寫的是「同官網」或「官網直售價再打折」這種浮動條件。這類我一律記成「無價格」並註明條件，不會自己去算一個數字出來。

理由很直接。報價單這種東西，一個數字錯了，業務可能就照著報給客人了，等到發現的時候，要嘛自己吸收差額，要嘛回頭跟客人改口。這兩件事都比「系統這格沒有資料，請自己打電話問」嚴重得多。

效期以內容為準，不是看檔名

公司對報價單的檔名有範本，會把年份、飯店名、適用對象、期間都寫進去。但系統判斷效期的時候，一律以 PDF 內容裡寫的日期為準，檔名只當參考。

因為實測下來，檔名跟內容對不上的情況並不少——有人複製上一年的檔名改了年份但忘了改期間，有人期間寫反。相信檔名比較省事，但那是把準確度交給命名的人當天有沒有細心。

如果你也是旅行社

這件事開始之前，先去看看你們的報價單是什麼格式。如果大多是翻拍照片跟傳真掃描，那不管用什麼工具辨識，結果都會很勉強——那種情況下最划算的第一步，是先跟飯店改要數位版，而不是先去找更強的辨識工具。