可恢復的行銷自動化：實作與驗收指南

本課內容

01先把定義說清楚
02現場情境
03實作範例
04照著做，每一步都有檢查點
05動手實作
06故障診間
07正式上線前的邊界
08資料來源與主張限制

這一課會完成什麼

判斷哪些步驟適合固定程式、模型判讀或人工決定，避免整條流程都塞進一個 prompt。
以 schema、冪等鍵、checkpoint、timeout 與 dead-letter queue 處理失敗。
在對外發送、發布、CRM 寫入與預算變更前保留可恢復的人工核准。

開始前先準備

• 已完成第 0 堂 charter，能說明介入範圍、輸入、輸出、負責人與禁止動作。
• 至少一份第 2 或第 5 堂 fixture，可在測試環境重複執行。

先把定義說清楚

行銷自動化

可上線的行銷自動化是一串有狀態的工作：接收事件、驗證資料、取得受控脈絡、執行固定規則或模型判讀、檢查結構化結果、等待人工核准、產生副作用，再確認外部系統真正完成。每一步都要留下執行 ID、輸入與版本，失敗時能知道停在哪裡。模型適合處理語意模糊的受限判讀；資料搬運、權限、金額、時間、去重與狀態轉換仍由確定性規則負責。重試不能等於整條流程從頭再跑，尤其在寄信、發布或寫入 CRM 之後。

示範影片通常只走一次順利路徑：表單進來、模型生成、訊息送出。正式環境會遇到 webhook 重送、API timeout、回應格式缺欄位、人工核准隔天才回，以及外部系統已成功但本地端沒收到確認。若沒有執行狀態與去重，同一事件可能建立兩份內容、寄兩封信或覆蓋最新資料。

把所有邏輯放進 prompt 看似省事，後來卻很難測試。像「已退訂不得發送」「預算不得超過上限」「同一 event_id 只能處理一次」都是明確規則，應該由程式檢查。模型只回傳 schema 允許的分類、摘要或建議，會比讓它同時決定權限與副作用更容易除錯。

人工核准若只是一則 Slack 訊息，也可能失去上下文。核准者要看到來源、差異、風險、執行 ID 與預計動作；核准結果要能驗證身分、設定期限並在之後恢復。有人碰巧看到通知，算不上清楚的負責機制。

現場情境

Beacon Brief 自動化

教學用合成案例。公司、事件量、錯誤與時間均為練習資料，不代表 n8n、Zapier 或任何客戶環境。

負責人: Marketing Ops Engineer，要把已核准研究資料轉成內容 brief 草稿，經編輯核准後寫入 CMS 草稿區。
要做的決策: 將流程拆成 intake、validate、generate、schema-check、approval-wait、draft-write、verify 與 complete；以 source_package_id + brief_version 作為冪等鍵。CMS 寫入前後各設 checkpoint，timeout 時先查詢是否已存在，再決定是否重試。
目前狀態: Beacon 每週處理 25 個研究包。現有 n8n 流程收到 webhook 後，把整份文件交給模型，再直接建立 CMS 草稿。上週 webhook 重送造成 3 份重複草稿；另一次 CMS 已寫入，但 n8n 在 30 秒 timeout 後重試，又建立第二份。流程沒有 schema 驗證、核准期限、執行紀錄或手動接管清單。
預期成果: 30 筆含重送、缺欄位、拒答、timeout、逾期與 CMS 部分失敗的 fixture 可重複執行。相同輸入不會產生重複草稿，每筆都能看到目前狀態、花費、核准與接管方式。

限制條件

• 只能讀取 evidence-approved 的 source ID，不得讀受限逐字稿或未核准資料夾。
• 模型只能產生 brief schema；CMS publish、delete 與排程權限一律不授予。
• 編輯核准等待上限為 2 個工作天，逾期轉人工佇列，不自行視為核准。
• 單次模型成本、總重試次數與整體執行時間都有上限。

實作範例

修掉一次 timeout 產生兩份草稿的路徑

證據類型: 具名模擬情境

Beacon 的 CMS API 在建立草稿後偶爾超過 30 秒才回應。自動化平台把這次呼叫標為失敗，從 webhook 節點重新執行；模型重跑一次，CMS 又收到沒有 idempotency key 的 create request。兩份草稿文字略有不同，編輯不知道哪份已核准。刪除其中一份還可能刪錯後續有人修改的版本。

