訂單從一個系統進來，有人抄進表格，再登進另一個系統開單；客戶訊息先到信箱，有人分類後轉貼到負責的群組。這類「人肉搬資料」是組織裡最常見的隱形成本：慢、容易漏，而且品質取決於當天值班的人有沒有空。這篇是操作配方：用 n8n 把一條既有 SaaS 流程串起來，讓機器做搬運、人只處理例外。全文最重要的一節是第五節——哪些環節可以交給 LLM，哪些環節必須用確定性節點，這條邊界畫錯了，自動化會比人工更危險。
這個場景解決什麼
適合這個配方的流程有四種特徵：高頻率（每天都在發生）、跨系統（資料要從 A 搬到 B）、規則說得清楚（新人照說明也能做）、繁瑣但必須做。四者俱備的人工搬運，通常有三種損耗：延遲（攢到晚上統一處理）、抄錯（欄位對錯行、數字漏一位）、中斷（請假那天流程就停了）。
做完這個配方之後的目標狀態：正常資料全自動跑完，異常資料自動被攔下並推到人面前。人的角色從「每一筆都搬」變成「只看例外」。
同時畫清邊界：這篇處理的是系統間的資料搬運與有限度的判斷，不是要你用 n8n 搭一套業務系統；需要人際判斷與決策授權的環節（例如「這單要不要給折扣」）也不在自動化範圍內。判斷一個場景值不值得自動化，先讀什麼時候不該用 AI。
工具組合與前置準備
- n8n：開源工作流平台，用節點拖拉的方式把系統串起來，有大量現成的服務整合，也能呼叫任何 HTTP API。兩種用法：自架（部署在自己的伺服器，資料與流程都在你的環境裡）或官方雲端（託管、訂閱制）。方案與定價以官網為準；自建與採購的系統性取捨見自建還是採購。
- LLM API（本文以 DeepSeek 為例，任何供應商皆可）：負責流程中「非結構化文字」的判斷與改寫。單價以供應商官網為準；接通後第一件事是在供應商控制台設定花費上限與用量告警。
前置檢查表——每一項都有明確答案才動工：
| 檢查項 | 要確認什麼 | 沒確認就做的後果 |
|---|---|---|
| 系統介面 | 起點與終點系統有沒有 API、webhook，或至少 email 進出口 | 做到一半發現某端無介面，整條流程報廢 |
| 帳號權限 | 申請專用服務帳號，取得最小必要讀寫權限 | 用個人帳號，人一走流程全斷（見常見踩坑） |
| 資料分級 | 流程會經手哪些欄位；能否出內網；能否傳給 LLM | 敏感欄位流經未經評估的工具，合規事故 |
| 維運責任 | 上線後誰看告警、誰修流程 | 流程壞了沒人知道，比沒有自動化更糟 |
資料分級的判斷方法見企業資料安全基本盤。
憑證紀律（先講，因為最常被忽略）：所有密碼與金鑰放進 n8n 的 credentials 機制；不要寫死在節點參數、流程備註或說明文件裡；不要把含憑證的工作流匯出檔傳給任何人。
一、盤點人工搬運點
花一週，把所有「複製、貼上、轉錄、匯出再匯入」的動作列成一張表：
| 起點系統 | 終點系統 | 觸發時機 | 頻率 | 單次耗時 | 出錯後果 | 現在誰做 |
|---|---|---|---|---|---|---|
| 訂單 email | 營運表格 | 信件到達 | 每日多筆 | 數分鐘 | 漏單、出貨延遲 | 值班同事 |
兩個填寫紀律：頻率與耗時是自己計時記下來的，不靠印象——口頭回憶幾乎總是低估；出錯後果要寫具體事件（哪次漏單、哪個欄位抄錯），寫不出後果的流程，說明它可能根本不值得自動化。
這張表有兩個用途：下一步的選型依據，以及上線後計算效益的基線。「自動化前每筆要多久、自動化後例外處理要多久」都從這張表與後面的執行紀錄算出來——自己測的數字，比任何文章裡的參考值可靠。
二、選一條最痛的流程
四個條件同時成立才動手：頻率高（每天發生）、規則寫得出來（能寫成給新人的說明）、出錯有代價（漏做會出事）、兩端系統有介面。
兩類流程先避開：規則每週在變的（自動化追不上變化，維護成本吃掉的比省下的多）；需要人際判斷與授權的（那是決策，不是搬運）。
第一版切小：只做「觸發 → 讀取 → 處理 → 寫入 → 通知」這一條主幹。重試、分支、例外流全留到第二版。一條穩定跑通的主幹，勝過一張完整但沒上線的設計圖。
三、自架還是雲端
| 考量點 | 自架 | 官方雲端 |
|---|---|---|
| 資料位置 | 流程與資料在自己環境，適合分級要求高的資料 | 資料經供應商環境，須先過資料分級這一關 |
| 維護責任 | 升級、備份、停機處置都是你的 | 供應商負責 |
| 起步速度 | 需要一台伺服器與基本部署能力 | 註冊即用 |
| 預算形態 | 伺服器費用加維運人力 | 訂閱制，金額以官網為準 |
決策方法：資料分級結果說「不能出網」時，自架幾乎是唯一選項；否則先用雲端把第一條流程跑通，累積了真實用量與失敗紀錄，再評估要不要遷移。不論哪種，都先用測試資料跑通示範流程，第一天不碰生產資料。
四、串出最小可跑版本
節點組裝順序：
- 觸發節點：定時、webhook，或服務整合的「新紀錄」觸發。優先事件型觸發，退而求其次才用輪詢。
- 讀取節點：從來源系統取得完整欄位。
- 轉換節點：欄位對應、格式轉換、條件分流。每一個欄位都顯式對應，不要依賴「兩邊欄位名稱剛好一樣」——介接系統改版時，剛好的部分會先壞。
- 寫入節點：寫進目標系統。
- 通知節點：把執行結果發到值班渠道。
試跑期三條紀律：
- 用假資料：自造測試紀錄，寫入測試表格與測試群組，兩端逐欄位核對一致才算過。
- 留執行紀錄：除平台內建的執行歷史外，為重要流程加一個「台帳」分支——每次執行把時間、狀態、業務主鍵（如訂單號）、錯誤摘要寫進一張專用表格。這是第八節監控的原料。
- 影子模式上線：自動化先與人工並行跑幾天——機器跑但不作數，人照做，逐日比對兩邊結果。連續一致之後才讓自動化接管，人轉為抽查。
五、哪些環節交給 LLM、哪些必須用確定性節點
這是全文最重要的一節。原則一句話：確定性的工作給確定性節點，LLM 只做「語言」這一類規則寫不盡的事。
| 環節 | 用什麼 | 為什麼 |
|---|---|---|
| 欄位對應、格式與單位換算 | 程式碼節點或內建轉換節點 | 同樣輸入必須同樣輸出；LLM 做不到這個保證 |
| 去重、金額與日期計算 | 條件／過濾／程式碼節點 | LLM 在「看起來很簡單」的計算上會錯，而且錯得不易察覺 |
| 自由文字分類（判斷 email 意圖、工單類型） | LLM 節點 | 規則難以窮舉，這是 LLM 的強項 |
| 把系統紀錄改寫成人話通知 | LLM 節點 | 但通知裡的數字由確定性節點原樣注入，LLM 不得改寫任何數字 |
| 從自由文字抽取關鍵欄位（單號、日期） | LLM 節點＋校驗節點 | 抽取結果必須過規則校驗（格式、範圍、在系統中是否存在），不過就進例外分支 |
兩條鐵律：
- 數字、金額、日期、單號永遠不經過 LLM 的嘴。 這些欄位由確定性節點直接傳遞；LLM 只產語言，不產事實。自動化流程裡代價最高的事故，形態幾乎都是「數字被模型改寫了一個，而且改得很像真的」。
- LLM 輸出永遠當作不可信輸入。 LLM 節點要求輸出固定結構的 JSON（欄位在提示詞裡逐一列舉）；下游第一個節點做格式校驗，校驗不過直接進例外分支，不允許「盡量解析」。
LLM 節點的提示詞寫法：給分類枚舉（超出枚舉輸出 unknown）、給輸出 JSON 的欄位定義、給邊界規則（「只根據輸入文字判斷，不補充推測」），溫度調低以減少隨機性。提示詞不神奇，神奇的是它後面接了校驗節點。
六、錯誤處理、重試與冪等
先把失敗分成三類，因為三類的處置完全不同：
| 失敗類型 | 例子 | 處置 |
|---|---|---|
| 暫時性 | 網路逾時、API 限流 | 節點自動重試（設次數與間隔）；重試耗盡仍失敗進例外分支 |
| 資料性 | 欄位缺失、校驗不過、格式異常 | 不重試（重試還是錯）；直接進例外分支，人修資料後重跑 |
| 設定性 | 憑證過期、API 改版、供應商停機 | 立即停止流程並告警，等人介入 |
冪等是重試的前提：流程要保證「同一筆輸入跑兩次不會出事」。做法是寫入前先用業務唯一鍵（訂單號、訊息編號）查目標系統是否已存在這筆——存在就跳過或更新，絕不無腦新增。沒有冪等設計就開重試，等於裝了一台重複資料製造機：重發的 email、重複的訂單，比人工抄錯還難收拾。
七、失敗告警
- 告警發到「有人在值班」的渠道：即時通訊群組或 email，且群組裡有明確的值班表。告警沒人看，等於沒有告警。
- 告警內容模板：流程名稱、失敗紀錄的業務主鍵、卡在哪個節點、錯誤摘要、發生時間、重跑方式。讓收到的人在半分鐘內能決定「現在處理還是稍後處理」。
- 分級防洗版：單筆資料例外進每日匯總；寫入失敗、憑證過期這類「流程已停」的事件才即時推送。每筆例外都彈一次通知，值班的人很快會把渠道靜音——告警系統就死在靜音那一刻。
八、上線後的監控
- 前兩週是觀察期：每天看執行歷史與台帳，記錄執行總數、失敗次數、失敗原因。兩週之後自己算失敗率與主因分佈——這是你的流程自己的數據，判斷門檻（失敗率高到多少要整修）由你的業務對錯誤的容忍度決定，定了就寫進值班說明，不要引用任何文章裡的現成數字。
- 每週對帳：固定抽幾筆已完成的紀錄，端到端比對來源與目標系統的資料是否一致。抽樣筆數依紀錄量自定，關鍵是固定頻率、留下紀錄、對不上就查到底。對帳抓的是「流程沒報錯但資料錯了」這類最安靜的事故。
- 變更紀律：來源系統 API 改版、LLM 供應商更新模型版本、你改提示詞，都算變更。改動前先用最近的例外樣本與幾筆正常樣本重跑一遍，確認沒有變差再上；改動寫進台帳。
- 成本：LLM 節點的用量乘上供應官網單價，加上平台費用與你的維運時間，就是這條流程的真實成本；估算方法見AI 成本怎麼算。
成果與驗收標準
| 檢查點 | 通過標準 | 沒通過怎麼辦 |
|---|---|---|
| 盤點基線 | 有搬運點盤點表，頻率與耗時是自己計時的紀錄 | 回到第一節；先別急著搭流程 |
| 主幹跑通 | 假資料端到端跑完，兩端欄位逐一核對一致 | 檢查欄位對應與服務帳號權限 |
| 確定性邊界 | 金額、日期、單號沒有任何一個由 LLM 寫入或改寫 | 改成確定性節點直接傳遞 |
| LLM 輸出校驗 | LLM 輸出有格式校驗節點，不合法進例外分支 | 在 LLM 節點後補校驗 |
| 冪等 | 手動把同一筆輸入跑兩次，目標系統沒有重複資料 | 加業務唯一鍵的存在性檢查 |
| 影子期 | 與人工並行連續數日結果一致才交接 | 延長影子期，逐欄位找不一致的原因 |
| 告警有效 | 故意製造一次失敗（暫撤測試憑證），告警在承諾時間內到達值班渠道且內容完整 | 修告警路由與值班安排 |
| 監控習慣 | 台帳連續兩週每週有紀錄，對帳有留痕 | 把監控指派到具體的人，放進行事曆 |
常見踩坑
- 讓 LLM 做確定性工作：「讓 AI 順便整理一下資料」一時方便，代價是同樣輸入可能不同輸出，出了錯無法重現、無從追查。
- 用個人帳號的憑證：當事人離職、改密碼的那天，流程集體猝死。用服務帳號，並納入組織的憑證管理。
- 直接在生產資料上實驗：正確順序是假資料、非敏感真實資料小範圍、全量。跳級的人通常在第二步就出事。
- 沒做冪等就開重試：重試機制會把偶發錯誤放大成重複資料事故。
- LLM 節點不設花費上限：一個迴圈觸發的臭蟲能讓流程整夜持續呼叫 API。上限與告警在供應商控制台設定，五分鐘的事。
- 告警發到沒人看的渠道：沒有值班表的告警是自我安慰。
- 一次自動化所有流程：一週串完盤點表上的每一條，第二週就沒有人力維護任何一條。先讓一條穩定跑滿一個月，把模式沉澱成範本，再複製到第二條。
下一步
- 同一套「自動整理＋人工閘門」模式用在會議場景：會議紀要自動轉行動項並分派
- 流程的前端產品想先做原型驗證：週末做出一個能用的原型網站
- 資料分級與安全邊界：企業資料安全基本盤
- 上線前的合規檢查表：AI 合規與風險邊界
- 流程越串越多、要不要升級成平台：自建還是採購
- 第一次接觸這類工作流工具：不寫程式做出你的第一個 AI 工作流