在 n8n 的自動化工作流中，許多人習慣使用 ChatGPT 的 AI 模型。然而，隨著 Google Gemini 系列模型的強勢崛起（尤其是具備免費額度的優勢），越來越多開發者與行銷人開始轉向使用 Gemini 來節省成本並維持高效的運算能力。 本文將帶您手把手實戰，從申請 Gemini API 密鑰開始，完整解析在 n8n 中串接 Gemini 的兩種核心做法：基礎節點搭配 JavaScript 解析，以及免寫程式的 AI Agent 結構化輸出。 如何快速取得 Google Gemini API 密鑰？要讓 n8n 成功呼叫 Gemini，我們首先需要前往開發者後台申請 API Key。 進入開發者平台：前往 Google AI Studio。 尋找申請入口：在左側選單點擊 Get API key。 建立密鑰：點選 Create API key，系統會要求您選擇或建立一個 Google Cloud 專案（Project）。如果您之前尚未建立過，可以點擊 Create project 來創建一個新專案。 選擇計費方案： 若您有綁定信用卡並啟用了付費帳單，系統可能會預設給予 Tier 1 (Postpay) 權限，這在需要呼叫「生成圖片」等進階模型時非常有用。 若您想完全免費使用，請確保專案的計費狀態設定為 Free tier，這對於一般的文本處理與自動化任務已經非常夠用。 複製密鑰：成功生成後，將這串 API Key 複製下來，準備貼到 n8n 的憑證（Credentials）設定中。 實戰方法一：透過「Message a Model」節點與 JS 解析 JSON在 n8n 中，最直覺的呼叫方式是使用原生的 Google Gemini 節點（Message a Model 操作）。但在實際應用場景中，我們通常會要求 AI 輸出特定的 JSON 格式（例如：分類、摘要、關鍵字），以便後續串接 LINE Bot 或寫入資料庫。 步驟與痛點解析 建立 Credentials：在 Message a Model 節點中，新增 Google Gemini(PaLM) API account，將剛剛複製的 API Key 貼入並儲存。 設定 Prompt 與 System Message：在 Node 設定中，您可以要求它輸出 JSON，並開啟 Output Content as JSON 選項。 痛點（為何需要 Code 節點）：即使勾選了輸出 JSON，Gemini 原生節點回傳的資料結構往往被包裝在一大包 JSON 陣列內（無法像 ChatGPT 節點那樣直接完美對應輸出規格）。 JavaScript 解析解法：為了解決這個問題，我們必須在後面加上一個 Code 節點，透過 JavaScript 將純文字轉換並萃取出我們需要的欄位。 Code 節點解析範例： 12345678910111213141516const raw = $json.content?.parts?.[0]?.text ?? '';let parsed;try { parsed = JSON.parse(raw);} catch (error) { parsed = { summary: '', category: '其他', keywords:[], language: 'zh-TW' };}return [{ json: parsed }]; 透過上述程式碼，我們才能確保後續的 HTTP Request 節點（例如推播 LINE 訊息）能正確讀取到 summary、category 與 keywords 等變數。這對於不熟悉程式碼的用戶來說，門檻相對較高。 實戰方法二：使用 AI Agent 輕鬆達成結構化輸出（專家推薦）為了避開繁瑣的程式碼解析，強烈建議使用 n8n 的 AI Agent 架構。透過「Agent + Model + Output Parser」的黃金三角，您可以讓系統自動將 Gemini 的輸出鎖定在嚴格的 JSON 規格內。 完美輸出的配置步驟： 加入 AI Agent 節點：在畫布中新增 AI Agent，並將輸入源連接至前置節點。 **連接語言模型 (Language Model)**：在 Agent 的 Model 輸入端，掛載 Google Gemini Chat Model 節點，並選定模型（如 gemini-2.5-flash）。 **強制結構化輸出 (Output Parser)**： 開啟 Agent 節點內的 Require Specific Output Format。 在 Parser 輸入端掛載 Structured Output Parser 節點。 在 Parser 內直接定義您期待的 JSON Schema（如下方範例）。 JSON Schema 定義範例： 1234567891011121314151617{ "type": "object", "properties": { "summary": { "type": "string" }, "category": { "type": "string", "enum":["AI工具", "程式開發", "商業", "教育", "其他"] }, "keywords": { "type": "array", "items": { "type": "string" } }, "language": { "type": "string" } }, "required":["summary", "category", "keywords", "language"], "additionalProperties": false} 使用 AI Agent 搭配 Structured Output Parser 的最大優勢在於：完全免寫任何一行解析用的 JavaScript 程式碼！系統會嚴格逼迫 Gemini 依照您提供的 Schema 回傳乾淨、格式化好的 JSON，極大地提升了工作流的穩定性與開發效率。 附錄：完整 n8n 工作流 JSON您可以直接複製以下 JSON 匯入您的 n8n 畫布中進行測試： { "nodes":[ { "parameters": { "promptType": "define", "text": "=請讀取以下內容，輸出摘要、主題分類、3 個關鍵字。\n\n內容：\n{{$json.input_text}}", "hasOutputParser": true, "options": { "systemMessage": "你是資料整理助手。\n\n規則：\n1. 使用繁體中文。\n2. 不要捏造未提供的資訊。\n3. 請只輸出 JSON。\n4. 欄位必須包含 summary、category、language。\n5. 若資訊不足，也必須輸出合法 JSON。" } }, "type": "@n8n/n8n-nodes-langchain.agent", "typeVersion": 3.1, "position":[352, -352], "name": "AI Agent" }, { "parameters": { "options": {} }, "type": "@n8n/n8n-nodes-langchain.lmChatGoogleGemini", "typeVersion": 1, "position":[288, -144], "name": "Google Gemini Chat Model" }, { "parameters": { "schemaType": "manual", "inputSchema": "{\n \"type\": \"object\",\n \"properties\": {\n \"summary\": { \"type\": \"string\" },\n \"category\": {\n \"type\": \"string\",\n \"enum\":[\"AI工具\", \"程式開發\", \"商業\", \"教育\", \"其他\"]\n },\n \"keywords\": {\n \"type\": \"array\",\n \"items\": { \"type\": \"string\" }\n },\n \"language\": { \"type\": \"string\" }\n },\n \"required\":[\"summary\", \"category\", \"keywords\", \"language\"],\n \"additionalProperties\": false\n}" }, "type": "@n8n/n8n-nodes-langchain.outputParserStructured", "typeVersion": 1.3, "position":[544, -128], "name": "Structured Output Parser" } ], "connections": { "Google Gemini Chat Model": { "ai_languageModel": [[{"node": "AI Agent","type": "ai_languageModel","index": 0}]] }, "Structured Output Parser": { "ai_outputParser": [[{"node": "AI Agent","type": "ai_outputParser","index": 0}]] } } } 常見問答 (FAQ)Q：為何在 n8n 中選擇使用 Gemini 而不用 ChatGPT？A：主要優勢在於成本與免費額度。Google AI Studio 提供了非常慷慨的 Free tier（免費層），對於剛開始建置自動化工作流、或需求量在中小型範圍的用戶來說，可以大幅降低 API 的呼叫成本，同時 Gemini 2.5 Flash 處理速度極快，非常適合自動化場景。 Q：為什麼使用基礎的「Message a Model」節點還需要額外寫程式碼？A：因為基礎的 LLM 節點雖然能設定輸出 JSON，但往往會包裝在複雜的結構層級中，無法直接無縫對接下一個節點的變數欄位。透過加入 JavaScript Code 節點進行 JSON.parse() 解析，才能精準拆解出所需的鍵值（Keys），讓後續推播或寫入資料庫的動作不出錯。 Q：如果不擅長寫程式，有什麼替代方案嗎？A：強烈建議採用本文示範的 AI Agent + Structured Output Parser 方法。這種架構屬於「宣告式」操作，您只需要在介面上填寫 JSON 格式規範（Schema），n8n 與 AI 就會自動溝通並轉換出完美對應的資料格式，徹底免除撰寫解析程式碼的困擾。 Q：Google Gemini 的免費額度真的夠做 n8n 自動化嗎？A：對大多數入門情境來說，通常夠用。若您的工作流主要是做摘要、分類、標籤整理、客服訊息初步回覆，Free tier 往往已足以支撐測試與小量正式使用。不過如果您開始大量處理長文本、頻繁排程，或同時有多個工作流共用同一組 API Key，就需要留意速率限制與用量上限。最穩健的做法是先用免費層把流程跑通，再依實際流量決定是否升級付費方案。 Q：什麼情況下該用「Message a Model」，什麼情況下該直接改用 AI Agent？A：如果您的任務只是單純的一進一出，例如摘要、翻譯、分類、改寫，且後面只要接一個 Code 節點就能順利整理資料，那麼 Message a Model 通常更簡單、成本也更低。但如果您已經明確知道後面要依賴固定欄位，例如 summary、category、keywords 去串接 LINE、Email、Sheets 或資料庫，那麼直接使用 AI Agent + Structured Output Parser 會更穩定，後續維護也更省力。 Q：為什麼我明明要求 Gemini 輸出 JSON，結果還是會多出說明文字或格式錯誤？A：因為單靠 Prompt 約束，模型仍可能在某些情況下額外補充說明，尤其當輸入內容較長、規則較複雜，或模型判斷需要「解釋」時更容易發生。這也是本文會把兩種方法拆開講的原因：如果您走基礎節點路線，就要準備用 Code 節點做容錯解析；如果您要的是更高穩定性，就應直接改走 Structured Output Parser，把格式控制交給系統，而不是只靠文字要求。 Q：匯入本文附錄的工作流 JSON 後，還需要手動修改哪些地方？A：需要，因為附錄的 JSON 是示範骨架，不是可直接上線的最終版本。至少要檢查三個地方：第一，Google Gemini Chat Model 是否已綁定您的 Gemini API Credential；第二，前置節點是否真的有提供 input_text 這個欄位；第三，後續節點若要讀取 Agent 的結果，是否使用正確路徑，例如 output.summary、output.category、output.keywords。如果其中任何一個欄位名稱對不上，流程就很容易出現空值或報錯。 Q：如果我的 JSON Schema 定義得太嚴格，會不會反而讓模型常常失敗？A：會有這種可能，尤其當您同時要求太多欄位、限制太多列舉值，或輸入內容本身資訊不足時。實務上建議 Schema 先維持「夠用就好」：只保留後續流程真正會用到的欄位，避免一開始就設計過多可有可無的結構。對自動化工作流來說，穩定輸出 4 個必要欄位，通常比一次追求 10 個欄位更有價值。 Q：如果後面我要把 Gemini 的結果寫進 Google Sheets、Notion 或資料庫，最重要的注意事項是什麼？A：最重要的是欄位名稱與值域要先標準化。不要讓模型今天輸出 AI工具、明天輸出 AI 工具、後天又輸出 AI Tool。一旦分類名稱不一致，後面做搜尋、篩選、儀表板統計都會變得很麻煩。因此像本文示範的 enum 設計就非常重要，它不是為了形式好看，而是為了確保資料落地後仍然可被穩定使用。

