這支程式我最怕的不是漏建，是重複建

前幾天講的都是內部雜務——信件轉寄、附件歸檔、回信分流。今天開始要進到真程旅行社最核心的資料入口：客人的詢問怎麼變成一筆可以追蹤的紀錄。

第一個做的系統看起來很單純：每 15 分鐘掃一次 Gmail，把客人的第一封旅遊詢問信解析成欄位，寫進客戶資料表。但做下去才發現，最難的不是解析信件內容，是確保同一個客人不會被建檔兩次。

為什麼「第一封信」這麼難判斷

客人詢問一趟旅程，通常不會只寄一封信就結束，中間會來回好幾封確認細節。只有第一封該建檔，後面的都是同一個案子的延續。問題是，程式怎麼知道現在看到的這封，是不是「第一封」？

四層保險

我後來做了四層防重複，一層一層疊上去，把漏洞越補越小。

第一層看整個對話串：只要這串信裡出現過我方的回覆，代表這個案子已經在往來中，整串信永遠不會被拿去建檔，不管掃到幾次。

第二層是本地端自己記一份帳，記錄哪些對話串已經處理過、哪些客人 Email 已經建過檔。這一層看起來好像多餘，其實是撐住系統的關鍵——因為 Smartsheet 本身的搜尋索引更新有延遲，如果只靠即時查詢客戶資料表判斷「這個 Email 有沒有建過檔」，中間那幾分鐘的空窗期，同一個客人可能會被建兩次。本地端的紀錄不受這個延遲影響，補上了這個洞。

第三層才是建檔前先去客戶資料表搜尋一次，同一個 Email 已經有資料列的話就跳過。

第四層是建檔完成後，在原本的信件討論串貼上一個標籤，讓人肉眼也能一眼看出這串信已經處理過，不用打開資料表交叉比對。

其他幾個防呆的小細節

單次執行最多只建五筆，不會因為某個環節出錯而一次灌入大量錯誤資料。AI 判斷這封信根本不是旅遊詢問的話，直接不建檔。解析不出客人姓名或 Email，不會硬塞資料進去，改寄一封通知信請人工處理。同一封信如果連續失敗三次，就不再重試，一樣轉人工，不讓它卡在無限重跑的迴圈裡。

一個容易忽略的坑：本機版跟雲端版只能開一邊

這支系統我後來又做了一個雲端版本，方便隨時執行不受限於某一台電腦。結果一度兩邊同時開著跑，同一封詢問信被兩邊都處理了一次，各自寄出一封「已建檔」的確認信。這種坑很難靠程式邏輯完全避免，因為兩邊各自的本地紀錄互相看不到對方——解法很單純，兩邊只能擇一啟用，關掉的那邊確實關乾淨，而不是「應該沒在跑吧」這種猜測。

如果你也是旅行社

自動建檔真正的價值不是省下打字的時間，是不漏單——但這個價值只有在你能證明它不會重複建檔的前提下才成立。重複建檔造成的業務內耗，往往比手動建檔慢一點更麻煩。與其事後補救，不如一開始就把防重複的層數疊夠。