先把郵件接收與附件處理解耦
不要讓郵件監聽程式直接解析附件並寫入 ERP、CRM 或文件系統。較穩健的做法是先取得郵件識別碼、寄件者、收件時間、主旨及附件摘要，把原始郵件與附件存入受控的物件儲存空間，再送出一筆處理工作。接收端只負責可靠落地與確認收件，後續驗證、分類及整合則由可獨立重試的工作程序執行。這樣即使 OCR、模型服務或 ERP 暫時不可用，也不會阻塞新郵件。
每個附件都應產生穩定的處理鍵，例如郵件識別碼、附件序號與內容雜湊的組合。不要只依賴檔名：同一封信可能重送，使用者也常以相同檔名寄送不同版本。所有下游寫入都應支援冪等性，先查詢處理鍵是否已完成，再決定建立、更新或略過，避免重試時產生重複訂單、案件或文件。
驗證是多層判斷，不只是副檔名
附件進入業務分類前，應先通過安全與結構驗證。副檔名、郵件宣告的 MIME type 與實際檔案特徵可能不一致，因此必須檢查檔頭或可靠的內容偵測結果。壓縮檔要限制展開後大小、檔案數量與巢狀深度；加密或含巨集的文件則應依公司政策隔離，而不是強行解析。惡意程式掃描、內容解析與敏感資料檢查最好保留各自結果，方便日後稽核。
驗證規則要區分「永久失敗」與「暫時失敗」。格式不允許、檔案毀損或密碼保護通常不會因重試而改善；掃描服務逾時、物件儲存短暫失聯則適合重試。常見檢查項目包括：
- 來源：寄件網域、信箱白名單、轉寄規則與郵件驗證結果是否符合預期。
- 檔案：實際類型、大小、內容雜湊、惡意程式掃描及壓縮安全限制。
- 結構：必要欄位、工作表名稱、欄位型別、日期格式與編碼是否可解析。
- 業務：客戶代碼、訂單編號或設備識別碼是否存在，資料是否落在允許期間。
分類要輸出決策依據與信心，而非只有標籤
規則式分類適合穩定且可明確描述的條件，例如特定寄件信箱、固定檔名樣式、PDF 關鍵欄位或試算表欄名。模型分類較適合版面多變、文字描述不一致的報價單、發票或維修紀錄，但不應把模型輸出直接當成事實。實務上可先用確定性規則縮小範圍，再讓模型處理模糊內容，並要求輸出文件類型、信心層級、判斷依據及擷取欄位。
信心門檻必須與錯誤成本一起設計。把一般附件誤送至人工複核，成本通常只是延遲；把採購單誤判為發票並寫入錯誤流程，可能造成後續帳務問題。因此，高信心結果可以自動流轉，中間區間進入人工複核，低信心或類型未知則隔離。人工修正應回寫原始判斷、最終類別與修改原因，既保留稽核軌跡，也能成為後續調整規則或評估模型的資料。
失敗佇列要支援復原，而不是成為垃圾桶
失敗處理至少應區分可重試佇列、永久失敗佇列與人工工作佇列。暫時性錯誤採指數退避並加入隨機延遲，同時設定最大嘗試次數，避免故障服務被大量重試壓垮。每次嘗試都要保存階段、錯誤類型、服務回應摘要與關聯識別碼。到達上限後，工作應轉入失敗佇列，而不是無限循環。
重新投遞前要先確認根因已解除，並從安全的處理階段續跑。例如附件已完成掃描與解析，只是 ERP 寫入失敗，就不必再次下載與 OCR。若程式版本或分類規則已變更，重跑記錄還應標示所用版本，避免新舊結果混淆。
- 監控積壓：追蹤各階段佇列深度、最老工作的等待時間，以及錯誤類型的變化。
- 提供操作能力：支援查看原始附件、修正欄位、略過、重新投遞與留下處理註記。
- 保護資料：限制附件與解析內容的存取權限，設定保存期限，並避免在日誌寫入完整個資或機密內容。
上線前應用重複郵件、毀損 PDF、錯誤副檔名、巨大壓縮檔、模型低信心及下游逾時等情境做端到端測試。真正可靠的附件自動化，不是永遠不出錯，而是每個錯誤都能被辨識、追蹤並以可控方式復原。