AI 工作流程容易展示，卻難以完成。順利路徑看起來可能很令人信服，但重試卻會重複副作用、跳過核准，或在沒有證據的情況下回報完成。

本教學將工作流程構想轉化為小型合約與六項驗收測試。範例刻意與模型無關，可套用於 OCR 審核流程、客服工單代理、API 自動化或研究助理。

從可觀測的合約開始

在選擇工具之前，請先撰寫五個欄位：

  1. 工作流程名稱 — 單一有界限的流程，而非整個部門。
  2. 預期成果 — 執行成功時必須可觀測到的狀態。
  3. 人工核准點 — 由人員控制的確切不可逆或外部動作。
  4. 副作用 — 工作流程可能產生的記錄、訊息、付款或系統變更。
  5. 證據參照 — 證明發生了什麼的物件。

實用的完成規則如下：

complete = outcome observed
        AND evidence reference exists
        AND required approval is granted
        AND duplicate side effects = 0

Enter fullscreen mode Exit fullscreen mode

這比「模型回傳了答案」更嚴格，讓周邊自動化變得可測試。

測試 1：順利路徑

提供具代表性的輸入，並斷言預期成果、證據參照、核准狀態與副作用數量。僅有自然語言的品質聲明是不夠的，結果必須有機器可讀的證據。

測試 2：格式錯誤的輸入

移除必要欄位或提供無效的型別。工作流程應在呼叫模型或建立副作用之前拒絕該輸入。失敗必須能被操作者看見。

測試 3：重複事件

傳送相同事件兩次。第二次傳送應回傳既有結果或執行安全的無操作。若能建立兩則通知、工單或付款，則該工作流程不具重試安全性。

測試 4：相依性失敗

模擬逾時或下游 5xx 回應。執行應記錄相依性失敗、保留其證據，並在固定政策內停止或重試。無聲的備援不視為通過。

測試 5：缺少核准

移除必要的人工決策。工作流程必須在外部或不可逆動作之前停止。「建議核准」比強制閘門更弱。

測試 6：缺少證據

在沒有物件或證據參照的情況下回傳成功狀態。驗證器應拒絕完成。這可避免綠色儀表板成為工作已完成的唯一證明。

本地瀏覽器實作

Acceptance Workbench 提供可編輯的合約、確定的四檔案 ZIP 匯出，以及 JSON/NDJSON 執行記錄驗證器。它不需登入、上傳、追蹤腳本、客戶資料或模型呼叫。原始碼與已驗證的 Starter 皆為公開。

此瀏覽器工具刻意保持小型。它不聲稱驗證模型準確度、安全性或法規遵循。其任務是在實作成本變高之前，將模糊的工作流程語言轉化為可觀測的通過／失敗條件。

執行記錄範例結構 

{
  "runId": "run_001",
  "status": "success",
  "outcomeEvidence": "ticket_1842 routed to escalation_queue",
  "validations": {
    "malformedInputRejected": true,
    "dependencyFailureRecorded": true
  },
  "metrics": { "duplicateSideEffects": 0 },
  "approval": { "required": true, "granted": true },
  "artifacts": ["audit_ticket_1842.json"],
  "evidenceRef": "evidence/run_001.json"
}

Enter fullscreen mode Exit fullscreen mode

重要的不是確切的欄位名稱，而是每項驗收測試都能指向可觀測的證據，而非樂觀的完成訊息。

Disclosure: this draft was created with AI assistance. It is intentionally unpublished and requires account-owner review before any external publication.