先講結論：n8n 的邊界不在功能表上
比較自動化工具的時候，多數人會去看功能表——支援幾個整合、有沒有這個節點、能不能寫程式。但實際跑過幾個案子之後會發現，n8n 幾乎什麼都「做得到」，真正決定成敗的不是做不做得到，而是做到那個規模時會不會壞、壞掉時你找不找得到原因。
所以這篇不列功能，只列三條邊界，加上自架與雲端的判斷門檻。這三條都是可以拿現有流程直接對照的。
邊界一：一條流程疊到四、五十步，它就壞定了
n8n 沒有限制你一條流程能放幾個節點，這正是問題所在。當一條工作流程疊到四、五十個步驟，它就成了典型的「巨石流程」——任何一步壞掉，整條一起停，而你要在幾十個節點裡大海撈針找出是哪一步。
比較能撐的做法，是把一個大流程拆成大約四條各司其職的小流程，彼此只透過「輸入與輸出」交接，不去依賴對方內部的邏輯。這樣除錯、更新、擴充都只會動到一個模組。
但拆分本身也有反例。把三個緊密相關的資料清理步驟硬拆成三條流程，只會製造更多需要維護的交接點，該合在一起的還是要合在一起。判準不是「幾步就要拆」，而是這幾步是不是同一件事——同一件事就留在一起，不同件事才拆開。
邊界二：錯誤處理預設是關掉的
這是多數人第一次真正撞到的邊界：n8n 的 Code Node 預設行為是「遇到任何錯誤就整條流程停止」。一個節點壞了，後面全部不跑，而且如果你沒設通知，它會安靜地停在那裡。
要撐得住生產環境，必須手動把節點設定改成「用錯誤輸出繼續」，讓流程分岔出成功與錯誤兩條路。錯誤那條再接一個 IF 節點去判斷錯誤訊息裡有沒有特定代碼——例如訊息裡含有 429，代表你被對方限流了，這種情況該做的是等一下再試，而不是報錯停掉；其他真正的錯誤才讓它停下來並通知人。
這裡有個要特別留意的地方：「等待後重試」如果沒有設重試上限，本身就是一個潛在的無限迴圈。對方服務一直回 429，你的流程就一直等、一直重試，執行次數會被吃光而且沒有人會發現。加重試邏輯的同時一定要加次數上限。
邊界三：卡住你的通常不是 n8n
很多人以為自動化平台本身是瓶頸，實際上真正的天花板，常常來自流程要串的每一個外部服務各自的硬性上限。
常見的幾種形式：CRM 或業務系統的 API 通常有「每分鐘幾次呼叫」的上限；電話或語音類服務會有「同時最多幾通」的並發上限，而且預設值往往很低，要主動申請才調得高；簡訊與訊息類服務則常以「每秒幾則」計算。自動化平台自己也有月執行次數與單次執行逾時的限制，這些會疊在一起。
換句話說，n8n 能不能撐起一個場景，最後常常不是看 n8n，而是看它要串的那個服務願不願意讓你跑到那個量。
這件事沒有通用答案，因為每個服務的數字都不一樣、而且會改。務實的做法是在動手建流程之前，先把這條流程會碰到的每一個外部服務列出來，逐一去查它官方文件寫的速率限制與並發上限，把最小的那個數字當成整條流程的實際天花板。這個動作花不到一小時，但它決定了你接下來要花的幾十小時值不值得。
自架還是雲端：一張可以現場核對的門檻表
這個問題常被當成偏好之爭，實際上有相當清楚的判準。
| 你的情況 | 建議 |
|---|---|
| 能投入維護的技術人力少於三人 | 雲端版 |
| 需要把做好的成品直接交給客戶在他自己的帳號使用 | 雲端版 |
| 相當依賴內建的 AI 輔助建流程功能 | 雲端版 |
| 常態需要同時運行數十條以上的並發流程 | 自架才划算 |
| 有專屬的維運人力照顧這台機器 | 自架才划算 |
| 有醫療、金融這類強制資料落地的法遵要求 | 自架才划算 |
雲端版本身依方案不同，會有每月執行次數的上限，量級從數千次到百萬次以上都有，實際數字以官方定價頁為準——這是會變動的商業條款，不要憑印象記。自架版沒有這層次數限制，但相對地會失去內建的身分權限管理（除非另外購買企業授權）與內建 AI 助手，而且擴容要自己動手。
自架版兩個預設就會出事的地方
如果評估後決定自架，有兩個坑不是「技術不夠好」造成的，而是預設設定本身就會出問題。
第一個是 Google 授權每七天失效。串接 Google 服務時，如果你的 OAuth 應用停留在「測試」狀態，Google 會每七天自動讓授權失效，流程會無預警斷線，而且斷得毫無道理可循。解法是把 OAuth 應用發布成正式環境狀態。這個坑特別惡劣的地方在於，它每次都會讓你以為是流程寫錯了。
第二個是預設資料庫會吃掉你的執行紀錄。自架版預設用 SQLite 存資料，而這個格式不是為容器化的生產環境設計的。容器重啟或版本升級時，很容易在資料真正寫入硬碟之前就被關掉，直接造成近期的執行紀錄消失——而執行紀錄正是你出事時唯一的線索。長期解法是換成 PostgreSQL，這件事愈早做愈便宜。
一個常見的成本誤判
市場上常見的誤判，是把「自架不用付月費」直接等同於「自架比較省」。我們觀察到企業普遍低估了自架需要的基本維運能力——如果團隊沒有把流程本體與登入憑證分開存放的習慣，一次系統升級就可能連帶把整批已經上線的自動化流程弄丟，而那個損失遠大於幾年的訂閱費。
用雲端版每月數十美元等級的訂閱，換掉這一整組風險，對還沒有專職維運人力的企業來說，通常比自架划算。這也正好呼應上面那張表的第一條：技術人力不足三人，就不該選自架。
結語
n8n 是一個好工具，但「它做得到」和「它在你的規模下撐得住」是兩個問題。上面三條邊界如果你對照下來發現有一兩條已經踩到，那通常不代表要換工具，而代表流程的架構該重新切一次。
如果你正在評估要不要用 n8n 撐起某條實際的業務流程，但不確定它會不會在半年後變成沒人敢動的巨石，歡迎談一場「AI導入探索會議」。我們會一起看你這條流程實際會串到哪些系統、瓶頸最可能出現在哪一段，以及這件事值不值得現在做。這是初步對談，還沒有到出具診斷報告的階段。在文末表單簡單描述你目前的狀況，我們收到後會主動與你聯繫，安排時間對談。