為什麼這篇設定很重要？在 n8n 的自動化流程中，Gmail 常常不是單獨存在，而是扮演「最後通知出口」的角色。你可能會先從 LINE、表單、Webhook 或資料庫拿到資料，再交給 AI 做整理，最後自動寄出摘要通知。這也是很多人卡關的地方：流程節點都接好了，結果 Gmail 節點始終無法授權。 Google 已經不建議用帳號密碼直接讓第三方服務寄信，因此在 n8n 中要使用 Gmail，標準做法就是透過 Google Cloud Console 建立 OAuth2 授權，再把 Client ID 與 Client Secret 填回 n8n。 這個設定一旦完成，未來你不只可以用在 Gmail，也能延伸到 Google Calendar、Google Drive、Google Sheets 等常見 Google 服務。更重要的是，當你做 AI 自動化工作流時，這組憑證就是能不能穩定落地的關鍵一步。 實用資源連結： Google Cloud Platform Google Cloud Console 這篇文章會完成什麼？本文會帶你完成兩件事： 在 Google Cloud 建立可供 n8n 使用的 Gmail OAuth2 憑證。 把這組憑證套用到一個實戰工作流：LINE Webhook -> AI Agent -> LINE Reply + Gmail 通知 根據你提供的工作流 JSON，這條流程的核心邏輯如下： Webhook：接收 LINE Bot 傳入的 webhook 事件。 If：確認收到的是文字訊息，而不是貼圖、圖片或其他事件。 Edit Fields：把 body.events[0].message.text 整理成 input_text。 AI Agent：交給 OpenAI 模型做摘要、分類、關鍵字萃取。 Structured Output Parser：限制輸出格式必須是固定 JSON。 HTTP Request：呼叫 LINE Reply API，把摘要結果回傳給使用者。 Gmail：再寄一封 Email，把摘要結果與原始文字同步通知給自己或團隊。 也就是說，Gmail OAuth2 不是孤立設定，而是整條 AI 通知流程的一部分。 第一步：如何在 Google Cloud Console 建立專案與啟用 API？要讓 n8n 可以代表你操作 Gmail，第一件事就是在 Google Cloud 建立專案，並啟用對應 API。 登入平台： 前往Google Cloud Console 並使用你的 Google 帳號登入。（建議預先綁定實體信用卡以利通過身分驗證，避免使用易遭拒絕的簽帳金融卡）。 建立新專案： 點擊左上角專案選單，選擇「**新增專案 (New Project)**」。將專案命名為易於辨識的名稱（例如：n8n-try），若無所屬機構可選擇「無組織」，接著點擊「建立」。 進入 API 服務： 專案建立完成後，展開左側導覽選單，選擇「API 和服務」>「已啟用的 API 和服務」（建議將此選項加入星號釘選，未來會經常使用）。 啟用所需 API： 點擊上方的「**+ 啟用 API 和服務**」，在搜尋框中尋找並啟用以下服務： Gmail API (本次寄信必備) Google Calendar API (建議一併開啟) Google Drive API (建議一併開啟) 第二步：如何設定 OAuth 同意畫面與新增測試使用者？在取得金鑰之前，還要先設定 OAuth 同意畫面。這個畫面就是你在 n8n 點擊 Sign in with Google 時，Google 會跳出來要求你確認授權的那一頁。 設定同意畫面： 在「API 和服務」選單中點擊「OAuth 同意畫面」。 選擇使用者類型： 一般個人用戶請選擇「**外部 (External)**」，點擊建立。 填寫應用程式資訊： 應用程式名稱：輸入如 n8n-try。 使用者支援電子郵件：選擇你目前的 Google 帳號。 開發人員聯絡資訊：同樣填入你的 Google 帳號。 新增測試使用者 (非常重要)：因為我們的應用程式仍在「測試中 (Testing)」狀態，並未經過 Google 官方審核發布，只有被加入「測試使用者」名單的帳號才能順利授權。 在「測試使用者」區塊，點擊「**+ ADD USERS**」。 輸入你即將用來「發送 Email」的 Google 帳號並儲存。 第三步：如何取得 Client ID 與密鑰 (Secret)？前面都設定好後，現在就可以正式建立 n8n 要使用的 OAuth2 憑證。 建立憑證： 點擊左側選單的「憑證」，接著點擊上方「**+ 建立憑證」，選擇「OAuth 用戶端 ID**」。 設定應用程式類型： 選擇「**網頁應用程式 (Web application)**」，並輸入名稱（如：n8n-try）。 設定重新導向 URI (Redirect URI)： 回到你的 n8n 介面，新增一個 Gmail 節點，動作選擇 Send a message。 在認證 (Credential) 欄位選擇 Create new credential。 複製 n8n 介面上提供的 OAuth Redirect URL（例如：https://n8n-try.zeabur.app/rest/oauth2-credential/callback）。 將此網址貼回 Google Cloud 憑證設定的「已授權的重新導向 URI」欄位中（注意：網址結尾不可包含斜線 /）。 取得金鑰： 點擊「建立」後，系統會彈出視窗顯示你的 用戶端 ID (Client ID) 與 **用戶端密鑰 (Client Secret)**。請將這兩組字串妥善複製並保存。 專家提示： 密鑰 (Secret) 只會在第一次建立時完整顯示，請務必妥善備份。若不慎遺失或外洩，可回到憑證管理頁面刪除舊密鑰並重新生成。 第四步：如何回到 n8n 建立 Gmail Credential？Google 端的工作完成後，接下來就是把這組 OAuth2 憑證填回 n8n。 輸入憑證資訊： 回到 n8n 的 Credential 設定畫面，將剛剛取得的 Client ID 與 Client Secret 貼入對應欄位，點擊「Sign in with Google」。 完成安全授權： 登入你設定為「測試使用者」的 Google 帳號。 系統會出現「這個應用程式未經 Google 驗證」的警告。這是正常現象，請點擊左下方的「繼續 / 進階」，再點擊「**前往 n8n-try (不安全)**」。 勾選「全選」賦予讀寫信件的權限，最後點擊「繼續」，若顯示 Connection successful 即代表串接成功！ 命名 Credential： 建議不要直接用預設名稱，可命名為像 Gmail (n8n-try) 或 Gmail (LINE 摘要通知)，之後多個專案並存時比較好管理。 第五步：如何把 Gmail 應用到這個 LINE + AI 工作流？當 Credential 建好後，就可以把它接到你這份工作流裡的 Gmail 節點。你提供的 JSON 使用的是 Send a message1 節點，實際設定重點如下。 1. 先理解這條工作流的資料流這份工作流的順序是： Webhook -> If -> Edit Fields -> AI Agent -> HTTP Request + Gmail 其中最關鍵的資料轉換有兩段： Edit Fields 把 LINE 訊息抽成 input_text AI Agent 透過結構化輸出，回傳 summary、category、keywords、language 也因為如此，Gmail 節點裡的主旨與內文，就可以直接引用 AI Agent 的輸出欄位。 2. Gmail 節點的設定方式在 Gmail 節點中，至少要確認以下欄位： Resource / Operation： Message / Send Credential： 選擇剛剛建好的 Gmail OAuth2 憑證 To： 你的收件信箱，或團隊共用信箱 Email Type： Text 你提供的範例主旨使用這段 Expression： 1LINE 摘要通知｜{{$json.output.category}} 信件內容則把 AI 整理後的資料與原始訊息一起寄出： 12345678910111213141516171819您好，已收到一則新的 LINE 文字內容，並完成自動整理如下：【摘要】{{$json.output.summary}}【分類】{{$json.output.category}}【關鍵字】{{$json.output.keywords.join('、')}}【語言】{{$json.output.language}}--------------------【原始內容】{{$('Edit Fields').item.json.input_text}} 這種寫法很適合通知型工作流，因為你不只會收到 AI 的摘要結果，也能同步保留原始內容做交叉檢查。 3. 為什麼這樣設計很實用？這份流程其實同時做了兩件事： 對外：透過 HTTP Request 呼叫 LINE Reply API，把摘要立即回覆給使用者 對內：透過 Gmail 把摘要寄給自己或團隊，形成通知與留存紀錄 如果你未來想把這條流程改造成客服摘要、業務回報、報名表單通知、或內部知識蒐集，這個架構都很容易擴充。 第六步：AI Agent 與 Structured Output 在這個流程中扮演什麼角色？這篇主題雖然是 Gmail OAuth2，但如果不了解前面的 AI 結構，很多人會在 Gmail 節點誤抓欄位，導致信件主旨或內文出現空值。 1. Edit Fields 做了什麼？Edit Fields 節點把原始 LINE Webhook 內容： 1{{ $json.body.events[0].message.text }} 整理成單一欄位： 1input_text 這樣做的好處是提示詞更乾淨，也比較不容易在後面節點重複寫深層路徑。 2. AI Agent 的提示詞邏輯你提供的 AI Agent 使用的是以下任務設定： 1234請讀取以下內容，輸出摘要、主題分類、3 個關鍵字。內容：{{$json.input_text}} 而 System Message 則限制模型： 使用繁體中文 不要捏造資訊 只輸出 JSON 必須包含 summary、category、language 資訊不足也要輸出合法 JSON 3. Structured Output Parser 為什麼重要？因為後面的 LINE Reply 與 Gmail 都不是要讀一大段自由文字，而是要讀固定欄位。 你的 JSON Schema 其實已經把這件事做得很完整： summary：摘要文字 category：限定在 AI工具、程式開發、商業、教育、其他 keywords：字串陣列 language：語言判斷 這代表 Gmail 節點可以穩定用下面這些欄位，而不是碰運氣讀模型輸出： `{{$json.output.summary}}` `{{$json.output.category}}` `{{$json.output.keywords.join('、')}}` `{{$json.output.language}}` 第七步：正式測試前，建議先檢查哪些地方？在你按下 Execute workflow 之前，建議先做一次快速檢查： Google Cloud 的 OAuth 同意畫面是否已加入正確的測試使用者。 Gmail Credential 中的 Client ID、Client Secret 是否來自同一個專案與同一組憑證。 OAuth Redirect URL 是否完整貼入 Google Cloud，而且沒有多餘斜線。 Gmail 節點是否真的選到正確的 Credential，而不是舊的或失效的憑證。 Gmail 節點中的 Expression 是否抓的是 AI Agent 的 output 欄位。 keywords 若要顯示成文字，是否已用 .join('、') 轉成字串。 If 節點是否限制只有 message.type = text 才往下走，避免貼圖或圖片事件直接報錯。 如果這幾個地方都正確，通常整條流程就能順利跑起來。 常見問答 (FAQ)Q：註冊 Google Cloud Platform (GCP) 需要綁定信用卡嗎？會不會被亂扣款？A：Google Cloud 通常會要求綁定信用卡做身分驗證，這是平台的常見流程。若你只是用來做 Gmail OAuth、Calendar 或 Drive 這類基礎串接，而且沒有另外啟用付費資源，通常不會因為這篇教學本身產生額外高額費用。不過還是建議你定期查看帳單與專案啟用服務，避免把測試專案長期放著不管。 Q：在 n8n 點擊 Sign in with Google 時，出現「Access denied」或「此應用程式尚未完成驗證」怎麼辦？A：最常見有兩種原因： 你用來登入授權的 Google 帳號，沒有被加入 OAuth 同意畫面的「測試使用者」 你登入的帳號和 Google Cloud 專案內設定的測試帳號不是同一個 先回到 Google Cloud 的「OAuth 同意畫面」，確認測試使用者名單，再重新回 n8n 授權一次。 Q：為什麼我明明已經拿到 Client ID 和 Client Secret，n8n 還是授權失敗？A：這通常不是金鑰本身錯，而是 Redirect URI 不一致。請重新比對： n8n Credential 畫面顯示的 OAuth Redirect URL Google Cloud 憑證中的「已授權的重新導向 URI」 兩邊只要少一個字、多一個 /、或網域不同，都可能導致授權失敗。 Q：Gmail 節點已經成功連上，但寄信時仍然失敗，應該先檢查哪裡？A：建議先檢查這四個點： Gmail 節點是否真的選到正確的 OAuth2 Credential。 To 欄位是否為合法 Email。 主旨與內文中的 Expression 是否抓得到值。 前一個 AI Agent 是否真的有成功輸出 output.summary、output.category 等欄位。 很多人以為是 Gmail 壞掉，實際上是前面節點沒有值，導致寄信內容組不起來。 Q：這份工作流中，為什麼 Gmail 節點要用 `{{$json.output.summary}}`，而不是 `{{$json.summary}}`？A：因為你這份流程使用的是 AI Agent + Structured Output Parser。在這種情況下，AI 的結構化輸出通常會包在 output 物件裡，所以 Gmail 與 HTTP Request 要抓的是： `{{$json.output.summary}}` `{{$json.output.category}}` `{{$json.output.keywords}}` `{{$json.output.language}}` 如果你直接寫 `{{$json.summary}}`，通常會抓不到值。 Q：keywords 是陣列，直接放到 Gmail 內文裡可以嗎？A：技術上可以，但顯示通常不夠友善。比較建議轉成一般文字，例如： 1{{$json.output.keywords.join('、')}} 這樣收件者看到的會是「AI、自動化、LINE Bot」這種格式，而不是原始陣列樣式。 Q：如果 LINE 傳來的是貼圖、圖片或非文字事件，這條流程會怎麼樣？A：你提供的工作流已經先用 If 節點判斷： 1{{ $json.body.events[0].message.type }} === text 這是必要的，因為後面的 Edit Fields 會直接讀 message.text。如果沒有先過濾，遇到非文字事件時就可能報錯。 Q：為什麼這個流程同時要回 LINE，又要寄 Gmail？不是重複通知嗎？A：兩者用途不同： LINE Reply 是給最終使用者的即時回覆 Gmail 是給自己或團隊的內部通知與紀錄留存 如果你之後想追蹤哪些訊息被分類成什麼主題、或想保留原始內容做人工覆核，Email 留存會非常實用。 Q：如果我的 Client Secret 不小心外洩了，應該怎麼補救？A：請立刻回到 Google Cloud Console 的「API 和服務」>「憑證」，找到對應的 OAuth 用戶端，重新產生新的密鑰，並在 n8n 更新成新的 Credential 設定。確認新密鑰可正常授權後，再停用或刪除舊密鑰。只要你懷疑有外洩，就不要繼續使用原本那組。 Q：這組 Google OAuth2 設定之後只能拿來寄 Gmail 嗎？A：不是。只要同一個 Google Cloud 專案有啟用對應 API，你之後通常還可以延伸用到 Google Calendar、Google Drive、Google Sheets 等服務。不過每種服務在 n8n 端可能會有不同的權限範圍與 Credential 類型，實作時還是要分開確認。

