系統整合 · 實作指南
讓 Webhook 先進驗證收件箱，再交給 AI
把接收、真偽驗證與業務處理拆開，降低事件驅動流程的混亂。
收到事件不代表可以執行
Webhook 是外部系統進入工作流程的公開入口。假設發票試點收到一份看似合理的 JSON，內容完整也不代表可以啟動審批。應先按提供方的文件驗證來源，再排入正式工作。GitHub 的簽章文件是其中一個參考，但不能把另一家平台的演算法直接照搬。驗證前可記錄必要接收資訊，卻不應讓模型讀取附件、寄信或修改客戶帳目。
建立精簡的事件收件紀錄
驗證後保存提供方事件編號、公司對應、收到時間與處理狀態；持久接收成功後盡快確認，再由背景工作進行較慢的分類。使用事件本身的身份辨識重送，不依賴模型摘要。接收成功與業務完成必須分開：傳輸層已確認，並不表示會計系統已接受發票。介面可同時顯示已接收、驗證失敗、等待處理及已完成，方便追查卡點。
流程一覽
預先設計亂序與重播
不要假定事件必定按順序到達。舊事件晚於新狀態出現時，應先決定哪個系統是正式依據。涉及重要修改前，可重新讀取來源紀錄，同時保留事件歷史以解釋過程。管理員按重播也不能跳過權限檢查；重播應沿用原本操作身份，檢查現在的資料狀態，避免把已取消的工作再啟動。這項規則要寫入操作手冊，而不只藏在程式裡。
用真實故障形狀驗收
用無害測試事件驗證錯誤簽章、重複傳送、延遲更新，以及接收成功後處理失敗。員工應能分辨遭拒流量與只是延誤的工作。除了錯誤率，也要監察最舊未處理事件及核對結果。收件紀錄會增加儲存和維護成本；流量很少時可以採用較簡單的受監察隊列，但來源驗證、重送與重播的決策仍須清楚，不能因此省略。
讓事件收件紀錄可見
可準備一個操作畫面，顯示收到時間、驗證結果、處理狀態和業務參考，支援人員不需開原始內容也能找到延誤事件。用偽造事件與合法但未處理事件測試，確保兩者原因不混淆。再確認事件被搬到失敗隊列後，畫面仍保留可追查關係，避免工作離開主路徑便消失。把這項能力列入交付，有助客戶自己處理常見查詢。
來源與延伸閱讀
編輯原則
本系列以 AI 輔助原創撰寫，並對照連結的公開來源。實作建議與假設情境屬編輯分析，並非客戶實績。來源發布日期及產品細節可能與本系列整理日期不同。