你是否聽過 n8n 很好用，看到很多人用它做 AI 自動化、AI Agent、RAG、CRM 同步，卻還是不太確定：n8n 到底是什麼？可以幫我做什麼？跟 Make、Zapier、ChatGPT 又差在哪裡？
先用白話講，n8n 是一個把不同工具串起來的自動化工作流平台。它可以接住表單、Email、Google Sheets、Notion、CRM、Slack、資料庫和 AI 模型，照你設定的條件整理資料、呼叫 API、通知人，或交給 AI Agent 判斷下一步。
它特別適合處理那些每天都不難、但一直重複做很浪費時間的工作。
例如：
- 官網每天都有詢問表單進來，你要人工判斷誰是高意圖客戶、誰只是問問。
- 客服信箱裡有付款、帳號、Bug、功能建議混在一起，每天都要先分類再派工。
- 每週要從 Google Sheets、CRM、Email、Notion 抓資料，整理成一份固定格式的報表。
- 業務跟進完客戶後，還要手動更新 CRM、通知 Slack、寄下一封信。
- 公司文件散在不同地方，同事一直問重複問題，你想做一個可以查文件但又能留下來源的 AI 助理。
- 你已經會用 ChatGPT，但不想每次都手動複製資料、貼 prompt、再把結果搬回系統。
如果你看到這裡有幾個點頭，n8n 對你就不是「另一個自動化工具」而已。它比較像一個可以把表單、Email、資料庫、CRM、Slack、AI 模型和內部 API 串起來的工作流中控台：前面接住資料，中間整理和判斷，後面自動更新系統或通知人。
這篇會先從你真的用得到的場景開始，不急著把所有節點講完。你會先做出第一條可運行 workflow，再往 AI Agent、RAG、human review、生產環境安全與監控走。
透明說明：本文包含工具推薦與站內延伸閱讀；若未來加入 n8n 聯盟連結，會在連結附近清楚標示。
先確認：你真的需要 n8n 嗎？
不是每一個自動化都要用 n8n。如果你只是想把 Gmail 附件存到雲端硬碟，Zapier 或 Make 會更快上手。n8n 真正有價值的地方，是當你的流程開始變得「有條件、有資料、有風險、有系統串接」：
- 串很多 API，而且每一步都要能 debug。
- 把資料庫、Webhook、CRM、內部系統、AI 模型接在一起。
- 讓 AI Agent 呼叫「可控的工具」，不是把所有權限都交給模型。
- 想自架，或至少希望未來有自架、私有部署、資料控管選項。
- 需要 error handling、重試、稽核紀錄、human-in-the-loop。
我的建議是：內容創作者、SOHO、業務團隊可以先用 Make；技術團隊、B2B SaaS、顧問公司、內部營運自動化，n8n 的長期彈性會比較高。
n8n 是什麼？和一般自動化工具差在哪？
n8n 的基本單位是 workflow。每個 workflow 由多個 node 組成：
| 概念 | 做什麼 | 新手理解方式 |
|---|---|---|
| Trigger | 決定流程何時開始 | 表單送出、Webhook 收到資料、排程到點 |
| Node | 執行某個動作 | 呼叫 API、查表、寄信、整理欄位 |
| Execution | 一次流程執行紀錄 | 可以回頭看哪一步成功、哪一步失敗 |
| Credentials | 儲存 API key / OAuth | 讓節點安全地連外部服務 |
| Expression | 動態取用前面節點資料 | 把表單欄位帶進 Email 或 API body |
| Workflow as tool | 把子流程包成工具 | 讓 AI Agent 只呼叫被允許的流程 |
一般 no-code 自動化工具通常強在「快速串 SaaS」。n8n 則更像工程化的工作流平台：你可以用 Code node 補邏輯、用 HTTP Request 接任意 API、用資料庫保存狀態、用 error workflow 做告警，最後再把流程交給 AI Agent 作為 tool。
第一次看 n8n：它到底在幹嘛？
如果你完全沒用過 n8n，可以先不要想「AI Agent」或「自架」。先把 n8n 想成一條自動化產線：前面有入口，中間有加工站，最後有出口。
一條最基本的 n8n workflow 通常長這樣：
| 流程階段 | 白話意思 | 常見節點 |
|---|---|---|
| 觸發 | 什麼事情發生時開始跑 | Manual Trigger、Schedule Trigger、Webhook、Form Trigger |
| 取得資料 | 把表單、API、資料表或檔案內容拿進來 | HTTP Request、Google Sheets、Gmail、Postgres / MySQL 等資料庫節點 |
| 整理資料 | 把欄位改成後面看得懂的格式 | Edit Fields (Set)、Code、Date & Time |
| 判斷分流 | 根據條件決定走哪條路 | If、Switch、Filter |
| 執行動作 | 寄信、更新 CRM、寫入資料表、通知團隊 | Send Email、Slack、Google Sheets、HubSpot / Pipedrive 等 CRM 節點、HTTP Request |
| 等待或審核 | 等人確認、等時間到、等外部回覆 | Wait、Respond to Webhook、人工審核節點設計 |
| 紀錄與告警 | 失敗時通知人，成功時留下紀錄 | Error Trigger、Execution Data、Slack、Email |
舉一個網站詢問表單的例子：
Form Trigger收到訪客填的姓名、Email、需求內容。Edit Fields (Set)把欄位整理成name、email、message、source。If判斷訊息裡是否有「報價」、「合作」、「預算」。- 高意圖名單走
CRM或Google Sheets，一般問題走Email或客服系統。 Slack通知業務：「這筆要優先跟進」。- 如果中間 API 失敗，
Error Trigger或錯誤分支通知負責人。
所以 n8n 不是叫 AI 自己亂做事，而是把「人本來會重複做的步驟」拆成一格一格可測試、可修改、可追蹤的節點。你越能把流程講成「什麼進來、怎麼整理、什麼條件、送去哪裡」，就越容易用 n8n 做出穩的自動化。
常用 n8n 節點中英對照表
下面這張表不追求列完整節點庫，而是先整理新手最常看到、也最容易搞混的節點。英文名稱用 n8n 介面常見命名，中文名稱是方便理解的翻譯。
| 英文節點名稱 | 中文理解 | 用途 | 怎麼用 |
|---|---|---|---|
Manual Trigger | 手動觸發 | 測試 workflow，不用等真實事件發生。 | 放在流程第一格，按 Execute workflow 看後面每個節點輸出；正式上線時通常會換成表單、Webhook 或排程觸發。 |
Schedule Trigger | 定時觸發 | 每天、每週、每小時自動跑一次流程。 | 設定執行頻率、時間與時區，用在每日報表、定期同步、固定檢查庫存或監控 API。 |
Webhook | 收外部事件的網址 | 讓外部服務主動丟資料進 n8n，例如表單、付款、CRM 事件、系統 callback。 | 複製 n8n 給你的 Test URL 測試資料格式；發布後改用 Production URL。記得設定 HTTP method、path、驗證方式和回傳內容。 |
Form Trigger / n8n Form Trigger | n8n 內建表單入口 | 不想另外接 Typeform、Tally、Google Form 時，可以直接用 n8n 收表單。 | 在節點裡設定欄位，例如姓名、Email、需求；提交後每筆表單會變成 workflow 的輸入資料。 |
HTTP Request | 呼叫 API | 連接任何有 REST API 的服務，是 n8n 最常用也最重要的節點之一。 | 填 method、URL、headers、query、body、authentication；如果 API 文件有 curl 範例，也可以匯入後再微調。常用在查 CRM、打模型 API、送資料到內部系統。 |
Edit Fields (Set) | 整理或新增欄位 | 把前面亂七八糟的資料整理成後面節點需要的格式。 | 用 Manual Mapping 拖拉欄位，或用 expression 組出新欄位；常見做法是把 first_name、mail、content 統一成 name、email、message。 |
If | 二選一條件判斷 | 根據條件把資料分成 true / false 兩條路。 | 設定欄位、比較方式和值，例如 message contains 報價；高意圖走業務通知，低意圖走一般回覆。 |
Switch | 多條路分流 | 條件不只兩種時使用，比 If 更適合分類。 | 建立多個 routing rules，例如客服類型是付款、帳號、Bug、功能建議，就分別送到不同 Slack channel 或 ticket queue。 |
Filter | 過濾資料 | 只讓符合條件的 item 往下走。 | 用在資料清理，例如只處理有 Email 的名單、只留下金額大於某個數字的訂單、跳過缺欄位資料。 |
Merge | 合併多路資料 | 把兩個以上來源的資料合在一起。 | 例如一邊是表單資料，一邊是 CRM 查詢結果，用 email 或 customer_id 合併；常用來補齊客戶資料或比對重複紀錄。 |
Loop Over Items (Split in Batches) | 分批處理 | 一次資料太多，或 API 有速率限制時，把資料分批慢慢跑。 | 設定 batch size，例如一次處理 10 筆；每批跑完再回到迴圈，適合大量寄送、批次查詢、避免打爆 API。 |
Wait | 暫停等待 | 流程跑到一半先停住，等時間到、等表單回覆或等外部 webhook 再繼續。 | 用在人工審核、延遲追蹤信、等待付款確認；可以等固定時間，也可以產生 resume URL 讓外部事件喚醒流程。 |
Code | 寫程式處理資料 | 內建節點做不到時，用 JavaScript 或 Python 補自訂邏輯。 | 用來清理複雜 JSON、計算分數、轉換格式、處理陣列；能不用就先不用，但遇到複雜資料轉換時很有用。 |
Date & Time | 日期時間處理 | 轉換時區、格式化日期、計算時間差。 | 用在會議提醒、到期日、排程報表、SLA 計算；避免直接用文字日期硬比對。 |
Remove Duplicates | 去除重複資料 | 避免同一個人、同一張訂單或同一筆事件被重複處理。 | 指定用 email、order_id、ticket_id 等欄位去重；常放在寫入 CRM、寄信或更新資料庫前。 |
Respond to Webhook | 回覆外部請求 | 當 n8n 被當成 API endpoint 時，決定要回傳什麼給呼叫方。 | 搭配 Webhook 使用；可以回傳成功訊息、查詢結果、錯誤原因，讓外部系統知道流程處理結果。 |
Error Trigger | 錯誤觸發 | workflow 失敗時啟動另一條錯誤處理流程。 | 建立一條專門收錯誤的 workflow，通知 Slack / Email，並附上 workflow 名稱、execution URL、錯誤訊息。 |
AI Agent | AI 代理人 | 讓模型根據任務選擇工具、查資料、產生回答或決定下一步。 | 不要一開始就給太多權限；先把查詢、寫入、寄信做成受控 workflow，再讓 Agent 只能呼叫這些工具。 |
OpenAI / Anthropic / Google Gemini | 語言模型節點 | 做摘要、分類、改寫、抽取 JSON、草稿生成。 | 給清楚輸入、輸出格式和限制；正式流程建議要求 JSON，再用 If 或 Switch 接下一步，不要直接相信自由文字。 |
Google Sheets | 試算表讀寫 | 最常見的輕量資料庫替代品。 | 用來新增名單、更新狀態、查詢既有資料；適合早期驗證，但資料量大或權限複雜時要改資料庫或 CRM。 |
Gmail / Send Email | 收信或寄信 | 做通知、草稿、客服回覆、銷售跟進。 | 新手先用寄給內部團隊的通知信，不要直接自動寄給客戶；正式上線前加人工審核與寄送限制。 |
Slack / Microsoft Teams | 團隊通知 | 把需要人處理的結果推到團隊溝通工具。 | 設計訊息格式，放入重點欄位、連結、下一步按鈕或負責人；避免把所有執行紀錄都丟進同一個頻道。 |
新手可以先記一個組合：Trigger 負責開始，Edit Fields 負責整理，If / Switch 負責判斷，HTTP Request / SaaS 節點負責做事，Slack / Email 負責通知人，Error Trigger 負責出事時不要安靜失敗。
實務上，最好的第一條流程不是「做一個 AI Agent」，而是「把一個你每天都會手動做的五步驟流程變成節點」：收到資料、整理欄位、判斷條件、更新系統、通知負責人。這條流程跑穩之後，再把 AI 放進分類、摘要、草稿或文件查詢的位置。
Cloud 還是自架？先不要一開始就硬上 Docker
n8n 可以用官方 Cloud，也可以自架。很多新手第一次看到這兩個選項會卡住，因為它們聽起來都像「使用 n8n」，但實際上差很多。
先用白話講：
- n8n Cloud：你直接用 n8n 官方幫你架好的服務。你只要註冊、登入、開始做 workflow；主機、更新、基本維運由 n8n 官方處理。
- 自架 n8n：你自己準備一台伺服器，自己把 n8n 裝上去。你可以更自由地控制資料、網路、資料庫、外部套件和內部系統連線，但也要自己負責維護。
可以把 Cloud 想成「租一間已經裝潢好的辦公室」，自架像是「自己租空間、拉電、裝網路、買設備」。前者快、穩、省麻煩；後者自由、可控，但你要會處理壞掉時的問題。
真正的差別不是哪個比較高級，而是責任怎麼分：
| 問題 | 用 n8n Cloud | 自架 n8n |
|---|---|---|
| 誰負責安裝與更新？ | n8n 官方 | 你或你的工程團隊 |
| 壞掉時誰要排查？ | 先看官方服務與支援 | 你要看主機、資料庫、log、網路 |
| 資料放在哪裡？ | 依官方方案與地區設定 | 你選的主機、資料庫與備份位置 |
| 能不能接內部系統？ | 通常要看網路與安全限制 | 比較容易接公司內網或私有 API |
| 適合什麼階段？ | 驗證流程、快速上手、非工程團隊 | 正式內部系統、資料敏感、需要高度客製 |
所以新手不要一開始就被「自架比較省錢」吸引。自架不是免費，它只是把費用從月費轉成主機、備份、更新、監控、安全與人力。SERP 上很多 hosting 文章會直接比較 VPS，但新手其實不必第一天就自架。
| 選項 | 適合誰 | 優點 | 代價 |
|---|---|---|---|
| n8n Cloud | 剛開始驗證流程、非工程團隊 | 省維運、更新快、開箱就能用 | 資料與方案限制需看官方條款 |
| VPS + Docker | 技術團隊、小型內部工具 | 成本可控、彈性高、容易接內網服務 | 要管備份、更新、憑證、監控 |
| Self-host + Postgres + Queue | 高流量或正式營運 | 執行穩定、可擴充、可分離 worker | 需要 DevOps 能力 |
| Enterprise / 私有部署 | 金融、醫療、大企業 | 權限、稽核、SLA、合規需求較完整 | 採購與導入週期較長 |
我的導入建議：
- 用 Cloud 或本機先做 proof of concept。
- 確認流程真的省時間，再決定是否自架。
- 只要開始處理個資、客戶資料、金流、內部機密，就要把 credentials、execution log、備份、權限納入正式規格。
第一個 n8n workflow：從可運行開始
官方入門教學會帶你建立第一個 workflow：先加 trigger，再加外部資料節點，接著用 IF 做條件判斷，最後看每個節點的輸出。你不必一開始就做 AI Agent；先能看懂資料怎麼在節點之間流動，比什麼都重要。
這是一個適合新手的練習流程：
- 建立
Manual Trigger或Form Trigger。 - 加一個
Set/Edit Fields節點，定義name、email、company、message。 - 加一個
IF節點，判斷message是否包含「報價」、「合作」、「預算」。 - 加一個
HTTP Request或 Email 節點，把高意圖名單送到指定系統。 - 加一個通知節點，把結果送給團隊。
- 執行一次，打開 execution 看每一步輸入與輸出。
這個練習會讓你熟悉三件事：
- n8n 的資料是一筆一筆 item 往下流。
- 後面的節點可以引用前面節點的欄位。
- 每個節點都應該能單獨測試，而不是整條 workflow 一次賭運氣。
可下載 n8n workflow 範本：先匯入跑一次
只看文字還是抽象，所以我準備了三個 starter workflow JSON。這些範本刻意使用 Manual Trigger、Code、No Operation 和 sticky note，不會直接連你的正式 CRM、Email、Slack 或資料庫；你可以先安全匯入、跑一次、看懂每個節點輸出，再把 placeholder 換成正式節點。
| 範本 | 適合場景 | 下載 |
|---|---|---|
| 名單分級與跟進 | 官網表單、諮詢表單、B2B 業務進線 | 下載 lead triage workflow JSON |
| 客服 ticket 分流 | 信箱、表單、客服系統進線分類 | 下載 ticket routing workflow JSON |
| RAG 文件匯入 | 把 FAQ、SOP、文件內容切塊後送向量資料庫 | 下載 RAG intake workflow JSON |
匯入方式：
- 下載其中一個 JSON 檔。
- 打開 n8n，建立或進入一個空白 workflow。
- 點右上角三個點，選擇
Import from File。 - 匯入 JSON 後，先不要接正式 credentials。
- 點
Manual Trigger執行一次，逐一打開後面節點，看json欄位怎麼變化。 - 確認資料流之後，再把
Replace with ...的No Operationplaceholder 換成你自己的 CRM、Slack、Email、Google Sheets、向量資料庫或內部 API。
如果你想用 URL 匯入，也可以複製上面下載連結；n8n 官方文件也列出 Download、Import from URL、Import from File 三種匯入匯出方式。
上線前請記住三件事：
- 從範本匯入後，先用假資料測試，不要第一步就接客戶資料。
- 替換
HTTP Request、Email、CRM、資料庫節點時，逐一檢查 credentials 權限。 - 任何會寄信、刪資料、改 CRM、建立訂單的動作，都先加人工審核或只產生草稿。
n8n AI Agent 怎麼運作？
n8n 的 AI Agent node 不是單一魔法節點。它通常會搭配這些元件：
| 元件 | 用途 | 實務提醒 |
|---|---|---|
| Chat Model | 決定使用哪個語言模型 | 看 tool calling、context、成本與穩定度 |
| Memory | 保存對話上下文 | 不要把敏感資料永久保存到不該保存的地方 |
| Tools | 讓 Agent 可以做事 | 工具越少越安全，權限越窄越好 |
| Output Parser | 限制輸出格式 | 生產流程盡量要求 JSON schema |
| Human Review | 人工批准高風險動作 | 寄信、刪資料、改 CRM 前最好保留審核 |
新手最容易犯的錯，是把 HTTP Request、資料庫、Email、CRM 全部直接開給 Agent。比較穩的做法是：先把可預期的操作做成獨立 workflow，再用 Call n8n Workflow 讓 Agent 呼叫。這叫 workflow as tool。
為什麼 workflow as tool 比直接給 API 安全？
假設 Agent 要查詢客戶訂單。你可以給它一個資料庫權限，讓它自己寫 SQL；也可以做一個 get_customer_order_status workflow，只允許輸入 order_id，然後回傳固定 JSON。
第二種比較適合正式環境，原因是：
- 你可以限制輸入欄位，避免亂查資料。
- 你可以在子流程內做權限檢查。
- 你可以統一處理錯誤與重試。
- 你可以留下清楚 execution log。
- 你可以替換內部 API，而不必改 Agent prompt。
AI Agent 最好只負責「判斷要不要呼叫哪個工具」，不要負責「自己決定怎麼碰核心資料」。
實戰案例一：名單分級與自動回覆
這是最適合做 n8n 聯盟行銷教學的案例，因為它有清楚商業價值：進線變多時，團隊不想每封表單都人工判讀，但又不敢讓 AI 直接寄出不受控的信。
流程設計
| 步驟 | n8n 節點 | 目的 |
|---|---|---|
| 1 | Form Trigger / Webhook | 接收官網表單、Typeform、Tally 或自家前端資料 |
| 2 | Edit Fields / Code | 統一欄位名稱，清掉空白、全形符號、無效 email |
| 3 | Database / Google Sheets / CRM lookup | 查詢是否已存在同一個 email 或公司 |
| 4 | AI Agent / Basic LLM Chain | 判斷需求類型、預算線索、急迫度、下一步 |
| 5 | IF | 如果低信心、高風險或高價值，送人工審核 |
| 6 | Email Draft / CRM Update | 產生回覆草稿，更新 CRM，通知業務 |
建議資料欄位
| 欄位 | 範例 | 為什麼需要 |
|---|---|---|
lead_name | 王先生 | 回覆草稿要用 |
email | [email protected] | 去重、回覆、CRM 主鍵 |
company | Mason AI Lab | 判斷 B2B / 個人 |
message | 想導入 AI 客服 | AI 分類的主要內容 |
source_url | /contact/ | 分析哪個頁面帶來名單 |
utm_campaign | n8n-guide | 追蹤內容轉換 |
ai_score | 82 | 排序與分派 |
confidence | 0.76 | 決定是否人工審核 |
AI 分級 prompt 範本
把 prompt 寫得像營運規格，不要只寫「幫我分析這個客戶」。你可以用這種格式：
你是 B2B 業務助理，負責判斷官網進線的需求類型與優先順序。
請只根據輸入資料判斷，不要編造客戶沒有提供的資訊。
輸入欄位：
- name
- company
- email
- message
- source_url
- utm_campaign
請回傳 JSON：
{
"category": "consulting | implementation | course | support | other",
"urgency": "low | medium | high",
"lead_score": 0-100,
"confidence": 0-1,
"reason": "不超過 40 字",
"next_action": "reply | assign_sales | ask_more_info | ignore",
"draft_reply": "繁體中文，禮貌、精簡，不承諾價格"
}
如果 message 涉及個資、法律、醫療、金流或客訴，confidence 不得高於 0.7，next_action 必須是 assign_sales。人工審核規則
正式上線時，至少把這些狀況送人工確認：
confidence < 0.75lead_score > 85- 訊息包含法律、醫療、金流、個資、客訴。
- AI 草稿中出現價格、折扣、交期、保證效果。
- 客戶已存在 CRM，且最近 30 天有人跟進。
這樣 AI 可以幫你省掉初步整理，但不會擅自對高價值客戶做錯承諾。
實戰案例二：RAG 文件問答 Agent
第二個值得寫進教學的案例，是把 n8n 做成 RAG 資料管線。很多人會直接用聊天機器人丟 PDF，但正式團隊需要的是可更新、可稽核、可控制權限的知識庫。
資料匯入 workflow
- 用 Schedule Trigger 每天或每小時執行。
- 從 Google Drive、Notion、內部 API、S3 或資料庫抓取文件清單。
- 比對
updated_at或 hash，只處理有變更的文件。 - 將文件切成 chunk，保留
source_id、source_url、owner、permission_group。 - 產生 embedding，寫入 vector database。
- 寫入同步紀錄，方便查詢哪份文件最後一次成功更新。
問答 workflow
- Chat Trigger 或 Webhook 收到問題。
- 先檢查使用者權限與查詢範圍。
- Retriever tool 取回相關 chunk。
- AI Agent 只根據取回資料回答。
- Output Parser 要求回答包含
answer、sources、confidence。 - 如果信心不足，回覆「找不到足夠資料」，不要硬答。
RAG 的重點不是回答很會寫，而是回答可以追來源。沒有來源、沒有版本、沒有權限邊界的 RAG，越像正式系統越危險。
實戰案例三：客服 ticket / GitHub issue 分流
如果你做 SaaS、軟體服務或內容產品，n8n 也適合用來處理 ticket：
- Webhook 接收客服表單、Intercom、Zendesk、GitHub issue。
- AI 判斷類型：bug、帳號、付款、功能建議、教學需求。
- 自動補上 reproduction steps、環境資訊、相關文件連結。
- 高風險 ticket 送人工；低風險 ticket 產生回覆草稿。
- 如果是工程問題，建立 GitHub issue 並加上 label。
這個案例的關鍵是不要讓 AI 直接關閉 ticket。AI 可以摘要、分類、補資料，但最後是否結案應該由人或明確規則決定。
多數入門文少寫的段落：生產化檢查清單
能跑一次的 workflow 不等於能上線。只要它會影響客戶、資料、金錢或內部決策，就要檢查下面這些項目。
| 檢查項 | 為什麼重要 | n8n 做法 |
|---|---|---|
| Idempotency | 避免 webhook 重送造成重複寫入 | 用 email、order_id、event_id 當唯一鍵 |
| Retry | API 短暫失敗不該讓流程全毀 | 節點重試、等待後重送、分支處理 |
| Error workflow | 失敗要有人知道 | 建立全站錯誤通知 workflow |
| Rate limit | 避免打爆第三方 API | 分批、Wait、Queue、節流 |
| Versioning | 改流程要可回溯 | 複製 workflow 測試後再替換 |
| Observability | 問題要能追 | execution log、外部 log、告警 |
| Secrets | API key 不該散落在節點文字 | 使用 credentials，不把 key 寫進 prompt |
| Cost guardrail | AI 成本會隨流量放大 | 記錄 token、限制重試、控制長 context |
真正專業的 n8n 教學，應該教讀者如何避免流程失控，而不是只展示「看，AI 自動完成了」。
安全與權限：AI workflow 最容易出事的地方
Agentic workflow 的風險通常不是模型突然變壞，而是模型讀到不可信輸入後，照著惡意指令去呼叫工具。只要你的 workflow 會讀取外部表單、Email、網頁內容、文件、ticket，就要把那些內容視為不可信資料。
建議規則：
- 外部輸入永遠不能直接變成系統指令。
- Tool 描述要短而明確，不要讓 Agent 猜權限。
- 刪除、付款、改權限、寄正式信件，必須 human review。
- credentials 用最小權限，不要拿個人管理員 token。
- prompt 不要包含 API key、內部密碼、無必要個資。
- execution log 如果含個資，要設定保存策略與可存取人員。
- 從網路下載的 n8n template，不要直接接上正式 credentials。
特別是 n8n template 很方便，但也容易讓人忘記檢查每個節點到底做了什麼。正式使用前要逐一檢查 HTTP Request、Code node、外部 URL、credentials 權限與輸出目的地。
n8n、Make、Zapier 怎麼選？
| 需求 | 優先考慮 |
|---|---|
| 非技術人員快速串 SaaS | Zapier |
| 視覺化流程、行銷營運、資料格式轉換 | Make |
| 自架、複雜 API、資料庫、工程化 workflow | n8n |
| AI Agent + workflow as tool | n8n |
| 大量模板、最少維運 | Zapier / Make |
| 需要 debug、分支、程式補邏輯 | n8n / Make |
簡單說：Zapier 最容易，Make 最平衡，n8n 最適合技術型自動化。如果你接下來要做聯盟行銷文章，建議這篇 n8n 教學主打「工程化與 AI Agent」，Make 教學主打「營運與 no-code 速度」，比較文則幫讀者做最後決策。
依你的需求，下一篇該看哪裡？
這篇是 n8n 入門與 AI workflow 的 hub。如果你已經知道自己卡在哪裡，可以直接往下面幾個方向走：
| 你的問題 | 建議下一步 |
|---|---|
| 還不知道 Trigger、Webhook、HTTP Request、IF、Code 怎麼選 | 看 n8n 節點大全 |
| 要接表單、API、外部事件或 LINE / CRM 進線 | 看 n8n Webhook 教學 |
| 要做 AI Agent、Tools、Memory、人工作業審核 | 看 n8n AI Agent 實戰 |
| 要決定 Cloud、自架、Docker、VPS、Queue mode | 看 n8n 自架教學 |
| 還在比較 n8n、Make、Zapier | 看 AI 自動化工具比較 |
| 想知道 Make 是否比較適合營運團隊 | 看 Make AI Agents 教學 |
| 想先用最簡單方式串 SaaS | 看 Zapier Agents 教學 |
| 想理解 workflow 這個概念 | 看 AI 工作流完全指南 |
| 要把 agent 放進正式環境 | 看 AI Agent 生產化部署指南 |
| 公司要做權限、稽核、治理 | 看 企業 AI Agent 檢查清單 |
30 天導入路線圖
第 1 週：找出值得自動化的流程
不要從工具開始，先列出每週重複發生的工作：
- 表單進線整理
- 客服 ticket 分類
- 會議記錄摘要
- 報表更新
- CRM 欄位補齊
- 內容發布通知
挑一個「頻率高、風險低、輸入格式穩定」的流程當第一個 n8n 專案。
第 2 週：做出最小可用 workflow
先不要加 AI。用 Trigger、Edit Fields、IF、HTTP Request、通知節點做出可運行版本。每個節點都要能解釋：
- 這一步吃什麼資料？
- 這一步產生什麼資料？
- 失敗會怎樣？
- 是否會改動外部系統？
第 3 週：加入 AI 分類或草稿
把 AI 放在「判斷、摘要、分類、草稿」的位置。不要一開始就讓 AI 做不可逆動作。輸出盡量要求 JSON，再用 IF 節點接下一步。
第 4 週：補上上線條件
上線前檢查：
- 是否有 error workflow？
- 是否有人工審核條件？
- 是否能避免重複寫入？
- credentials 是否最小權限？
- 是否能追 execution？
- 是否有成本上限或流量限制？
n8n 教學常見問題
n8n 適合完全不會寫程式的人嗎？
可以入門，但如果你要做複雜 API、資料庫、AI Agent 或自架，會一點 JavaScript、JSON、HTTP 概念會很有幫助。完全 no-code 團隊可以先用 Make，等流程變複雜再評估 n8n。
n8n Cloud 和自架哪個比較好？
驗證流程時先用 Cloud 比較快；資料敏感、需要內網、想控制成本或有工程維運能力時，再考慮自架。自架不是免費，還要算主機、備份、更新、監控與人力。
n8n AI Agent 可以直接取代客服或業務嗎？
不建議直接取代。比較穩的做法是讓它整理資料、分級、摘要、產生草稿，再由人確認高風險或高價值案件。AI 做助理，人做承諾與決策。
n8n 做 RAG 一定要向量資料庫嗎？
如果文件少，可以先用簡單搜尋或固定資料源；文件量變大、需要語意搜尋、需要持續更新時，再導入 vector database。重點是權限、來源與版本，不只是能不能回答。
我應該先寫 n8n 教學還是 n8n vs Make 比較文？
先寫 n8n 詳細教學是對的，因為它能承接搜尋「n8n 教學」、「n8n AI Agent」、「n8n workflow」的人。接著再寫 Make 教學，最後用 n8n vs Make 比較文把兩邊流量導到決策頁。
下一步怎麼做？
如果你只是想快速體驗，今天就做一條「表單進線 → AI 分級 → 人工確認 → CRM 更新」的 workflow。這條流程夠小、夠實用，也很容易看出 n8n 的價值。
如果你是要把 n8n 當正式系統，請不要只問「能不能自動化」。你真正要問的是：
- 失敗時誰會知道？
- AI 什麼時候不能自己決定？
- 哪些工具需要最小權限？
- 哪些資料不能進 prompt？
- 哪些輸出必須保留來源與紀錄？
能回答這些問題，n8n 才不是玩具，而會變成你網站和業務流程裡可以長期累積的自動化基礎建設。
參考資料與延伸閱讀
- n8n first workflow tutorial
- n8n workflows documentation
- n8n export and import workflows
- n8n node types documentation
- n8n core nodes library
- n8n HTTP Request node
- n8n Webhook node
- n8n AI Agent node documentation
- n8n Tools AI Agent node
- n8n Advanced AI documentation
- n8n Advanced AI examples
- n8n hosting documentation
- Chat with a Google Sheet using AI
- n8n 節點大全：常用 node 中英對照、用途與新手選擇指南
- n8n Webhook 教學：從表單進線到 API 串接的完整實戰
- n8n AI Agent 教學：Tools、Memory、Human Review 實戰設計
- n8n 自架教學：Cloud、Docker、VPS、Postgres、Queue mode 怎麼選
- AI 自動化工具比較：n8n、Make、Zapier 怎麼選