如何將基礎 LLM 升級為強大的 AI Agent？在先前的 n8n 實作中，我們常用 Message a model 來處理 OpenAI API 的回覆。但只要流程開始牽涉到結構化輸出、節點串接穩定性、或後續還要交給其他系統使用，單純文字回覆通常很快就會碰到限制。 這次的做法不是只讓模型「回答問題」，而是讓它在 n8n 裡扮演一個可控的 AI Agent。搭配 Structured Output Parser 與 JSON Schema 之後，模型不只會回覆內容，還能穩定產出指定欄位，讓後面的 HTTP Request 節點可以直接把結果送進 LINE Bot 或其他 API。 如果你正在做的是「收到訊息 -> AI 分析 -> 結構化結果 -> 推播到外部服務」這種流程，那麼 AI Agent 會比一般對話節點更適合。 實作步驟：如何快速完成環境與節點部署？1. 建立工作流基本骨架根據附加的工作流 JSON，這個範例的核心節點順序如下： Webhook -> Edit Fields -> AI Agent -> HTTP Request 另外 AI Agent 下方還會再掛兩個擴充節點： OpenAI Chat Model Structured Output Parser 實作時可以照這個順序建立，會比較不容易接錯線。 2. 先用 Edit Fields 整理輸入資料這個範例不是直接把 LINE Webhook 的整包 JSON 丟給 AI，而是先透過 Edit Fields 抽出真正要分析的文字： 1{{ $json.body.events[0].message.text }} 並且將它命名為： 1input_text 這一步很重要，因為它可以讓後續提示詞更乾淨，也能降低你在 AI Agent 中直接處理深層 JSON 路徑的複雜度。 3. 配置 AI Agent 的提示詞與系統設定進入 AI Agent 的設定畫面，我們需要定義它的角色與任務： 設定 System Message：在 Options 中加入 System Message，建立固定規則。 設定 User Message：在 Prompt (User Message) 中用 Expression 模式動態帶入前一節點的資料。 這份工作流實際使用的 User Message 可整理成： 1234請讀取以下內容，輸出摘要、主題分類、3 個關鍵字。內容：{{$json.input_text}} System Message 的設計重點則是： 12345678你是資料整理助手。規則：1. 使用繁體中文。2. 不要捏造未提供的資訊。3. 請只輸出 JSON。4. 欄位必須包含 summary、category、language。5. 若資訊不足，也必須輸出合法 JSON。 如果你只是想讀取前一節點整理好的文字，也可以記住最核心的變數寫法： 1{{ $json.input_text }} 實作提醒：一定要切到 Expression 模式。若你停留在 Fixed，n8n 會把 `{{$json.input_text}}` 當成純文字，而不是變數。 4. 結合 Structured Output Parser 實現 JSON 格式化為了讓 AI 的輸出能被後續的 HTTP Request（例如發送到 LINE）完美讀取，我們必須規範它的輸出格式： 點擊 AI Agent 下方的 Output Parser 擴充節點，選擇 Structured Output Parser。 將 Schema Type 設為手動定義 JSON Schema。 使用標準 JSON Schema 來限制欄位格式。根據附加檔案，這次實作的 Schema 如下：1234567891011121314151617{ "type": "object", "properties": { "summary": { "type": "string" }, "category": { "type": "string", "enum": ["AI工具", "程式開發", "商業", "教育", "其他"] }, "keywords": { "type": "array", "items": { "type": "string" } }, "language": { "type": "string" } }, "required": ["summary", "category", "keywords", "language"], "additionalProperties": false} Schema 設計重點解析： **enum**：限制 category 只能從預定義的分類中選擇，避免 AI 自由發揮產生不一致的分類名稱。 keywords 陣列：讓 AI 自動提取 3 個關鍵字，方便後續做資料標籤或搜尋索引。 **required**：強制所有欄位都必須存在，防止 AI 漏掉任何一個欄位。 **additionalProperties: false**：禁止 AI 額外輸出未定義的欄位，確保 JSON 結構乾淨一致。 5. 串接 OpenAI Chat ModelAI Agent 就像一個大腦，需要連接特定的語言模型才能運作： 點擊 AI Agent 下方的 Chat Model 擴充節點。 搜尋並選擇 OpenAI Chat Model。 在模型設定中選擇對應模型版本。本次附加檔案使用的是： 1gpt-5-mini 如果你的任務是摘要、分類、關鍵字提取這類結構化整理工作，先從成本較低、速度較快的模型開始，通常就很夠用了。 6. 修正 HTTP Request 節點的輸出參數這是升級 AI Agent 後最容易踩雷的地方。因為節點改成 AI Agent 之後，輸出物件不再和原本 Message a model 一樣，後面的 HTTP Request 若仍沿用舊路徑，就很容易送出空值或直接報錯。 根據附加檔案，HTTP Request 送往 LINE Reply API 時，正文內容是從 output 物件裡取值，因此你至少要重新綁定以下欄位： 摘要：`{{ $json.output.summary }}` 分類：`{{ $json.output.category }}` 語言：`{{ $json.output.language }}` 若你也想把關鍵字一起送出去，可以再補上： 關鍵字：`{{ $json.output.keywords.join('、') }}` 另外，附加工作流中的 LINE 訊息模板有一個小細節值得注意：欄位名稱寫成了 languag，如果你要正式發布，建議順手改成 language，避免訊息文字看起來像拼字錯誤。 完成變數重綁後，執行 Execute workflow 測試，理想狀況下你就能在 LINE 收到一段由 AI 產生、而且格式固定的摘要結果。 觀念解析：一般模型 (Message a model) vs. AI Agent 差異在哪？為什麼我們不繼續用原本的 Message a model，而要大費周章換成 AI Agent？這兩者雖然看起來都是處理文字，但運作底層完全不同： 比較維度 一般對話模型 (Message a model) AI Agent 處理邏輯 **線性直出 (Linear)**：輸入問題 $\rightarrow$ 產出解答 $\rightarrow$ 結束。 **循環思考 (Loop)**：接收任務 $\rightarrow$ 思考 $\rightarrow$ 調用工具 $\rightarrow$ 驗證 $\rightarrow$ 產出。 擴充能力 僅能單純處理文字生成與回覆。 可串接多種工具 (Tools)、資料庫或記憶庫 (Memory)。 Token 消耗 極低（省錢），適合簡單明確的任務（如翻譯、改寫）。 較高（耗費 Token），因為會進行多次內部對話與工具反覆確認。 顧問建議：如果你的任務只是單純改寫、翻譯、生成一段文字，Message a model 通常更省成本；但如果你需要穩定輸出結構、後續還要串 API、或未來準備接工具與記憶能力，直接用 AI Agent 會更有擴充性。 常見問答 (FAQ)一、節點設定與資料流Q：為什麼這個流程要先用 Edit Fields，不能直接把 Webhook 內容丟進 AI Agent 嗎？A：可以直接丟，但不建議。LINE Webhook 的 JSON 通常層級較深，若直接在提示詞裡寫 `{{$json.body.events[0].message.text}}`，可讀性與維護性都比較差。先用 Edit Fields 把資料整理成 input_text，後續提示詞會更乾淨，也更容易除錯。 Q：AI Agent 的 Prompt 為什麼一定要切成 Expression？A：因為你要讀的是前一個節點動態傳入的值。若使用 Fixed，n8n 會把 `{{$json.input_text}}` 當成一般字串，而不是變數，模型收到的就不是實際訊息內容。 Q：系統提示詞已經寫「請只輸出 JSON」了，為什麼還要加 Output Parser？A：因為提示詞只是要求，Parser 才是約束。只靠提示詞，模型仍可能偶爾多說一句說明文字；加上 Structured Output Parser 與 JSON Schema，才比較能把輸出鎖定在你要的欄位結構內。 二、Structured Output 與 JSON SchemaQ：JSON Schema 裡的 required 和 additionalProperties: false 有什麼差別？A：required 是規定哪些欄位一定要出現；additionalProperties: false 是禁止模型額外加出沒定義的欄位。兩者一起用，才能同時做到「不能漏欄位」與「不能亂加欄位」。 Q：category 為什麼要用 enum？A：因為分類欄位很容易失控。若不限制，模型可能一下輸出「商業應用」、一下輸出「商務」、一下又寫「創業」，後續做篩選、分析或寫入資料庫時就會很麻煩。用 enum 能把分類名稱固定下來。 Q：keywords 是陣列，實際發送 LINE 訊息時要怎麼顯示？A：如果 LINE 訊息需要純文字顯示，可以把陣列轉成字串，例如： 1{{ $json.output.keywords.join('、') }} 這樣收到的訊息會比較適合一般使用者閱讀。 三、常見錯誤與除錯Q：為什麼把一般模型換成 AI Agent 後，最後的 HTTP Request 會報錯或變成空值？A：最常見原因就是資料路徑改了。切換成 AI Agent 後，輸出通常會包在 output 物件中，所以你原本綁的欄位若不是 `{{ $json.output.summary }}` 這類新路徑，就會抓不到值。 Q：如果 AI 回傳格式仍然不穩，應該先檢查哪裡？A：先檢查三件事： Structured Output Parser 是否真的接在 AI Agent 的 ai_outputParser 連線上。 JSON Schema 是否為合法格式，尤其是括號、逗號與 required 欄位名稱。 System Message 是否和 Schema 衝突，例如提示詞要求輸出欄位和 Schema 定義不一致。 Q：附加工作流裡 LINE 訊息的欄位名稱出現 languag，這會影響流程嗎？A：不會影響資料抓取，因為真正取值仍然是 `{{ $json.output.language }}`。但它會讓使用者在 LINE 看到拼字錯誤，所以建議改掉，這屬於顯示層的細節修正。 四、模型選擇與使用時機Q：這種摘要與分類工作，適合用哪一種模型？A：如果需求是摘要、分類、關鍵字提取、標籤整理這種中低複雜度任務，先用輕量模型通常最划算。像附加檔案採用的 gpt-5-mini，就很適合作為第一版驗證。 Q：什麼情況下我應該直接用 AI Agent，而不是 Message a model？A：當你符合以下其中一種情況，就很適合改用 AI Agent： 你需要穩定的 JSON 結構輸出。 你後面還要串接 API、資料庫或聊天平台。 你未來可能會加上工具調用、知識庫檢索或多步驟判斷。 如果只是一次性生成文字，Message a model 仍然比較省錢也比較簡單。

如何快速開啟你的 AI 自動化冒險？在 AI 工具百花齊放的時代，雖然有多種大型語言模型可供選擇，但在 n8n 自動化流程中，最穩定且最常被使用的核心引擎依然是 **ChatGPT (OpenAI API)**。本篇文章將手把手帶你完成 n8n 與 ChatGPT 的串接，從申請 API 密鑰、模型選擇到完整的 Prompt 詠唱技巧，一次幫你打通自動化工作流的任督二脈！ 實用資源連結： OPENAI API 平台 n8n 官方文件：OpenAI node 整合指南 步驟一：如何取得與保護你的 OpenAI API 魔法鑰匙？要讓 n8n 成功呼叫 ChatGPT，你必須先取得專屬的 API Key，並了解官方的計費與使用規範。 1. 申請 API Key 你可以先前往 OPENAI API 平台 了解最新的模型能力與官方資訊。 接著登入 OpenAI Platform 開發者後台（注意：此帳號獨立於一般版 ChatGPT 網頁，可分開註冊）。 點擊右上角個人頭像，進入 Profile -> API keys。 點擊 Create new secret key，為你的 Key 命名（例如：n8n-try），並選擇預設的 Project。 複製生成的金鑰（格式通常為 sk-...）。請注意，這組金鑰建立後通常只會完整顯示一次，務必立即妥善保存。 2. 公會嚴格守則：資安防護 專家警告： 這把「魔法鑰匙」絕對不可外洩！千萬不要將 API Key 直接寫在程式碼中，或推送到公開的 GitHub Repo。一旦外洩，你的額度將面臨被盜刷的風險。在 n8n 中，請務必使用內建的 Credentials 系統來安全儲存。 (註：新申請的帳號若未綁定信用卡並儲值 Credit，呼叫 API 時將會報錯。建議先至 Billing 頁面進行小額充值以啟用服務，否則即使 Key 建立成功也可能因額度問題而無法呼叫。) 步驟二：n8n 實戰，如何正確配置「OpenAI node」節點？隨著 n8n 官方不斷迭代，舊版的 Assistant API 節點已被淘汰。最新的整合方式請務必參考官方指南：OpenAI node 官方文件。 1. 新增節點與設定憑證在 n8n 工作流中，新增一個最新的 OpenAI Node (Message a Model) 節點。在 Credential to connect with 欄位中，選擇創建新的憑證，並貼上剛剛申請的 OpenAI API Key 來完成連線。 2. 挑選適合的 AI 精靈 (Model)在節點的 Model 列表中，你會看到多種模型。實戰上的選擇策略如下： GPT-5-mini (萬能主角)： 性價比最高、處理速度快，足以應付 80% 以上的日常自動化任務（如：摘要、分類、翻譯）。（實戰首推） GPT-5-nano (低成本首選)： 適合大量且極度單純的資料抽取，成本最低。 GPT-5 / GPT-4o (BOSS 戰專用)： 當需要高難度推理、複雜程式碼撰寫或嚴格邏輯判斷時再派上用場。 如果你只是要先做出第一個能穩定跑通的 MVP，建議直接從 gpt-5-mini 開始。它的速度、成本與輸出品質在 n8n 場景中相對平衡，很適合摘要、分類、標籤整理、客服初步回覆等任務。 步驟三：詠唱的藝術，如何精準設定 Prompt 與輸出 JSON 格式？要讓 AI 聽話，不能只把資料丟給它，必須建立「三層漢堡」結構的提示詞 (Prompt)。核心原則很簡單：System 負責規則，User 負責任務，而 JSON Schema 負責把輸出格式鎖死。 1. 頂層：系統人設 (System Prompt)在節點設定中，將 Role 設為 System。在這裡賦予 AI 角色與規則： 12345678你是資料整理助手。規則：1. 使用繁體中文。2. 不要捏造未提供的資訊。3. 請只輸出 JSON。4. 欄位必須包含 summary、category、keywords、language。5. 若資訊不足，也必須輸出合法 JSON。 2. 中層與底層：任務指令與動態輸入 (User Prompt)再新增一個 Message 區塊，Role 設為 User，並動態帶入前方節點的變數： 1234請讀取以下內容，輸出摘要、主題分類、3 個關鍵字。內容：{{ $json.input_text }} 3. 強制結構化輸出 (JSON Schema)為了後續自動化節點能順利讀取資料，我們必須限制 AI 只能輸出 JSON： 在節點底部的 Options 點擊 Add Option。 選擇 Text Format 或 Output Format 中的 JSON Schema（不同版本 UI 命名略有差異）。 貼上你預先定義好的 Schema 格式，例如： 1234567891011121314151617{ "type": "object", "properties": { "summary": { "type": "string" }, "category": { "type": "string", "enum": ["AI工具", "程式開發", "商業", "教育", "其他"] }, "keywords": { "type": "array", "items": { "type": "string" } }, "language": { "type": "string" } }, "required": ["summary", "category", "keywords", "language"], "additionalProperties": false} 這樣做的最大好處是，下一個節點不需要再猜 AI 回了什麼格式，直接用固定欄位去接值即可。特別是 enum 很實用，它能強迫模型只能從你預設好的分類清單中挑選答案，大幅降低資料髒亂與拼字不一致的問題。 步驟四：資料淨化與回傳，如何完成連段技？在呼叫完 AI 後，我們通常需要將結果傳回前端（例如 Line Bot 或資料庫）。 Set 節點淨化： 在接收 Webhook 與傳給 AI 之間，建議先安插一個 Set (Edit Fields) 節點，將複雜的 Webhook 結構簡化為 input_text。例如把 {{ $json.body.events[0].message.text }} 指派給 input_text，這能讓你的 Prompt 保持乾淨，也讓後續維護更容易。 HTTP Request 回傳： 取得 AI 產出的 JSON 後，使用 HTTP Request 節點，動態帶入 replyToken 與 AI 產出的摘要內容，即可成功將結果推播給使用者。 如果你是串接 Line Bot，JSON Body 可以參考下面這個最小可行範例： 123456789{ "replyToken": "{{ $('Webhook').item.json.body.events[0].replyToken }}", "messages": [ { "type": "text", "text": "【summary】{{ $json.output[0].content[0].text.summary }}\n【category】{{ $json.output[0].content[0].text.category }}\n【language】{{ $json.output[0].content[0].text.language }}" } ]} 如果你也想把關鍵字一起回傳，只要在文字內容中再補上 keywords 欄位即可。透過這種做法，一個從接收、處理到回覆的 MVP AI 自動化工作流就能順利跑起來。 常見問答 (FAQ)為了方便你快速排錯，我把常見問題依照「最容易搜尋到的痛點」重新整理成四類：先處理帳號與節點錯誤，再看模型與成本，接著解決工作流穩定性，最後才是上線與維護。 一、帳號、節點與連線錯誤Q：為什麼我的 OpenAI API Key 一直報錯或無法使用？A：最常見的原因是「帳戶餘額不足」。OpenAI API 的計費機制與一般網頁版 ChatGPT Plus 訂閱是完全分開的。請登入 OpenAI API 後台的 Billing 頁面，綁定信用卡並儲值（Add payment details），API 即可正常開通使用。 Q：為什麼我在 n8n 執行 OpenAI 節點時，會收到「Error: 401 Insufficient Quota」的錯誤？A：這是因為你的 OpenAI 開發者帳戶「餘額不足」。OpenAI API 的計費與一般網頁版的 ChatGPT Plus 訂閱是分開的。請登入 OpenAI Platform 的 Billing 頁面，綁定信用卡並預先儲值（如 5 美金），即可開通 API 權限。 Q：為什麼在 n8n 裡找不到舊版的 OpenAI Assistant 節點？A：n8n 官方已於後續版本中淘汰了舊的 Assistant API 節點，改用更具彈性的架構。目前的最佳實踐是參考OpenAI node 官方文件，使用「Message a Model」或 LangChain 相關節點，不僅支援多模態（圖片、音訊），在設定 JSON Schema 結構化輸出時也更加穩定。 Q：如果我在 OpenAI 節點裡找不到 JSON Schema 選項怎麼辦？A：這通常有兩種原因。第一，你使用的是較舊版的 n8n，介面中可能還沒有完整支援結構化輸出功能；第二，你可能不是使用最新的 Message a Model 類型節點，而是用了舊版或其他 OpenAI 相關節點。最穩妥的做法是先更新 n8n，並確認你使用的是官方目前主推的 OpenAI 節點。若暫時無法升級，也可以先在 Prompt 中強制要求輸出 JSON，再用後續節點做驗證，但穩定性仍然不如原生 Schema。 二、模型選型與成本控制Q：gpt-5-mini、gpt-5-nano、gpt-5 到底該怎麼選？A：你可以用一句話快速判斷。若你的任務是摘要、分類、標籤整理、客服初步回覆這類標準型工作，先選 gpt-5-mini；若你的任務極度單純，而且請求量很大、很在意成本，可以試 gpt-5-nano；若你要處理多步邏輯推理、複雜文字生成或高品質程式碼任務，再升級到 gpt-5。不要一開始就選最強模型，否則通常只是成本更高，效果卻未必明顯更好。 Q：為什麼我的成本會比想像中高？不是只有丟一段文字給 AI 嗎？A：成本不只和輸入文字長度有關，也和你送出的系統提示詞、使用者提示詞、歷史上下文，以及模型輸出的字數有關。如果你在工作流中夾帶大量背景資訊、冗長規則、長篇聊天紀錄，Token 消耗就會快速增加。最佳做法是先用 Set、Code 或資料清洗節點把不必要的欄位砍掉，只保留 AI 真正需要看的內容。 Q：我可以把整段客服對話、網頁內容或 PDF 全部丟進去，讓 AI 自己理解嗎？A：技術上有時可以，但實務上不建議一開始就這樣做。資料越雜，輸出越不穩，成本也越高。比較好的流程是先做前處理，例如擷取重點欄位、清除無關字串、限制字數，再把精煉後的內容送進 OpenAI 節點。AI 並不是垃圾桶，前處理做得越乾淨，結果通常越穩。 Q：如果我的工作流只是做摘要或分類，還需要用 AI Agent 嗎？A：通常不需要。這種任務屬於標準的一進一出文字處理，使用單純的 OpenAI 節點反而最穩、最便宜，也最好除錯。AI Agent 真正適合的是需要自行查資料、決策、呼叫工具、反覆嘗試的流程。如果只是摘要、翻譯、改寫、分類或抽取欄位，直接用 LLM 節點即可。 三、輸出格式與工作流穩定性Q：AI 有時候會亂講話或格式跑版，導致後面的自動化流程中斷怎麼辦？A：這就是 Prompt 工程的關鍵！除了在 System Prompt 中明確寫出「請只輸出 JSON，不要包含其他廢話」之外，務必在 OpenAI 節點的 Options 中開啟 Output Format: JSON Schema，並嚴格定義你要的欄位結構。這樣 AI 就會被強制限制，只產出合法且符合你所需的 JSON 結構，確保工作流穩定運行。 Q：為什麼我明明要求 AI 輸出 JSON，它還是會多回一些說明文字？A：因為單靠 Prompt 約束並不保險。模型即使理解了你的要求，也有可能在某些情況下額外補一句說明，尤其在輸入內容複雜、上下文過長或指令不夠明確時更容易發生。最有效的解法不是一直加重語氣，而是直接使用 JSON Schema 或結構化輸出功能，讓格式限制由系統層處理，而不是只靠文字要求。 Q：為什麼同一段 Prompt，今天測得好好的，明天結果卻有點不一樣？A：這是生成式模型的正常現象。即使模型、提示詞與輸入看似相同，輸出的文字細節仍可能略有差異。因此在 n8n 工作流裡，真正需要追求的不是「每次字字相同」，而是「每次都符合你要的結構與規則」。也就是說，請把重點放在穩定的欄位輸出、固定分類值與可驗證的資料格式，而不是要求每一句自然語言都完全一致。 Q：OpenAI 節點回傳成功了，但我不知道該怎麼抓裡面的欄位怎麼辦？A：最簡單的方法是先在 n8n 的執行結果面板中查看該節點的實際輸出 JSON，確認資料路徑後，再複製到下一個節點的表達式中。很多新手會直接照抄別人的 {{ $json.output[0].content[0].text.summary }}，但不同節點版本或設定方式，輸出結構可能略有差異。正確做法永遠是先看自己的執行結果，再決定要抓哪一層。 Q：為什麼 AI 有時候回傳的內容會導致後面的 HTTP Request 節點報錯？A：通常是因為 AI 回傳了包含 Markdown 標記（如 json ）或多餘的聊天廢話，導致 n8n 無法正確解析 JSON。解決方案是確實使用步驟三教學的 JSON Schema 功能，這會在底層強制 API 僅能輸出純粹且符合規則的 JSON 格式。 Q：Webhook 傳來的結構太複雜，我一定要用 Set (Edit Fields) 節點嗎？A：雖然不是強迫的，但強烈建議使用。將深層的 JSON 路徑（例如 body.events[0].message.text）統一轉換為一個易讀的變數 input_text，不僅方便你在 Prompt 中引用，未來如果前端平台（從 Line 換成 Telegram）更換了，你也只需要在 Set 節點修改一次對應關係，大幅提高工作流的維護性。 Q：如果我想讓 AI 根據不同情境回不同格式，還適合用固定 Schema 嗎？A：可以，但你要先重新思考資料設計。實務上不建議讓同一個節點今天回 A 格式、明天回 B 格式，因為這會讓後續節點很難維護。更好的做法通常有兩種：一種是把所有可能欄位都設計進同一份 Schema，未使用欄位留空；另一種是先用前一個節點做路由判斷，再分流到不同的 OpenAI 節點，各自使用不同 Schema。這樣工作流會比混合格式穩定很多。 四、上線測試與後續維護Q：如果我想把 AI 產出的結果寫進 Google Sheets、Notion 或資料庫，有什麼要注意？A：最重要的是欄位要先標準化。也就是說，不要讓 AI 自由發揮欄位名稱、分類文字或日期格式，而是先在 Schema 裡把欄位類型與值域定義好。這樣後續接 Google Sheets、Notion、Airtable、SQL 等節點時，才不會出現欄位名稱忽然改掉、分類值拼法不一致，或日期格式無法寫入的問題。 Q：我該怎麼測試這個工作流，才不會一上線就翻車？A：請不要一開始就拿真實使用者流量測。比較穩健的方式是先準備 5 到 10 組測試資料，刻意涵蓋正常輸入、空字串、超長文本、語意模糊內容，以及格式不完整的情境。只要這些案例都能穩定輸出合法 JSON，而且後面的 HTTP Request 或資料庫節點都接得住，你再上線會安全很多。 Q：如果未來 OpenAI 模型更新，我現在的 n8n 工作流會壞掉嗎？A：有可能，但通常不是整個流程壞掉，而是輸出風格、欄位路徑或可選模型名稱發生變化。因此建議你在工作流中盡量避免硬依賴模型的自由文字表現，而是把穩定性建立在 System Prompt、JSON Schema 與後續驗證節點上。只要格式約束做得夠紮實，未來即使更換模型，調整成本也會低很多。

在建立 n8n 的自動化工作流時，許多新手都會遇到一個核心痛點：畫面上同時有 LLM 節點和 AI Agent 節點，到底該拉哪一個？ 如果你習慣將所有任務都塞給 AI Agent 處理，你可能會面臨 Token 費用暴增、執行流程不穩定，甚至是難以 Debug 的地獄。這篇文章將帶你深度解析 LLM 與 AI Agent 的本質差異，並教你如何針對不同的戰場，選擇最適合的自動化武器。 💡 核心對決：LLM 與 AI Agent 的本質差異在哪裡？要理解兩者的差異，我們可以用最簡單的「積木（Function）」概念來看： LLM (大型語言模型)： 本質上它**只有一個大腦 (Model)**。它採取一問一答的線性模式（你問 → 他回），完全處於被動狀態。 AI Agent (智能體)： 除了大腦 (Model) 之外，它還具備了 記憶 (Memory) 與 **工具箱 (Tools)**。它能夠根據你的目標，自主啟動 ReAct（理解目標 ➔ 規劃步驟 ➔ 呼叫工具 ➔ 檢查結果）的多步推理解迴路，直到任務完成。 🧠 為什麼 90% 的場景你只需要 LLM？（省錢又穩定）許多新手在初學 n8n 時，容易陷入「凡事皆用 Agent」的誤區。事實上，在日常的自動化任務中，有高達 90% 的時間你只需要使用單純的 LLM 節點。 適合 LLM 處理的任務特徵： 流程固定： 擁有明確的輸入（Input）與輸出（Output）。 純文字處理： 例如資料摘要、語言翻譯、語意分類（客訴情緒判斷）。 生成結構化資料： 幫你打草稿、生成 Email 內容、或是轉換成特定格式（JSON、SQL）。 LLM 的絕對優勢： 超便宜： 只要 Prompt 寫好，一次呼叫就解決，Token 消耗極低。 超好 Debug： 流程固定，出錯時一眼就能看出是哪個環節的問題。 可控性極高： 嚴格遵循你的指令，不會有意外的自主決策。 🦸‍♀️ 何時才需要派 AI Agent 上場？（處理不確定任務）如果你今天的任務沒有固定的標準流程，且需要「動態決策」或「與外部系統互動」，這時才是 AI Agent 發揮價值的舞台。 適合 AI Agent 處理的任務特徵： 不確定的流程： 無法事先寫死所有的判斷條件。 需要多步驟決策： 遇到問題需要反覆思考並修正。 依賴外部工具： 例如自動查訂單資料庫、上網搜尋最新資訊、或是直接操作 API 發送郵件。 ⚠️ 新手防坑警告：拜託不要濫用 Agent！AI Agent 雖然聰明，但會帶來高昂的代價。它在思考與嘗試的過程中會消耗大量 Token（成本直接爆炸），且由於具備自主決策權，非常容易產生「幻覺 (Hallucination)」導致過度行動。如果出錯，因為思考邏輯成謎，Debug 的難度將會非常高。 鐵則：能用 LLM 解決的問題，就絕對不用 Agent！ 🏗️ 大師級實戰架構：如何打造「黃金混合生產線」？在實戰中，最強的架構不是全用 Agent，也不是全用 LLM，而是將兩者混搭，各司其職。我們以「智能客服工作流」為例： 讓 Agent 當「廠長」負責決策 (Decision)：接收到客戶訊息後，由 AI Agent 判斷「是否需要回覆？」。如果需要，Agent 會決定去 Database 調出這筆訂單資料。 讓 LLM 當「作業員」負責處理 (Process)：將訂單資訊與客訴內容交給純 LLM 節點，請它專心撰寫一封語氣誠懇的安撫 Email（生成內容）。 讓 Tools 當「輸送帶」確實執行 (Execute)：最後，將 LLM 寫好的信件交給常規的 HTTP / Gmail 節點（不需要 AI），單純負責把信件送出。 這樣一來，Agent 不需要浪費 Token 去寫信，LLM 也不需要負擔決策的壓力，整個 n8n 流程既聰明、穩定又省錢！ 常見問答 (FAQ)Q：為什麼我在 n8n 中使用 AI Agent 執行任務，費用會突然暴增？A：因為 AI Agent 具備「ReAct（推理與行動）」機制。為了解決一個問題，它會在背後不斷自我對話、反覆呼叫工具並驗證結果，每一次的內部迴圈都會消耗大量的 Token。如果沒有嚴格限制它的行動次數或提供精確的 Prompt，成本就會直線上升。 Q：我該如何決定一個新流程要用 LLM 還是 Agent？A：你可以問自己兩個問題：第一，「這個任務的流程是否固定不變？」第二，「任務需要自行判斷並呼叫外部工具來查資料嗎？」。如果流程固定且只需純文字轉換，請召喚 LLM；如果需要多重判斷與操作工具，再指派 Agent。 Q：如果我的 AI Agent 流程一直報錯，該如何優化？A：遇到 Agent 報錯或產生幻覺，首要之務是「把它牢牢限制住」。你可以在 System Prompt 中給予極度明確的目標與角色設定，限制其最大思考與行動次數，並確保給予的 Tools (工具箱) 只有它絕對需要的工具，避免它漫無目的地亂猜。若還是難以 Debug，建議將複雜流程拆解，改用「Agent 決策 + LLM 執行」的黃金混合架構。

使用 n8n 串接 LINE 官方帳號，最彈性且穩定的做法並非依賴專用的第三方節點，而是回歸本質，直接使用基礎的網路傳輸節點： 透過 Webhook 節點 接收來自 LINE 的 Webhook 事件。 透過 HTTP Request 節點 呼叫 LINE Messaging API 來回覆或推送訊息。 這種「不依賴特定模組」的架構，不僅能支援 LINE 最新的 API 功能，在未來擴充與維護上也最為自由。 n8n 串接 LINE 的核心運作架構為何？要建立流暢的自動化回覆，整個資訊流的方向如下： 使用者觸發： 使用者傳送訊息給 LINE 官方帳號。 事件推送： LINE 伺服器將該事件（Event）打包成 JSON，以 POST 方式傳送至你設定的 n8n Webhook URL。 資料解析： n8n 接收後，過濾並解析使用者的訊息內容。 執行回應： n8n 透過 HTTP Request 節點，帶著身分驗證（Token）呼叫 LINE Reply API 或 Push API，將回覆傳送給使用者。 💡 專家提示： LINE 官方文件明確指出，當使用者與官方帳號互動時，LINE 會發送 Webhook Event。而 n8n 的 Webhook 與 HTTP Request 節點完美對應了「接收」與「發送」這兩個必要動作。 開始前，你需要準備哪些開發環境？在建立工作流程前，請確保你已準備好以下兩端的設定： 1. LINE Developers 端請登入 LINE Developers Console，建立並設定你的 Messaging API Channel： 取得 Channel access token（用於 API 呼叫身分驗證）。 取得 Channel secret（用於後續的安全性簽章驗證）。 準備好填寫 Webhook URL 的位置（稍後從 n8n 取得）。 LINE 官方開發入口可參考：LINE Developers 2. n8n 端你需要一個 可從外網透過 HTTPS 存取 的 n8n 伺服器： LINE 的 Webhook 嚴格要求必須是公開的 HTTPS 網址。 請務必使用 n8n Webhook 節點提供的 Production URL（正式網址），Test URL 僅供編輯器內手動測試使用。 若你的 n8n 架設在 Reverse Proxy（如 Nginx、Cloudflare Tunnel）後方，請確保系統環境變數的 Webhook Base URL 設定正確。 實戰教學：3 步驟完成 n8n 與 LINE Webhook 設定步驟 1：建立 n8n Webhook 節點 (接收入口)在 n8n 中新增一個 Webhook 節點，這是整個自動化的起點： HTTP Method: POST Path: 自訂路徑，例如 line-webhook Respond: 設為 Immediately 或 Using Respond to Webhook Node（建議盡速回應 200 OK）。 設定完成後，複製節點上的 Production URL（例如：https://your-domain.com/webhook/line-webhook）。將此網址貼回 LINE Developers Console 的 Webhook URL 欄位並啟用，同時點擊 Verify 測試連線。 步驟 2：加入資料分流與判斷 (IF / Switch)LINE 送來的事件很多種（加入好友、封鎖、文字訊息、圖片等）。透過 IF 或 Switch 節點，過濾出你想處理的事件，例如僅處理文字訊息： 條件設定：{{ $json.body.events[0].type }} === "message" 條件設定：{{ $json.body.events[0].message.type }} === "text" 步驟 3：設定 HTTP Request 節點 (回覆訊息)過濾出文字後，使用 HTTP Request 節點呼叫 LINE Reply API： Method: POST URL: https://api.line.me/v2/bot/message/reply Authentication: 可使用 Header Auth 或直接在 Headers 手動加入。 Headers: Authorization: Bearer {{你的_CHANNEL_ACCESS_TOKEN}} Content-Type: application/json Body (JSON):123456789{ "replyToken": "={{$json.body.events[0].replyToken}}", "messages":[ { "type": "text", "text": "你剛剛說的是：{{$json.body.events[0].message.text}}" } ]} ⚠️ 絕對不能省的 Content-Type 設定：雖然你已經設定了 Bearer Auth 來驗證身分，但 **務必手動加上 Content-Type: application/json**。Authorization 管的是「你是誰」，而 Content-Type 是告訴 LINE「你送的資料格式」。如果漏掉這行，LINE API 非常容易直接回傳 400 Bad Request 錯誤。 資訊安全必備：如何在 n8n 實作 LINE 簽章驗證？為了防止惡意攻擊者偽造 LINE 的請求打爆你的 Webhook，LINE 官方強烈建議驗證請求標頭中的 x-line-signature。 簽章驗證官方文件可參考：Verify webhook signature 在 n8n 的實作步驟： 開啟原始內容： 在 Webhook 節點設定中開啟 Raw Body 選項，因為簽章驗證必須使用「完全未經解析的原始 Request Body」，若經過 JSON Parser 重整，計算出的雜湊值就會出錯。 加密運算： 加入 Crypto 節點，選擇 HMAC-SHA256 演算法。 設定密鑰： 將 LINE 的 Channel secret 作為加密 Key，對 Raw Body 進行加密。 編碼與比對： 將加密結果轉為 Base64 格式，並使用 IF 節點比對是否與 Header 中的 x-line-signature 完全一致。 進階實用情境：圖片處理與主動推播當你的基礎文字 echo bot 跑起來後，可以嘗試擴充以下業務邏輯： 1. 接收與處理圖片 (Image Handling) 事件觸發後取得 message.id。 透過 HTTP Request 發送 GET /v2/bot/message/{messageId}/content 取得圖片。 將下載的圖片串接後續節點（如上傳至 Google Drive、S3，或丟給 AI Vision 進行影像分析）。 2. 主動推播通知 (Push Messages)不需等待使用者講話，只要你有對方的 userId，就能利用 Push API 主動發送訊息。非常適合用於：電商訂單狀態更新、報名成功通知、定時提醒或 AI 每日摘要推播。 邁向企業級：如何規劃高擴充性的 n8n 自動化架構？如果你打算打造正式商業用的 LINE 自動化系統，建議將 n8n 工作流拆分為「兩層式架構」： 入口層 (Gateway Workflow)：專門負責 Webhook 接收、簽章驗證、回覆 HTTP 200 OK 給 LINE（避免超時），並將事件標準化後，透過子工作流 (Execute Workflow node) 傳遞下去。 業務層 (Business Workflows)：根據事件類型觸發不同的業務邏輯。例如：FAQ 智能客服 (串接 OpenAI)、會員資料寫入 (串接 Google Sheets / CRM)、預約系統建立 (串接 Notion / Airtable)。 這樣拆分的好處是：不僅能大幅降低 LINE Reply Token 逾時的風險，未來擴充任何 AI 工具或資料庫都會變得異常輕鬆。 常見問答 (FAQ)Q：HTTP Request 節點已經設定了 Bearer Auth，還需要手動加上 Content-Type 嗎？A：需要，強烈建議手動加上！ Authorization: Bearer xxx 僅負責身分驗證，而 Content-Type: application/json 是告訴 LINE 伺服器你傳送的資料格式。雖然某些 n8n 版本在 Body Type 選擇 JSON 時會自動補上，但為了避免難以除錯的 400 Bad Request 錯誤，手動在 Header 加上 Content-Type 是最穩妥的最佳實務。 Q：為什麼我在 LINE Developers 後台點擊 Verify Webhook，一直測試失敗？A：最常見的原因有兩個：第一，你在 n8n 提供的是 Test URL（僅限編輯模式有效），請務必改用 Production URL 並啟用 (Activate) 該工作流。第二，若你的 n8n 架設在反向代理伺服器（如 Nginx、Cloudflare）後方，請檢查 WEBHOOK_URL 系統環境變數是否有正確設定為對外公開的 HTTPS 網域名稱。 Q：LINE 的 Reply Token 有時效限制，如果我的流程需要很長的運算時間（例如呼叫 AI 整理資料）該怎麼辦？A：LINE 規定 Webhook 必須盡快給予 200 OK 回應，且 Reply Token 的有效時間非常短。實務上的做法是：Webhook 接收後立刻回傳「已收到您的訊息，處理中…」，接著將耗時任務（如 AI 分析）往後丟給非同步流程處理。當資料處理完畢後，改用 Push API 主動推播最終結果給該使用者的 userId。 官方文件延伸閱讀 LINE Developers Verify webhook signature Sending messages