團隊先在 intake 登錄 run_id 與 idempotency_key，生成結果通過 schema 後保存 artifact hash。人工核准綁定 hash，內容被修改便要重新核准。draft-write 送出 external_request_id；遇到 timeout 不立即 create，而是用 external_request_id 查詢。查到既有草稿就進 verify，確認 title、source IDs 與 artifact hash；確定不存在才從 draft-write 重試。重試超過 2 次送 dead-letter queue。

教材測試包含 10 次相同 webhook、5 次格式錯誤、3 次模型拒答、4 次 CMS timeout、2 次核准逾期與 6 次正常執行。最後只有 6 份正常草稿與 4 份 timeout 後確認的既有草稿，沒有重複；格式錯誤、拒答、逾期與查無狀態的項目停在對應佇列。每筆能從 run_id 重建節點、嘗試、成本與人工決定。

主張限制

這是合成 fixture，不代表任何平台的錯誤率。不同 CMS 是否支援 idempotency key、查詢與交易要逐一確認；若外部系統無法查詢，就需要內部 outbox 或更保守的人工確認。模型供應商的 refusal、incomplete 與 rate limit 回應格式也不同，不能把教材欄位直接當正式 API 規格。

做法

照著做，每一步都有檢查點

現場情境

將流程拆成 intake、validate、generate、schema-check、approval-wait、draft-write、verify 與 complete；以 source_package_id + brief_version 作為冪等鍵。CMS 寫入前後各設 checkpoint，timeout 時先查詢是否已存在，再決定是否重試。

01拆分確定規則、模型與人工動作
02定義 schema 與非成功狀態
03加入執行 ID、冪等與 checkpoint

驗收條件

完成品可以回答某一筆執行收到什麼、跑過哪些版本、花多少、誰核准、外部系統有沒有真正寫入，以及失敗後應從哪個 checkpoint 恢復。重送、重試與人工等待都不會讓同一業務事件重複發生。

這張圖要幫你看懂什麼狀態、checkpoint、重試、人工等待與外部副作用必須精確對位，適合使用可版本化的序列／狀態圖。

01
拆分確定規則、模型與人工動作
逐步標記 deterministic、model-assisted、human-decision 或 external-side-effect。資料驗證、權限、去重、金額與狀態用程式；語意摘要才交給模型；公開或難以回復的動作留給人。
檢查點 · 每個節點只有一種主要責任，模型節點沒有 CMS publish、CRM send 或預算權限。
02
定義 schema 與非成功狀態
為輸入與輸出設定必填、enum、長度、source ID 及額外欄位拒絕。把 refusal、incomplete、invalid、timeout 與 rate-limit 分開處理，不把空字串當成功。
檢查點 · 至少 5 個格式錯誤 fixture 會停在 schema-check，原始回應與錯誤位置可查，且不進入核准。
03
加入執行 ID、冪等與 checkpoint
在第一次收到事件時建立 run_id，對業務事件建立穩定 idempotency_key。每個副作用前保存 artifact 與核准，副作用後保存 external_request_id 與查詢結果。
檢查點 · 同一 webhook 送 10 次只形成一個業務執行；重播不會重新花模型成本或建立第二份草稿。
04
把人工核准做成可恢復狀態
核准畫面顯示來源、diff、風險、預計動作、artifact hash 與到期時間。只接受具權限者；修改內容、核准逾期或身分不符都不能直接恢復。
檢查點 · 流程暫停一晚後仍可由同一 run_id 恢復；核准後竄改 artifact 會被擋下並要求重審。
05
注入失敗並演練手動接管
依 fixture 製造 timeout、拒答、rate limit、CMS 已寫入但未回應、憑證失效與核准逾期。驗證退避、上限、查詢後重試、dead-letter 與暫停通知。
檢查點 · 30 筆輸入都有唯一最終狀態，副作用數量符合預期；值班者能在 20 分鐘內找出未完成項目並手動接續。

動手實作

完成一條可重播、可暫停的自動化

用 Beacon Brief 的 30 筆 fixture 建流程，不必連接正式 CMS 或真實 webhook。

準備項目

• 建立隔離的測試資料與 sandbox 憑證，禁止對正式名單、CMS 或廣告帳號寫入。
• 列出每個節點的輸入 schema、輸出 schema、timeout、重試與負責人。
• 準備可回傳成功、格式錯誤、拒答、逾時與部分成功的 stub。

本課產出

一份節點圖、執行合約、結構化輸出 schema、30 筆 fixture、稽核 log、dead-letter queue 與手動接管 runbook。

起始模板: 工作流程執行合約

YAML

workflow_id: beacon-brief-v1
trigger:
  event_type: evidence_approved
  event_id:
