很多自動化流程一開始都很單純：收到表單後建立任務、寄一封確認信、更新試算表，再通知團隊。第一次跑成功時，你會覺得它很省時間。
真正麻煩通常出現在第十次、第百次，或某一天外部服務剛好失敗的時候。
假設流程已經建立客戶資料，也寄出通知信，卻在最後一步更新付款狀態時失敗。這時候不能只說「重跑一次」。重跑可能會寄第二封信、建立第二筆資料，或把原本半完成的狀態弄得更亂。
Cloudflare 在 2026-06-25 介紹 Workflows 的 saga-style rollbacks。Workflows 是 Cloudflare 用來執行多步驟、可持續一段時間的應用流程；saga-style rollback 則是讓開發者為每個 step.do() 寫下對應的補償動作。白話說，就是不要只寫「這一步要做什麼」，也要寫「如果後面失敗，這一步要怎麼補救」。
這篇微課不需要你先學會 Cloudflare。真正值得帶走的是一個通用觀念：多步驟自動化不是會重試就安全，還要知道失敗後怎麼收拾。
先分清楚：重試和復原不是同一件事
「重試」是同一件事再做一次。例如 API 暫時連不上，幾秒後再送一次。
「回滾／復原」是把已經造成的影響處理掉。例如取消保留名額、標記訂單需要人工檢查、寄出更正通知，或把資料狀態改回可重新處理。
這兩件事聽起來都像錯誤處理，但用在不同情境。
如果一個步驟只是讀資料，重試通常很合理。網路短暫不穩、資料庫忙碌、第三方服務暫時超時，都可能靠重試解決。
但如果一個步驟會「真的動手」，重試就可能製造新問題。像是：
- 對客戶寄出 Email 或簡訊。
- 建立帳號、工單、訂單或發票。
- 扣款、退款、發放點數或調整庫存。
- 改 CRM，也就是客戶關係管理系統裡的客戶資料與互動紀錄。
- 呼叫外部工具，讓另一個系統開始工作。
這些步驟一旦發生，世界已經被改變了。後面失敗時，你需要的不是單純重跑，而是補救計畫。
補償動作是「失敗後的下一步」，不是魔法復原
在分散式系統裡，saga 常用來處理一串本地交易。Microservices.io 對 saga 的說明很直接：如果中間某個交易失敗，系統要執行一連串補償交易，明確撤銷前面造成的影響。Microsoft Azure 的補償交易模式也提醒，很多復原不是把資料倒回去就好，而要按照業務規則處理，例如取消預約或發出部分退款。
對一般工作流來說，也可以把「補償動作」想成失敗後的下一個負責步驟。
它不一定是完全復原。很多事情不能真的倒帶。信寄出去了，就不能把收件者腦中的內容收回來；客戶看過錯誤通知，就不能假裝沒發生；外部服務已經建立一筆資料，也不一定能無痕刪除。
所以補償動作通常是這幾種：
- 取消：把預約、任務、訂單或暫存資料取消掉。
- 標記：把狀態改成「需要人工確認」，避免後續流程繼續自動跑。
- 更正：寄出更正通知、補上說明，或更新錯誤資料。
- 隔離：把有疑慮的資料先放到隔離區，不讓它進入正式報表或客戶流程。
- 接手：通知負責這件事的人，附上已完成步驟、失敗點和可選處理方式。
這裡的「負責人」不是文件上寫一個名字就好，而是真的要知道：誰看警示？誰判斷要不要繼續？誰處理客戶或內部影響？
用一張表檢查每一步能不能自動跑
在寫自動化之前，可以先把流程拆成步驟，再問每一步失敗時要怎麼補救。
| 流程步驟 | 失敗時最怕什麼 | 先寫好的補償動作 |
|---|---|---|
| 建立內部任務 | 任務建立一半，團隊以為沒建立又手動重建 | 記下外部 ID；重試前先查是否已存在；找不到才建立新任務 |
| 寄出客戶通知 | 後續資料失敗，但客戶已收到不完整訊息 | 停止後續自動寄送；標記需要人工檢查；必要時寄更正通知 |
| 更新付款、點數或庫存 | 金錢或數量被改錯，重跑又改一次 | 不自動重跑高影響步驟；先鎖定紀錄，交由負責人確認差額 |
| 呼叫外部 AI 或代理人 | AI 已經改檔案、開 PR、發出訊息或觸發外部工具 | 要求每次動作留下紀錄；失敗後先停在待審狀態，不讓下一個工具接著做 |
這張表只算一個起點。它的目的不是讓流程變得複雜，而是逼你先回答：如果第 3 步失敗，第 1 步和第 2 步留下的痕跡要怎麼處理？
還有一個通用原則值得先記住：會「動手」的步驟盡量設計成 idempotent。這個英文詞可以先理解成「同一件事做多次，不會造成多份副作用」。例如你用同一個訂單編號建立任務，第二次呼叫時系統應該回傳已存在的任務，而不是再建立一筆。（多數工作流平台的官方文件——包含 Cloudflare——都會強調這一點。）
如果你的流程做不到這一點，就更不能把重試當成唯一保護。
什麼流程最需要先寫復原步驟
不是每個自動化都需要完整的 saga（為每一步都預先寫好失敗補救動作的設計）。把檔名整理好、把資料轉成固定格式、從公開資料產生摘要，風險通常比較低。
但下面幾類流程，只要要放進日常工作，就應該先寫復原步驟：
- 會對外發訊息的流程：Email、簡訊、社群貼文、客服回覆、客戶通知。
- 會改正式資料的流程：CRM、訂單、付款、庫存、會員狀態、權限。
- 會跨系統串接的流程：表單、試算表、專案管理工具、財務系統、外部 API。
- 會讓 AI 連續執行多步驟的流程：會自己讀資料、改檔案、呼叫工具、開 PR 或通知人的 AI agent。這裡的 AI agent 是會自己連續執行多步驟的 AI，不只是回答一句話的聊天機器人。
這些流程的共同點是：失敗後不只影響一個畫面，而是可能留下外部痕跡、錯誤資料或後續連鎖動作。
如果你還說不清楚補救方式，流程可以先停在「產草稿」或「建立待審任務」，不要直接放行到正式動作。
小團隊可以先做的三個改法
第一，替每一條自動化流程加一個「已做過什麼」紀錄。至少留下流程 ID、每一步開始與完成時間、外部系統回傳的 ID、錯誤訊息，以及下一步狀態。沒有紀錄，就沒辦法復原。
第二，把高影響步驟拆出人工核准關卡。核准關卡就是送出前要有人按確認的那一步。凡是會寄給客戶、改錢、改權限、改正式資料的動作，都不要只靠 AI 或自動化腳本自行決定。
第三，為每個高影響步驟寫一句補償規則。例如「如果建立任務後寄信失敗，就不要重建任務；改成通知負責人補寄」。這句話看起來很小，但它會讓流程從「出錯再說」變成「出錯有下一步」。
這堂微課的結論
自動化真正成熟的標準，不是流程平常跑得多順，而是它失敗時能不能被看懂、被停下來、被補救。
Cloudflare Workflows 的 saga-style rollbacks 只是這個觀念的一個新提醒。無論你用的是 Cloudflare、GitHub Actions、Zapier、n8n、內部腳本，或讓 AI agent 幫你串多個工具，都一樣要問：
- 哪些步驟只要重試就好？
- 哪些步驟一旦做了，就需要補償動作？
- 哪些失敗不能自動處理，必須交給負責人確認？
- 復原時要看哪些紀錄，才能知道已經發生什麼？
如果這些答案先寫好，自動化才不是一條看起來很快、壞掉時沒人敢碰的黑盒子。它會變成一條知道怎麼前進，也知道怎麼停下來收拾的工作流。
用日常來理解
- 一條多步驟自動化流程看起來一路順暢，每一步都像可以自己完成。
- 中間某一步突然失敗，團隊先停下來，不急著把整條流程重跑一次。
- 大家啟動事先寫好的補償動作，把前面已經造成的影響整理清楚。
- 最後由負責人接手檢查，決定哪些可以重試、哪些要人工處理。
AI 整理卡
依這篇情境，請 AI 幫你整理
複製到你自己的 AI 聊天工具，讓它把這篇微課轉成你的個人版檢查清單。BMC 不會看到你貼給 AI 的內容。
參考來源
- Cloudflare Blog：How we built saga rollbacks for Cloudflare Workflows — https://blog.cloudflare.com/rollbacks-for-workflows/
- Cloudflare Docs：Rules of Workflows — https://developers.cloudflare.com/workflows/build/rules-of-workflows/
- Microservices.io：Pattern: Saga — https://microservices.io/patterns/data/saga.html
- Microsoft Learn：Compensating Transaction pattern — https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction
