直接答案
Automation 多數唔係突然變蠢，而係外圍條件改咗但冇人知道。
最常見原因包括 Token 過期、欄位改名、API 限制、Vendor 更新、Model 或 Prompt 表現改變、公司流程改咗，同埋 Production 環境設定漏咗。
最低限度要監察成功、錯誤、延遲、積壓、用量同告警送達；同時保留重試限制、去重、人工後備、事故 Owner 同復原 Runbook。
先分清故障類型，先可以設計正確監察。
Credential 或 Token 過期
登入、API Key、OAuth 或服務帳戶失效，通常會出現 401、403 或寫入被拒。要有到期 Owner 同告警。
欄位或資料格式改動
表格、CSV、Invoice、Webhook Payload 或 CRM 欄位改名，會令資料缺失、錯位或無法驗證。
Rate Limit、Quota 或用量問題
短時間大量請求、月度上限、付款失敗或服務降速，可以造成延遲、積壓同部分完成。
Model 或 Prompt Drift
模型版本、輸入分布或 Prompt 改動令分類、擷取或文案質素下降，但系統仍然顯示成功。
Vendor 平台更新
API Version、Webhook、權限、畫面、政策或產品功能更改，會令原本正常嘅連接失效。
公司流程同規則改動
新產品、部門、審批人、價格規則或資料責任改咗，但 Automation 仍然跟舊做法。
部署及 Environment 設定
Staging 有嘅環境變數、Secret、Database、Domain、Webhook 或權限冇同步去 Production，會出現『本機正常，上線失效』。
每條重要流程至少要睇六個訊號。
成功執行量
唔只睇有冇 Error。平時每日有 30 次，突然變成 0 次，都可能係 Trigger 已經斷咗。
錯誤量同類型
分開權限、驗證、外部服務、資料、程式同未知錯誤，先可以交畀正確 Owner。
延遲同完成時間
流程未必完全失敗，但由一分鐘變一小時已經可能影響客戶回覆或營運。
Queue 同 Backlog
等待數量持續增加代表處理速度追唔上、下游被限速，或者某類資料不停失敗。
用量同成本
突然增加嘅 API、Token、訊息或執行次數，可能係重試循環、重複事件或濫用。
告警有冇送到
告警系統自己都會壞。要定期測試指定人員真係收到，而且知道下一步做乜。
無限制重試，可以將一個小故障變成重複落單同重複訊息。
每個事件要有唯一 ID，同一事件重試時保持相同 ID。寫入前檢查狀態，短暫錯誤用延遲同有限次重試；資料或權限錯誤就停止，放入人工 Queue。修復後再對帳，確認冇漏做、重複或只完成一半。
例如表格 API 回覆 200，但 Database 冇寫入、通知冇送出或 Conversion Event 冇記錄，對客人仍然係失敗。
故障發生後嘅頭 30 分鐘，要先控制影響，再修復。
確認同分級
確認邊條流程、幾時開始、影響幾多紀錄、係完全停止定資料質素下降。
停止擴大同轉人工
暫停危險寫入或訊息，保留輸入，啟動人工後備，避免錯誤繼續擴散。
修復、驗證同恢復
先喺安全樣本驗證，再逐步恢復流量，監察成功、錯誤、延遲同重複。
對帳同預防再發
找出漏做、重複同錯資料，通知受影響 Owner，記錄根因、修正同預防措施。
網站或 Workflow 每次發佈，都要做一次端到端驗證。
真實提交關鍵表格
用 Production 頁面填一筆可識別測試資料，唔只係睇按鈕可唔可以撳。
確認 Server 同 Database
檢查 API Response、Server Log、Database 寫入、欄位內容、時間同去重狀態。
確認通知同客戶畫面
檢查 Email、WhatsApp 或內部通知，同時確認客戶見到清楚成功狀態，唔會重複提交。
確認 Conversion Tracking
成功提交後只觸發一次正確 Event，並喺 Analytics 或 Debug 工具確認收到。
記錄版本同 Rollback
保存發佈人、時間、Commit、測試結果、已知風險同可以回復嘅上一個版本。
維護合約要分清正常保養、事故處理同新需求。
正常保養
健康檢查、Credential、依賴更新、Log Review、用量、備份、抽樣質素同細微修正。
事故處理
告警分級、回應時間、控制影響、修復、對帳、溝通同事後記錄。承諾時間只應按真實合約列明。
Change Request
新增系統、欄位、商業規則、審批、報表、資料範圍或完整功能，應先重新評估 Scope、風險同測試。
系統可用唔等於 AI 結果仍然合格。
保留一組固定 Evaluation 樣本，記錄預期結果、重要欄位同不接受錯誤。每次改 Model、Prompt、資料處理或重要依賴，就比較新舊版本。正式運行期間按風險抽樣，將低信心、新格式同客訴納入下一輪測試。
每條流程要有業務 Owner、技術 Owner 同人工後備。
業務 Owner
負責規則、優先次序、成功標準、人工例外同批准重要改動。
技術 Owner
負責部署、Credential、監察、事故、文件、依賴同復原。可以係內部或合約供應商。
Runbook 同離場安排
記錄帳戶、流程圖、欄位、告警、常見故障、人工做法、Rollback、資料匯出同交接方法。
常見問題
AI Automation 應該幾耐檢查一次？
關鍵成功、錯誤同積壓應持續監察；Credential、平台、用量、抽樣質素同 Runbook 可按風險每星期或每月 Review。重大改動後要即時重新驗證。
冇 Error 係咪代表系統正常？
唔代表。Trigger 斷咗可以令成功同錯誤都變成零；Model 質素下降亦可能每次都回覆成功。要同時睇成功量、延遲、積壓、用量同抽樣結果。
每次改網站都要測 Form 嗎？
如果 Form 係主要 Conversion Path，應該每次 Production Publish 都做一筆端到端測試，確認 API、Database、通知、成功畫面同 Conversion Event。
維護係咪包所有新功能？
通常唔包括。維護應處理已同意流程嘅健康、錯誤、Credential、依賴同細微修正；新增系統、規則或功能要重新 Scope。
系統壞咗最重要先做咩？
先確認影響同停止錯誤擴大。暫停危險寫入或訊息、保留輸入、轉人工後備，再修復、逐步恢復同對帳。
EXPERT AUTOMATION CONSULTATION
想確認你公司應該由邊度開始？
用一條真實流程做診斷，先整理價值、風險、資料、系統同最小可行範圍，再決定值唔值得建立。