idempotency_key: source_package_id + brief_version
states: [intake, validate, generate, schema-check, approval-wait, draft-write, verify, complete, dead-letter]
limits:
  model_attempts: 2
  external_write_attempts: 2
  model_cost_per_run:
  total_runtime:
approval:
  role: editor
  expires_in: 2 business days
  binds_to: artifact_hash
side_effect:
  target: cms-draft-sandbox
  external_request_id:
  query_before_retry: true
audit:
  - run_id
  - input_version
  - prompt_model_schema_version
  - artifact_hash
  - approval_actor
  - node_attempts
  - cost
  - final_state
recovery:
  pause_owner:
  manual_queue:
  resume_from_checkpoint:

預期結果

留給下一課

保存執行合約、fixture、run log 與人工核准元件。第 7 堂會在同一骨架內加入代理式工具選擇，第 8 堂用 trace 建立回歸評估。

驗收條件

01節點圖清楚區分確定規則、模型判讀、人工決定與外部副作用。
02schema 驗證涵蓋正常、拒答、不完整、額外欄位、timeout 與 rate limit。
03同一事件重送 10 次與 CMS timeout fixture 都不會產生重複草稿。
04核准綁定 artifact hash 並有期限；dead-letter 與手動接管能從 run_id 完成演練。

常見故障

故障診間

F1相同 webhook 產生多份內容、任務或 CRM 紀錄。

先檢查: 比對 event_id、idempotency_key、run_id、external_request_id 與各次重試起點。
可能原因: 平台層重試被當成新的業務事件，或副作用後沒有 checkpoint。
修復方式: 暫停新執行，合併或標記重複項目；補穩定冪等鍵並從副作用前後分段恢復。
下次怎麼避免: 把重送與 timeout-after-success 固定放進部署前測試，監測 duplicate prevented 與 duplicate created。

F2模型回傳看似 JSON 的文字，後續節點卻用錯欄位或把拒答當草稿。

先檢查: 查看原始回應、結構化輸出狀態、schema 錯誤、SDK 解析與 fallback。
可能原因: 只剝除 code fence 或用寬鬆 parse，沒有處理 refusal、incomplete 與額外欄位。
修復方式: 停止副作用，改用嚴格 schema 與明確狀態；錯誤輸出進人工或有限重試。
下次怎麼避免: 版本化 schema，保留壞輸出 fixture；模型或 SDK 更新時先跑合約測試。

F3編輯已核准，但恢復後發布的內容不是當時看到的版本。

先檢查: 對照 artifact hash、核准時間、修改事件、工作流程版本與外部寫入 payload。
可能原因: 核准只綁 run_id，等待期間 artifact 被重新生成或人工修改。
修復方式: 撤回待發布項目，要求對最終 hash 重新核准；保存核准畫面的 payload。
下次怎麼避免: 任何內容、來源或設定變更都使核准失效，恢復節點再次驗證 hash 與權限。

展示版之後

正式上線前的邊界

01每個業務事件有 event_id、run_id、穩定冪等鍵、節點狀態、版本、嘗試與時間。
02模型輸入輸出採嚴格 schema；refusal、incomplete、invalid、timeout 與 rate limit 各有路徑。
03服務帳號採最小權限，測試與正式憑證隔離，secret 不進 prompt、輸出或一般 log。
04副作用前後有 checkpoint 與 external_request_id；timeout 時先查詢狀態再重試。
05重試有退避、次數、時間與成本上限；超過上限進 dead-letter 並通知負責人。
06人工核准顯示來源與 diff，驗證角色、期限與 artifact hash；高風險動作不能預設通過。
07監測成功、各類失敗、等待、人工接管、重複防止、完整成本與端到端延遲。
08保留暫停、排空、手動完成、從 checkpoint 恢復及憑證撤銷 runbook，並定期演練。

證據類型

資料來源與主張限制

資料來源只支撐本課標示的主張，不代表換一個系統也會得到相同結果。

[1]
Integrate AI into n8n workflows
n8n · 官方文件 · 2026-08-20
節點式 AI 工作流程、測試、失敗處理與範例
[2]
Zapier developer platform
Zapier · 官方文件 · 2026-08-20
觸發器、動作、API 整合與平台執行模型
[3]
Structured model outputs
OpenAI · 官方文件 · 2026-08-20
結構化輸出、refusal 與 incomplete 狀態的處理邊界
[4]
Building effective agents
Anthropic · 已發表研究 · 2026-08-20
固定工作流程與代理系統的選擇、成本及控制邊界