n8n vs 自己寫程式：什麼時候該用 no-code 自動化？

該用 n8n 還是自己寫程式？一句話的判準是：流程只是把現成服務串起來、邏輯不複雜、要快速上線，就用 n8n；邏輯複雜、需要版本控制與測試、要規模化或對長期成本敏感，就自己寫。

兩者不是「誰比較強」的問題，而是「你這條流程落在線的哪一邊」的問題——而大多數人卡住，是因為一開始就站錯了邊。

這篇不打算說服你用 n8n，也不打算說服你別用。它要做的是把那條線畫清楚：一張對照表看懂兩者各自贏在哪、一段誠實的隱藏成本、再加一份你拿了就能自己判斷的決策清單。

n8n 是什麼？適合哪一種自動化？

n8n 是一套視覺化的工作流自動化工具：你在畫布上把一個個「節點」拖拉、連線——這個節點收信、那個節點寫進試算表、再一個節點發通知——不太需要寫程式，就能把幾個現成服務串成一條會自動跑的流程。它支援數百種現成整合，卡關時還能在節點裡塞一段 JavaScript 或 Python 當逃生門。

它最甜的場景很明確：你要串的東西都是現成的（SaaS、API、資料庫），中間的邏輯不複雜，而你想要「這週就看到它在跑」。 表單進來自動歸檔、新訂單自動發通知、定時把 A 平台的資料同步到 B——這類「黏合劑」型的工作，n8n 幾小時就能搭起來，自己寫程式反而是殺雞用牛刀。

但「適合快速串接」這件事的另一面，就是它的天花板。要看懂天花板在哪，得把它跟「自己寫」並排比較。

什麼時候該用 n8n、什麼時候該自己寫？

把兩者放在同一張表上，差異會比任何文字描述都清楚：

面向	用 n8n	自己寫程式
上線速度	快——拖拉節點、串好現成 API，當天就能跑	慢——環境、串接、錯誤處理都得自己搭，起步成本高
學習門檻	低——視覺化介面，不太會寫程式也能上手	高——要會一門語言，還要懂部署與環境
邏輯複雜度上限	中——簡單分支與轉換沒問題；邏輯一複雜，流程圖會變成一團難讀的義大利麵	高——再纏的邏輯都能拆乾淨、寫清楚
版本控制與測試	弱——流程存在 n8n 自己的格式裡，難 code review、難寫自動化測試	強——進得了 git，能 review、能寫測試、能接 CI/CD
維運與除錯	看部署方式——雲端版省心但綁計費；self-host 免費但伺服器、備份、升級、安全更新都得自己顧	你完全掌握每一步，但也完全要自己負責，沒有現成介面替你顯示流程跑到哪
規模化與成本	雲端版按「執行次數」計費，跑得越頻繁越貴，量一大帳單會跳	多半是固定的伺服器成本，跑再多次邊際成本趨近於零
客製彈性	中——可在節點裡塞程式當逃生門，但跳不出它的框架	高——完全照你的需求長，沒有框架天花板
廠商鎖定	高——流程綁在 n8n 的格式與生態裡，哪天要搬走是一筆真實的工	低——是你自己的程式碼，搬到哪都行

把這張表濃縮成兩種原型，最好判斷：

該用 n8n 的原型：一條「只是要把現成服務黏起來」的流程——邏輯單純、跑的頻率不高、你（或團隊）裡也沒有人想長期養一套自己的程式。這種情況硬要自己寫，是拿三天去做別人三小時的事。

該自己寫的原型：一套「會一直長大」的東西——分支只會越來越多、重要到需要測試與版本控制、未來要規模化或對成本敏感。這種情況硬塞進 n8n，短期看起來快，但流程圖很快會纏成沒人敢動的義大利麵，到時候搬出來重寫的代價，遠大於一開始就好好寫。

路澄 LUCE 幫客戶做自動化時，第一個問的從來不是「要不要用 n8n」，而是「這條流程未來三個月會變簡單還是變複雜」。答案往哪邊倒，選型就往哪邊走。

n8n 的隱藏成本是什麼？

這一段是信任的關鍵——因為 n8n 真正的成本，幾乎都不在你決定用它的那一刻，而是藏在「上線之後」。

第一，雲端版的執行量計費。 n8n 雲端版是按「執行次數」收費的（見 n8n 官方定價頁）：一條 workflow 從頭跑到尾算一次，不管它中間經過幾個節點。聽起來很合理，但只要你的流程是高頻觸發的——每來一封信跑一次、每筆資料變動跑一次——執行數會比你預期的累積得快，帳單也跟著跳。便宜的是入門價，貴的是你沒算到的觸發頻率。

第二，self-host「免費」的真相。 n8n 的社群版確實可以自架、100% 免費、執行不限量——但你接手的不是一個免費工具，而是一台要自己養的伺服器。Linux 與 Docker 的環境、定期備份、版本升級（而 n8n 的升級時不時會帶來破壞性變更，得有人盯著修）、安全更新——這些全是你的事了。免費的是授權，不是維運。 對沒有人能長期顧這台機器的一人公司來說，這筆隱形人力成本往往比雲端訂閱還貴。

第三，fair-code 不等於完全開源。 n8n 走的是「fair-code」授權，不是無條件的開源。部分企業級功能（像 SSO、稽核日誌）是要付費解鎖的；它的授權模式近年在「個人玩家」與「高用量商用」之間拉出了一條分界，也曾在社群引起討論。如果你把長期商業營運押在它上面，這條分界值得先搞清楚。