為什麼需要自動化排程？在完成 n8n 的基礎工作流後，如果每次都需要手動點擊「執行 (Execute)」才能運行流程，就失去了自動化的意義。為了讓系統能自動幫我們產出報表、發送 Discord 通知或處理訂單，我們必須為工作流加上排程 (Schedule) 功能。 例如：設定每週一早上 9 點自動產出報表，這才是真正完整的自動化應用。 如何設定 Schedule Trigger 排程節點？要讓工作流定時啟動，我們需要使用 Schedule Trigger 節點來取代原本的手動觸發節點。 移除手動節點：先將原本的「手動觸發 (Manual Trigger)」節點刪除。 新增排程節點：搜尋並新增 Schedule Trigger 節點。 設定觸發規則：將節點連接至工作流後，點開設定。可以設定為「每週 (Weekly)」觸發，並指定時間（例如：每週一上午 9 點 0 分）。 確保排程準確的關鍵：時區 (Timezone) 設定設定好排程後，最常遇到的痛點就是「觸發時間與預期不符（例如晚了或早了好幾個小時）」。這通常是因為伺服器或系統的時區設定錯誤。 檢查與修改步驟：前往 n8n 右上角的 Settings。 確認時區：確認時區是否正確設定為你所在的地區（例如：Asia/Taipei 亞洲/台北）。 為什麼會出錯？：在不同環境（如國外主機）安裝 n8n 時，預設時區可能與本地相差數小時，因此這是上線前必須檢查的重點。 發布 (Publish) 與工作流維護技巧1. 將工作流正式上線 (Publish)排程設定完畢後，必須將工作流切換為 Publish (發布) 狀態。 確保右上角的開關顯示為「綠色的 Publish」。 只有在 Publish 狀態下，Schedule Trigger 才會在背景自動運作；若切換回 Unpublish，則會停止自動排程。 **執行日誌 (Executions)**：上線後，若要查看工作流的運行狀況或除錯 (Debug)，可以切換到 Executions 面板查看歷史執行紀錄與錯誤提示。 2. 使用便利貼 (Sticky Note) 做好註解當工作流越來越長時，過段時間再回來看可能會忘記邏輯。 點擊右側工具欄的 Sticky Note 功能。 在畫布上新增便利貼，可以更改顏色、雙擊輸入文字說明。 應用場景：用來標示「取得資料流程」、「判斷流程」或留下使用說明與備忘錄，能大幅提升工作流的可讀性與後續維護效率。 常見問答 (FAQ)Q：為什麼我的 n8n 排程觸發時間跟設定的完全不一樣？A：這通常是因為 n8n 的「時區 (Timezone)」設定與你所在地區不同。請前往右上角的 Settings，將時區手動校正為正確的位置（如：Asia/Taipei），即可解決時間落差問題。 Q：設定好 Schedule Trigger 後，為什麼時間到了卻沒有自動執行？A：請確認你的工作流是否已經「發布」。在編輯模式 (Edit) 下，工作流不會自動執行。你必須將右上角的狀態切換為綠色的 Publish，排程才會正式生效。 Q：工作流節點越來越多，該如何標註說明方便未來維護？A：強烈建議使用 n8n 內建的 Sticky Note (便利貼) 功能。你可以為不同區塊的工作流加上底色標記與文字註解，例如標明「資料處理區」或「通知發送區」，能大幅降低未來檢修的困難度。

