你可能已經打開 n8n 了，但卡在第一個真正的問題：畫面上節點很多，教學也很多，卻不知道自己的流程到底該從哪個 node 開始。
常見情況像這樣：
- 官網表單進來了，你想自動判斷是不是高意圖客戶，但不知道要用
Webhook、Form Trigger還是Manual Trigger。 - 你想把資料丟到 CRM，看到現成節點和
HTTP Request都能做，不知道哪個比較穩。 - 客服訊息有付款、帳號、Bug、功能建議，你知道要分流，卻分不清
If、Switch、Filter的差別。 - API 回來的 JSON 很亂，你不知道該用
Edit Fields (Set)、Code還是Merge整理。 - 看到別人用
AI Agent很炫，但自己接上去後，反而不知道它應該放在流程哪一段。
這篇不是要你背完整節點庫，而是幫你用「任務」反推「該用哪個節點」。讀完後，你應該能自己判斷：資料從哪裡進來、要怎麼整理、要不要判斷、要呼叫哪個系統、上線前還要補哪些保護。
先記一句話：n8n 節點就是工作流程裡的一個步驟。有些節點負責開始，有些負責整理資料，有些負責判斷分流，有些負責呼叫外部服務。你不需要一次學完整個節點庫，先把常用節點分群，就能開始做流程。
如果你還完全不知道 n8n 能做什麼，先看主文：n8n 教學 2026：AI Agent、自動化工作流與實戰案例完整指南。
先看你是哪一種卡關
| 你現在想做的事 | 優先學的節點 | 為什麼 |
|---|---|---|
| 接住官網表單、LINE 事件、付款成功通知 | Webhook、Form Trigger | 先讓資料穩定進到 n8n |
| 把亂七八糟的欄位整理成固定格式 | Edit Fields (Set)、Code | 後面的判斷和 API 才不會吃錯欄位 |
| 判斷名單是不是高意圖、ticket 屬於哪一類 | If、Switch、Filter | 讓流程不只是直線，而能分流 |
| 串 CRM、內部系統、沒有現成 n8n node 的 SaaS | HTTP Request | 只要對方有 API，通常就能串 |
| 大量資料一筆一筆處理 | Loop Over Items、Wait | 避免 rate limit、timeout 或一次爆量 |
| 想加 AI 分類、摘要、草稿 | AI Agent、OpenAI、Call n8n Workflow | 讓 AI 做判斷，但把動作限制在安全邊界 |
| 怕流程失敗沒人知道 | Error Trigger、通知節點 | 正式上線一定要有補救路線 |
n8n 節點可以分成哪幾類？
官方文件把內建節點分成 node types、core nodes、cluster nodes、credentials、community nodes 等類別。新手不用先背分類名，實務上可以先用下面這張表理解。
| 分類 | 白話意思 | 常見節點 |
|---|---|---|
| Trigger | 什麼時候開始跑 | Manual Trigger、Schedule Trigger、Webhook、Form Trigger |
| Data transform | 把資料整理成後面能用的格式 | Edit Fields (Set)、Code、Date & Time、Remove Duplicates |
| Flow logic | 決定資料往哪裡走 | If、Switch、Filter、Merge、Loop Over Items |
| App / API | 和外部服務互動 | HTTP Request、Google Sheets、Gmail、Slack、HubSpot |
| AI | 讓模型摘要、分類、決策或呼叫工具 | AI Agent、OpenAI、Anthropic、Google Gemini |
| Reliability | 讓流程能上線、能排錯 | Error Trigger、Wait、Respond to Webhook、Execution Data |
常用 n8n 節點中英對照
| 英文節點 | 中文理解 | 什麼時候用 |
|---|---|---|
Manual Trigger | 手動開始 | 做測試、教學、第一次設計 workflow 時使用。 |
Schedule Trigger | 定時開始 | 每天報表、每小時同步、固定檢查 API。 |
Webhook | 收外部事件的網址 | 表單送出、付款成功、CRM 事件、GitHub webhook。 |
Form Trigger | n8n 內建表單 | 想快速收資料，但還不想接 Typeform 或自家前端。 |
HTTP Request | 呼叫 API | 串任何有 REST API 的服務，是最萬用的節點。 |
Edit Fields (Set) | 整理欄位 | 把 mail、first_name、content 整理成 email、name、message。 |
If | 二選一判斷 | 高意圖 / 低意圖、有付款 / 沒付款、成功 / 失敗。 |
Switch | 多路分流 | 客服分類：付款、帳號、Bug、功能建議、其他。 |
Filter | 過濾資料 | 只留下符合條件的 item，例如有 email 的名單。 |
Merge | 合併資料 | 把表單資料和 CRM 查詢結果合成同一筆資料。 |
Loop Over Items | 分批處理 | 大量資料、API 有 rate limit、批次寄送或查詢。 |
Wait | 暫停等待 | 等人工審核、等付款結果、等時間到再追蹤。 |
Code | 寫程式補邏輯 | 清複雜 JSON、計分、轉格式、處理陣列。 |
Respond to Webhook | 回覆外部請求 | 讓 n8n 像 API 一樣回傳結果給呼叫方。 |
Error Trigger | 錯誤時啟動 | 任何 workflow 失敗時通知 Slack / Email。 |
AI Agent | AI 代理人 | 讓模型依任務選工具、查資料、產生回答或下一步。 |
新手第一條 workflow 該用哪些節點？
不要一開始就用 20 個節點。第一條 workflow 只要跑通下面這個組合就夠：
| 步驟 | 建議節點 | 目的 |
|---|---|---|
| 1 | Manual Trigger 或 Form Trigger | 先讓資料進來 |
| 2 | Edit Fields (Set) | 統一欄位名稱 |
| 3 | If | 判斷是否符合條件 |
| 4 | Google Sheets 或 HTTP Request | 寫入資料表或送到 API |
| 5 | Slack 或 Send Email | 通知負責人 |
例如官網表單進線：
Form Trigger收到姓名、Email、需求。Edit Fields (Set)把欄位整理成name、email、message。If判斷message是否包含「報價」、「預算」、「合作」。- 高意圖名單寫入 CRM 或 Google Sheets。
- Slack 通知業務優先跟進。
這條流程不炫，但很實用。它能讓你理解 n8n 最核心的資料流：每個節點接收前一步的 item，處理後再把 item 交給下一步。
三個可以直接照抄的節點組合
如果你不是來研究節點，而是想先做出一條能用的流程，可以從下面三個組合開始。
| 場景 | 節點組合 | 解決什麼問題 |
|---|---|---|
| 官網表單進線分級 | Webhook 或 Form Trigger -> Edit Fields -> If -> Google Sheets / CRM -> Slack | 把人工看表單、判斷客戶意圖、通知業務這件事自動化 |
| 客服 ticket 分流 | Webhook -> Edit Fields -> Switch -> Slack / Email -> Google Sheets | 讓付款、帳號、Bug、功能建議自動分到不同負責人 |
| 每日報表同步 | Schedule Trigger -> HTTP Request -> Code 或 Edit Fields -> Google Sheets -> Send Email | 每天固定抓資料、整理欄位、寄報表，不用人工複製貼上 |
第一條 workflow 不要追求完整，先追求「資料真的能從 A 到 B」。能穩定跑，再補 AI、錯誤處理、去重和權限。
什麼時候用 HTTP Request？
HTTP Request 是 n8n 最值得學的節點之一。很多 SaaS 沒有現成節點，或現成節點缺少某個 API 功能，這時候就用 HTTP Request。
常見用法：
- 從 CRM 查客戶資料。
- 把表單資料送到自家後端。
- 呼叫 AI 模型 API。
- 查訂單狀態、物流狀態、付款狀態。
- 串內部系統或第三方資料服務。
設定時先看 API 文件的四件事：method、URL、authentication、body。若文件提供 curl 範例，可以先用它理解 headers 和 body，再轉成 n8n 欄位。正式使用前不要把 token 寫死在 body 或 URL，應該放到 credentials 或環境變數管理。
If、Switch、Filter 怎麼選？
這三個節點都和條件有關，但用途不同。
| 需求 | 選哪個 |
|---|---|
| 只有 true / false 兩條路 | If |
| 有三種以上分類 | Switch |
| 只想讓符合條件的資料往下走 | Filter |
例如「是否高意圖」用 If。客服類型分成付款、帳號、Bug、功能建議，用 Switch。只留下有 email 的名單，用 Filter。
什麼時候才需要 Code node？
Code 很強，但不要太早依賴它。新手常見錯誤是：明明 Edit Fields、If、Switch 做得到，卻全部丟進 Code，結果流程變得很難交接。
適合用 Code 的情境：
- 需要複雜欄位轉換。
- 要計算 lead score、風險分數、排序權重。
- 要處理多層 JSON 或陣列。
- 要把多筆資料拆成多個 item。
- 需要比對、去重、組合輸出格式。
不適合用 Code 的情境：
- 只是改欄位名稱。
- 只是判斷文字是否包含某個詞。
- 只是把資料送到 Google Sheets。
- 團隊裡沒有人能維護 JavaScript 或 Python。
我的建議是：先用視覺化節點做 80%，真的卡住再用 Code 補最後 20%。
AI Agent 節點不要一開始就亂接工具
AI Agent 很吸引人，但它不是第一天就該打開所有權限的節點。正式做法應該是：
- 先用一般節點做出可控 workflow。
- 把查詢訂單、查文件、建立草稿這類操作拆成小工具。
- 讓 Agent 只能呼叫這些工具。
- 高風險動作前加 human review。
例如不要讓 Agent 直接拿資料庫 admin 權限查全部客戶。比較好的方式是做一個 get_customer_order_status 子 workflow，只允許輸入 order_id，再回傳固定 JSON。
如果你想深入這塊，可以看：n8n AI Agent 教學：Tools、Memory、Human Review 實戰。
正式上線前一定要補的節點
Demo 可以只跑 happy path，正式流程不行。只要 workflow 會改資料、寄信、通知客戶或影響營運，就要補下面這些設計。
| 風險 | 建議節點 / 設計 |
|---|---|
| API 失敗沒人知道 | Error Trigger + Slack / Email |
| Webhook 重送造成重複寫入 | Remove Duplicates 或用 event_id 做唯一鍵 |
| 第三方 API rate limit | Loop Over Items + Wait |
| 外部系統需要即時回應 | Respond to Webhook |
| 人工要確認後才寄信 | Wait 或人工審核分支 |
| 需要追查每次結果 | execution log + 外部紀錄 |
常見問題
n8n 節點一定要照官方分類學嗎？
不用。官方分類適合查文件；實作時先用「觸發、整理、判斷、執行、告警」來理解會更快。
我可以只用 n8n 內建節點，不用 API 嗎？
可以，但一旦你要接比較冷門的 SaaS、內部系統或某個特殊功能，通常還是會用到 HTTP Request。
Code node 會不會讓 n8n 變得很工程？
會，所以要節制。能用視覺化節點就先用；Code node 留給複雜資料轉換、計分、陣列處理和例外邏輯。
節點越多代表 workflow 越專業嗎？
不是。好的 workflow 是每一步都能解釋、能測試、能排錯。節點太多但沒命名、沒註解、沒錯誤處理，反而更難維護。
下一步
如果你想把節點真的串起來，下一篇看 n8n Webhook 教學：從表單到 API 串接。如果你還在建立整體概念，回到 n8n 完整教學 hub。