第四，廠商鎖定。 你的流程是活在 n8n 的格式與節點生態裡的。用得越深、串得越多，哪天想搬到別的工具或改成自己寫，就是一筆越來越重的遷移成本。

這四件事，跟我們在〈為什麼你的 AI PoC 上不了線〉裡談的是同一個病灶：能 demo 不代表能長期 production。 一個工具好不好用，看的不是它上線那天有多快，而是它在背景安靜跑了三個月之後，還有沒有人罩得住。

可以兩個混用嗎？界線怎麼切？

可以，而且這往往是最務實的答案——前提是界線切對。

實務上最穩的切法是：讓 n8n 當「黏合劑」，讓自己寫的程式當「大腦」。 n8n 擅長的是觸發、串接、把資料從一個地方搬到另一個地方——這些黏合的活交給它。而真正複雜、需要嚴謹測試、會持續演化的核心邏輯，抽出來寫成一個你自己的服務或 API，讓 n8n 去呼叫它。

這樣切的好處是兩邊都做自己最擅長的事：你保留了 n8n 拉起整條流程的速度，又把最不該被鎖死、最需要被測試的那塊核心，握在自己手上。要避開的反模式則剛好相反——把複雜邏輯硬塞進 n8n 的節點裡。當你發現自己在一個節點裡寫了上百行 JavaScript、或是流程圖分支多到要拉很遠才看得完，那就是 n8n 在告訴你：這塊已經越過線了，該抽出來自己寫。

怎麼快速判斷自己該用哪邊？

不想看完整篇也沒關係，用這份清單對一下訊號就好。

偏向用 n8n 的訊號：

• 你要串的都是現成的 SaaS / API，沒太多特殊邏輯。
• 你要的是「這週就看到東西在跑」。
• 你或團隊裡，沒有人能長期維護一套自己的程式。
• 這條流程跑的頻率不高，執行量計費吃得消。

偏向自己寫的訊號：

• 邏輯複雜、分支多，而且未來只會更複雜。
• 這套東西重要到需要版本控制、測試、code review。
• 會高頻觸發或要規模化，執行量計費會失控。
• 你需要完全掌握每一步，不想被綁在別人的格式裡。

對到的訊號落在哪一欄多，答案就往哪邊倒。兩欄都中一些，就回到上一段的「混用」——讓 n8n 黏、讓程式想。

常見問題

完全不會寫程式，可以只靠 n8n 經營自動化嗎？

可以走得比你想像的遠。大量「把現成服務串起來」的自動化，n8n 不寫程式就能搭起來，這正是它的價值。但會遇到天花板：當流程的邏輯變複雜、或你想做嚴謹的測試與版本控制時，純拖拉節點會越來越吃力。務實的做法是先用 n8n 把能跑的先跑起來，等真的撞到牆，再針對那一塊學一點程式、或找人把核心抽出來寫——而不是一開始就因為「不會寫程式」而放棄自動化。

n8n 的 self-host 跟雲端版怎麼選？

看你更缺的是「錢」還是「時間與維運能力」。雲端版省下所有伺服器維運的功夫，但按執行次數計費，高頻流程長期算下來不便宜。self-host 的社群版免費、執行不限量，但你得自己顧伺服器、備份、升級與安全更新——免費的是授權，不是維運。一人公司若沒有人能長期罩這台機器，雲端版省下的時間通常值回票價；反之若你本來就有維運能力、又跑很高頻，self-host 才划算。

n8n 跑久了會遇到什麼坑？

最常見三個：一、雲端版的執行量計費隨著流程觸發頻率悄悄累積，帳單比預期高；二、self-host 的版本升級偶爾帶來破壞性變更，沒人盯著就會某天突然壞掉；三、流程越串越深，對 n8n 格式的廠商鎖定越重，未來要搬走或改寫的成本越大。這三個坑都不是 n8n 不好，而是任何「上線之後沒人負責維運」的自動化都會踩到的縫隙。

已經用 n8n 了，什麼訊號代表該改成自己寫？

幾個明確訊號：你在單一節點裡塞了上百行程式碼；流程圖的分支多到沒人敢動；每次 n8n 升級你都提心吊膽；或者執行量計費已經貴到讓你心痛。出現這些，代表這條流程的複雜度或規模已經越過了 n8n 的舒適區。這時候不一定要整個打掉，更常見的是把最複雜的那塊核心抽出來自己寫，讓 n8n 退回它最擅長的「黏合」角色。

選對邊，比急著開工更省

回到最前面那句判準。n8n 還是自己寫，從來不是「哪個比較好」的問題，而是「你這條流程落在線的哪一邊」的問題。站對邊，n8n 能幫你幾小時拉起一條流程；站錯邊，它會在三個月後變成一團沒人敢動、又搬不走的麻煩。

路澄 LUCE 幫客戶做自動化時，第一步從來不是急著開 n8n，而是先把這條線畫清楚——這條流程未來會變簡單還是變複雜、誰來長期養它、跑多頻繁、值不值得被測試。如果你手邊正好有一條卡在這個選擇上的流程，不確定該用 n8n 黏、還是該好好寫一套，讓路澄 LUCE 先幫你做一次自動化選型診斷，再決定要不要動工。選對邊，往往比急著開工省下更多。

• #n8n
• #no-code-automation
• #workflow-automation