Verification Sandwich 工作流：讓 AI 先自查、再交付、再複核

AI Agent 很容易在「看起來完成了」的地方出問題。它寫了檔案，但沒跑檢查；它說頁面可存取，但沒有貼上 HTTP 結果；它認為內容不重複，但沒有和近期主題比較。Verification Sandwich 的作用，就是把驗證夾在任務前後，讓交付不是一句主觀判斷，而是一組可複查證據。

這個工作流適合內容發布、程式碼修改、資料修復、部署變更等任何容易「口頭完成」的任務。

第一層：開工前驗證

任務開始前先確認三件事：目標物件是否存在，當前狀態是什麼，禁止動作有哪些。比如補發文章前，要先確認 slug 真的不存在；覆蓋舊文章前，要先確認舊 slug 和三語 ID 存在；部署前，要先確認當前線上版本和回滾點。

這一步的價值是防止「修錯物件」。很多事故不是執行能力問題，而是目標識別錯誤。

第二層：交付中驗證

執行過程中不要等到最後才檢查。寫完草稿先查標題和主題；發布前先 dry-run；更新生產環境後立即驗證 API 行、公開頁面和封面資源。每個階段都留下一個最小證據。

這會讓問題更早暴露。翻譯失敗、封面不可達、slug 已存在、相似度過高，都應該在中途被攔住。

第三層：交付後複核

最後的複核必須由另一條視角完成。可以是另一個 Agent，也可以是唯讀腳本。它不參與寫入，只檢查結果：頁面是否 200，內容是否變更，連結是否保留，審計是否通過。

如果後複核失敗，不要用「應該沒問題」壓過去，而要回到具體證據修。

實用模板

• 開工前：確認物件、狀態、禁止動作。
• 執行中：每個關鍵步驟跑一次最小檢查。
• 交付後：用唯讀方式複核線上結果。
• 報告裡：寫清命令、輸出、檔案路徑和剩餘風險。

結論

Verification Sandwich 不是增加流程負擔，而是減少返工。AI 團隊真正需要的不是更多「已完成」匯報，而是能經得起複查的完成狀態。先驗證、再執行、再複核，才能讓自動化交付穩定起來。