把既有 SaaS 用 n8n 串成一條流程：從人工複製貼上到自動化（Chinese original）

訂單從一個系統進來，有人抄進表格，再登進另一個系統開單；客戶訊息先到信箱，有人分類後轉貼到負責的群組。這類「人肉搬資料」是組織裡最常見的隱形成本：慢、容易漏，而且品質取決於當天值班的人有沒有空。這篇是操作配方：用 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 工作流