去年我們跑了一個 AI 自動化的報價追蹤流程。用 Make 串了 CRM 跟 Claude API，邏輯很簡單：lead 進來，AI 判斷需求等級，自動生成報價 email，直接送出去。

第一週跑得很順，我們甚至在慶功。

第三週，發現 AI 把一個企業版 lead 的報價低估了 40%，因為 prompt 沒處理到某個特殊的用量條件。那封 email 已經發出去了，客戶已經截圖，業務去收拾殘局花了兩個禮拜。

那次之後我才真的懂，跑通跟能上線是兩件事。

看到論壇那個討論「沒有工程背景，AI 寫的 code 跑起來了，然後呢？」，有人說「沒有 rollback plan 不能上」、「報價出錯比沒報價還慘」。我一邊看一邊點頭，說的就是這件事：AI 系統的上線門檻，跟它能不能跑沒有太直接的關係。

我後來把 AI workflow 按「出錯的後果」分類。後果是內部的就全自動：內容初稿、A/B test 文案、keyword 分類，出錯頂多效率損失。後果是外部的就必須有人工確認點：報價生成、個人化 email、客戶分群，這類我現在一律至少一個人工簽署 step，沒人確認不讓它跑下一步。

第二類最容易出問題，因為看起來可以自動化，但後果是外部的。我們的 Make 流程曾經有一段，客戶填表後自動進 onboarding 序列，某個條件沒設好，6 個 lead 同一天收到三封重複的歡迎信。那週 reply rate 掉了 18%，還要一一發道歉信補救。

關於 trace log，「強制讓 AI 輸出 trace log，出錯了有辦法定位」這個做法我認同，但 log 本身不夠，你還要決定誰來看、多久看一次。我們有段時間有 log 但沒人盯，等到問題被發現，log 裡已經有 80 筆有問題的 record。

後來加了簡單的機制：每天早上 Make 跑一個 summary，把前一天所有 AI node 的 output 狀態 email 給我。不自動修，就是讓我知道哪裡不對勁。這個加下去之後，發現問題的平均時間從 4 天縮到半天。

第三個坑是 human-in-loop 節點沒畫清楚。大家串流程時通常先把 happy path 畫完，human review 是事後才加的，有時候根本忘了。那個「客服 flow 卡死是因為人工確認點沒畫清楚」的案例，我完全有畫面，踩過同樣的坑。

一個行銷 AI workflow 要能上線，我現在問三件事：壞掉怎麼回滾？怎麼在半小時內搞清楚昨天出了什麼問題？哪些 step 要人接手，有沒有清楚畫出來？答不出來就還沒準備好。

穩定性比參數重要這個道理，行銷人通常要親自踩一次才信。我信了。📈