審核步驟是 AI 自動化中最重要的治理控制之一。它們確保在關鍵輸出到達客戶、被發布或觸發金融交易之前，有人進行審查。但一直以來都存在一個摩擦問題：審核者必須登入控制台、導航到審核佇列、查看上下文，然後點擊核准或拒絕。對於忙碌的經理和高階主管來說，他們的工作幾乎都在電子郵件中進行，這種上下文切換會嚴重阻礙工作流程。
我們建立了電子郵件審核功能，徹底消除這個摩擦。
運作方式
當工作流程到達配置了電子郵件傳送的審核步驟時，以下流程會自動執行：
- 工作流程暫停 — 執行引擎將工作流程停在「等待審核」狀態，與控制台審核完全相同。
- 發送上下文郵件 — 系統向指定審核者發送一封電子郵件，包含工作流程上下文摘要：觸發原因、前面步驟的產出結果，以及根據決策結果接下來會發生什麼。
- 一鍵操作按鈕 — 郵件中包含醒目的「核准」和「拒絕」按鈕。每個按鈕都包含一個唯一的簽章操作 URL。
- 記錄決策 — 當審核者點擊按鈕時，操作 URL 會導向一個輕量級 API 端點，驗證令牌並記錄決策。
- 工作流程繼續 — 執行引擎從暫停的位置繼續執行工作流程，審核決策和審核者的中繼資料可供後續步驟使用。
從審核者的角度來看，整個流程只需幾秒鐘。打開郵件、查看上下文、點擊按鈕。無需登入。
安全設計
電子郵件審核的安全性必須至少與控制台審核相當。以下是令牌系統的運作方式：
HMAC 簽章令牌 — 每個操作 URL 都包含一個使用伺服器端密鑰以 HMAC-SHA256 簽章的令牌。令牌編碼了工作流程執行 ID、審核步驟 ID、操作（核准或拒絕）以及過期時間戳記。竄改任何欄位都會使簽章失效。
可配置的過期時間 — 令牌在可配置的期限後過期，預設為 72 小時。過期後，點擊按鈕會返回一條清楚的錯誤訊息，引導審核者前往控制台。這防止過時的審核在數週後被執行。
單次使用強制 — 每個令牌只能使用一次。第一次點擊後，令牌即被標記為已使用。後續對同一按鈕（或相反按鈕）的點擊會返回「決策已記錄」訊息。這防止了重放攻擊和重複提交。
輕量級驗證端點 — 操作 URL 導向一個專用的 API 端點，該端點驗證 HMAC 簽章、檢查令牌過期狀態、確認單次使用狀態、記錄決策並恢復工作流程。不需要會話或認證 Cookie，因為簽章令牌本身就是憑證。
在工作流程編輯器中配置電子郵件審核
工作流程建立者使用他們已熟悉的 ApprovalStepEditor UI 來配置電子郵件審核。唯一的新選項是傳送方式選擇器：
- 僅控制台（預設）— 審核出現在控制台審核佇列中。審核者必須登入。
- 電子郵件通知 — 向指定審核者發送包含一鍵操作按鈕的審核郵件。審核也會出現在控制台佇列中作為備用方案。
- 兩者皆有 — 電子郵件通知加上控制台佇列項目。適用於團隊採用電子郵件審核的過渡期。
審核者的電子郵件地址會自動從其 RBAC 使用者設定檔中取得。如果指定的審核者角色對應到多位使用者，每位都會收到郵件，先採取行動的人即記錄決策。
稽核軌跡與合規性
每次電子郵件審核都會產生與控制台審核相同的稽核記錄，加上電子郵件通道特有的額外中繼資料：
- 核准或拒絕的時間戳記
- 執行操作的審核者電子郵件地址
- 採取的行動（核准或拒絕）
- 點擊操作 URL 的客戶端 IP 位址
- 客戶端的 User Agent
- 令牌過期時間以及操作當下的剩餘時間
- 審核步驟當時的工作流程上下文快照
此稽核軌跡滿足與控制台審核相同的合規要求。對於受 SOC 2、HIPAA 或 SOX 規範的組織，電子郵件審核日誌提供了同等的人工審查和授權證據。
使用案例
電子郵件審核為那些因登入摩擦而避免使用審核步驟的團隊解鎖了治理能力：
內容發布管線 — 編輯使用 AI recipe 撰寫部落格文章草稿。工作流程生成文章後，到達審核步驟。行銷經理在手機上收到郵件，閱讀摘要，在會議間隙點擊核准。工作流程繼續從已核准的草稿生成社群媒體貼文和電子報內容。
財務交易工作流程 — 分析師使用自動化工作流程準備一批發票。財務長收到審核郵件，內含批次總額、行項目數量和供應商明細的摘要。一鍵核准，批次即進入付款系統。
部署關卡 — 工程師透過自動化部署工作流程提交配置變更。DevOps 負責人收到審核郵件，包含差異摘要和目標環境。從 Slack 的電子郵件整合或直接從收件匣中核准。
開始使用
電子郵件審核在所有方案中都可使用。打開任何包含審核步驟的工作流程，選擇「電子郵件通知」作為傳送方式，然後執行工作流程。當工作流程到達審核關卡時，指定的審核者會在幾秒內收到郵件。
對於已經在使用審核步驟的團隊，啟用電子郵件傳送只需對每個步驟進行一鍵配置變更。無需重新設計工作流程。