為什麼要在 n8n 中引入 Code 節點？在自動化工作流中，當我們使用節點過濾並梳理好資料後（例如成功撈取出 16 筆已預訂的訂單），往往會需要進行進階的數值計算，像是「計算所有訂單的總價值」。這時，純粹的無程式碼 (No-code) 節點可能無法滿足複雜的運算需求，我們就可以透過加入 Code 節點 並撰寫 JavaScript 來達成目的。 Code 節點的兩大核心執行模式在 n8n 中新增 Code 節點後，系統會要求你選擇執行模式。了解這兩種模式是確保資料正確處理的關鍵： Run once for all items (對所有項目執行一次)： 將所有輸入的資料作為一個群組（陣列）一次性處理。非常適合用來做「總和計算」或「跨資料比對」[00:02:06]。 Run once for each item (對每個項目逐一執行)： 針對流入節點的每一筆資料單獨執行一次程式碼。適合用來做單筆資料的格式轉換或清理。 對於計算訂單總和的情境，我們必須選擇 Run once for all items。 避開陷阱：掌握 n8n 特有的資料結構在 n8n 中處理程式碼時，最常遇到的挫折就是資料格式錯誤。 獨特的物件陣列 (Object Array)n8n 節點之間傳遞資料的模式是非常特殊的「物件陣列」，它雖然長得有點像 JSON，但有其嚴格的規範。如果你在撰寫或回傳資料時沒有遵照 n8n 的 Data Structure（資料結構），系統就會直接報錯。 程式碼貼上技巧為了避免不必要的錯誤，當你要貼上已經寫好的 JavaScript 程式碼時，請務必按照以下步驟操作： 點擊輸入區塊。 全選並刪除所有預設的內容，確保輸入框完全乾淨。 貼上你的程式碼。 123456// n8n Code 節點範例：計算總和 (需符合 n8n return 格式)let totalValue = 0;for (const item of $input.all()) { totalValue += item.json.orderValue || 0;}return [{ json: { totalOrderValue: totalValue } }]; 不會寫程式？讓 AI 成為你的得力助手！如果你對 JavaScript 不熟悉，也不用擔心！在 AI 時代，你不需要成為工程師也能打造低程式碼 (Low-code) 工作流。你只需要將 n8n 的資料結構規範以及你的運算需求（例如：「幫我把陣列中的 book 訂單價值加總」）交給 AI (如 ChatGPT 或 Gemini)，AI 就能為你生成精確且符合 n8n 格式的程式碼。這大幅降低了從無程式碼跨越到低程式碼的門檻。 常見問答 (FAQ)Q：不會寫程式也能使用 Code 節點嗎？A：絕對可以！現今可以利用 AI 工具輔助，只要清楚描述你的需求與 n8n 的資料結構，AI 就能幫你產出正確的 JavaScript 程式碼，你只需複製貼上即可。 Q：Code 節點的執行模式該如何選擇？A：如果你需要將所有資料加總計算（例如本教學中的計算訂單總和），請選擇「Run once for all items」；若是需要對單一項目逐一處理或格式化，則選擇「Run once for each item」。 Q：為什麼貼上程式碼後會一直出現 Error？A：n8n 使用獨特的物件陣列 (Object Array) 格式傳遞資料，與一般 JSON 略有不同。強烈建議在貼上程式碼前，先「全選並刪除」原本編輯器內預設的程式碼，確保輸入框乾淨後再貼上，以避免結構格式衝突。

為什麼你需要學會資料篩選？在自動化流程中，我們時常會從前一個節點（如 Webhook 或資料庫）接收到大量的原始資訊。然而，並非所有資訊都是後續流程所需要的。例如，你可能只需要「訂單編號」與「員工姓名」，而不需要價格、狀態等雜訊。 若不進行篩選，直接將所有資料塞入後端表格，會導致資料庫臃腫且難以維護。透過 n8n 的 Set 節點，我們可以像過濾器一樣，只留下真正有價值的數據。 如何使用 Set (Edit Fields) 節點？1. 新增並設定 Set 節點在流程中點擊 + 號，搜尋並加入 Edit Fields (Set) 節點。 2. 切換至手動映射 (Manual Mapping)進入節點設定後，你會看到兩種模式：JS 與 Manual Map。請選擇 Manual Map，這能讓你直觀地透過拖放來選擇欄位。 3. 挑選關鍵欄位從左側的輸入預覽中，將你需要的欄位（例如 orderID、employeeName）拉動至右側的輸出設定中。 4. 關閉「包含其他欄位」 (Include Other Fields)這是最關鍵的一步！請確保將 Include Other Fields 選項設為 **False (關閉)**。 開啟時： 會保留所有原始欄位並新增你設定的欄位。 關閉時： 輸出的資料將僅包含你剛剛手動挑選的那幾個欄位。 1234567// Set 節點處理後的資料結構範例[ { "orderID": "10248", "employeeName": "Vinsset" }] 將優化後的資料同步至 Airtable完成資料篩選後，你需要調整輸出的目的地： 建立新表： 在 Airtable 中建立一個新的工作表（例如 processed_orders）。 定義欄位： 根據你在 Set 節點篩選的欄位，在 Airtable 建立對應的欄位名稱（如 orderID 設為數字類型，name 設為單行文字）。 連接流程： 將 Set 節點的輸出連接至 Airtable 節點，並選擇剛才建立的新表。 執行流程後，你會發現原本混亂的 14 筆訂單，現在以最精簡、清晰的格式呈現在你的資料庫中。 常見問答 (FAQ)Q：為什麼我用了 Set 節點，輸出的資料還是有一堆用不到的欄位？A：請檢查節點內的 Include Other Fields 開關。若此選項開啟，n8n 會預設傳遞所有原始欄位。請將其關閉，才能達到精確篩選的效果。 Q：Set 節點可以修改欄位的名稱嗎？A：可以。在 Manual Map 模式下，你可以自定義輸出的 Key 名稱，並將左側的原始資料對應進去，這對於整合不同格式的系統非常有用。 Q：如果我想對篩選後的數字進行計算（如加總訂單額）該怎麼辦？A：Set 節點主要用於「定義」與「過濾」欄位。若需要進行複雜運算，建議在 Set 節點之後接續一個 Code 節點（使用 JavaScript）來處理計算邏輯。

為什麼需要在寫入資料庫前進行「條件過濾」？在上一堂課程中，我們成功透過 HTTP Request 節點從 API 取得了 30 筆訂單資料，並將它們全部寫入 Airtable 中。然而在實務應用上，這並非最佳做法。 我們其實不需要將「所有」訂單都存入資料庫，而是只需要處理特定狀態的訂單。例如，我們只想挑出 orderStatus 為 processing（處理中）的訂單，而忽略狀態為 booked（已預訂）的資料。透過條件過濾，不僅能讓資料庫保持整潔，更能節省運算資源與 API 傳輸時間。 如何在 n8n 中加入並設定 If 節點？為了達到分流資料的目的，我們可以使用 n8n 中的 If 節點 來處理條件邏輯。 步驟一：中斷原有流程並插入 If 節點 游標移至 HTTP Request 與 Airtable 節點之間的連線。 點擊垃圾桶圖示（Delete）刪除原有的直接連線。 點擊 + 號，搜尋並新增一個 If 節點。 步驟二：設定條件邏輯 (Expression)進入 If 節點的設定畫面後，我們需要告訴系統「判斷的標準」是什麼： 點擊 Add Condition。 針對 Value 1，點擊 Expression 模式。 從左側的資料面板中，將前一個節點抓取到的 orderStatus 欄位拖拉進來，此時會自動產生變數語法：1{{ $json.orderStatus }} 設定判斷條件：選擇 String 類別下的 **is equal to**（等於）。 針對 Value 2，輸入我們想要篩選的目標字串：processing。 步驟三：測試與檢驗分流結果點擊 Execute Step（執行節點）。執行完畢後，你可以在 Output 面板看到資料被成功分流： True Branch（真分支）： 包含 14 筆 orderStatus 為 processing 的訂單。 False Branch（假分支）： 包含 16 筆狀態為 booked 的訂單。 如何將篩選後的資料正確寫入 Airtable？既然我們已經把資料分流，接下來只要將符合條件的資料送進資料庫即可。 連接正確的分支： 從 If 節點的 true 輸出端點，拉一條線連接至原有的 Airtable 節點。 清理舊資料： 回到你的 Airtable 介面，將先前測試時一次塞入的 30 筆舊資料全選並刪除（Delete all selected orders）。 重新執行工作流： 回到 n8n，點擊下方的 Execute Workflow 完整跑一次流程。 驗證結果： 此時回到 Airtable 或查看 Airtable 節點的 Output，你會發現系統只精準寫入了那 14 筆 processing 狀態的訂單，且每個欄位（如建立時間、ID、名稱等）皆正確對應。 下一步優化：為什麼我們該精簡傳輸的欄位？目前我們雖然過濾了訂單狀態，但仍把每一筆訂單的「所有欄位」都傳進了 Airtable。 如果在只有 14 筆資料、5 個欄位的情況下，效能差異並不明顯；但當企業成長到數千筆訂單、數十個欄位時，傳輸不需要的資料會大幅拖慢運算速度、拉長資料傳輸時間，並佔用過多 Airtable 的儲存空間。 因此，在下一個章節中，我們將教你如何進一步過濾，只提取我們真正需要的欄位（例如：員工姓名與訂單編號）來進行後續處理。 常見問答 (FAQ)Q：在 n8n 中，If 節點與 Switch 節點有什麼不同？A：If 節點主要用於處理布林邏輯（True / False），適合單一條件的二分法過濾（例如：狀態是否為處理中）。若你需要依據多種不同的狀態（例如：處理中、已出貨、已退款）將資料分流到三個以上的不同工作流程，使用支援多個輸出連接器的 Switch 節點會更加合適。 Q：如果我想設定多個過濾條件可以嗎？A：可以的。在 If 節點的設定中，你可以點擊 Add condition 來新增多個條件，並設定它們之間的邏輯關係為 AND（必須全部符合）或 OR（符合其中一項即可），以滿足更複雜的商業邏輯。 Q：為什麼不建議把 API 抓到的所有資料直接塞進資料庫保留備用？A：寫入過多非必要資料會大量消耗系統算力，導致資料傳輸速度變慢且耗時更長。此外，雲端資料庫（如 Airtable）通常有儲存空間與紀錄筆數的限制。精準過濾所需的資料與欄位，是維持自動化工作流高效運作的關鍵最佳實踐。