在前面的七天裡，我們從不同角度探索了 n8n 的強大功能：我們學會了如何處理影片上傳、建立錯誤監控系統、串接 Webhook 接收即時訊息，並且打造了能夠跨平台運作的智慧助理。這些看似獨立的主題，其實都圍繞著一個核心概念：如何讓工作流更健壯、更智慧、更貼近真實需求。
今天這篇文章，我們將把這七天的內容進行重點整理。
我們會把相似的主題放在一起比較、把分散的知識點串連起來，幫助你建立一個更完整的知識架構。
| 節點類型 | 圖文設定 | 影片設定 |
|---|---|---|
| FB 粉專 | 直接發布，文案用caption參數 |
也是直接發布，文案用description參數 |
| IG | media_type: IMAGE、image_url: 圖片連結 |
media_type: REELS、video_url: 影片連結、Host URL: Video uploads |
| Threads | media_type:IMAGE、image_url: 圖片連結 |
media_type: VIDEO、video_url: 影片連結 |
| 錯誤類型 | 發生原因 | 解決方案 | 實作節點 |
|---|---|---|---|
| Supabase Duplicate | 重複上傳同一檔案 | 上傳前先檢查檔案是否存在 | Supabase Search → Code 判斷 → If 分流 |
| Container Not Ready | 影片打包需要時間 | 發布前確認 container 狀態 | HTTP Request 查詢狀態 → If 判斷 → Wait 等待 |
Container 狀態查詢 URL：
| 平台 | API Endpoint |
|---|---|
| IG | https://graph.facebook.com/v23.0/{container_id}?fields=status_code |
| Threads | https://graph.threads.net/v1.0/{container_id}?fields=status_code |
| 特性 | 說明 |
|---|---|
| 觸發時機 | 只在自動執行的工作流出錯時觸發 |
| 啟用需求 | 不需要手動啟用（Active） |
| 測試方式 | 無法手動測試 |
| 綁定方式 | Settings → Error Workflow → 選擇錯誤處理工作流 |
| 應用範圍 | 可讓多個工作流指向同一個錯誤處理流程 |
| 步驟 | 節點 | 功能 |
|---|---|---|
| 1. 接收錯誤 | Error Trigger | 自動捕捉錯誤訊息 |
| 2. AI 診斷 | AI Agent | 白話文解釋錯誤、提供 2-3 個具體修正建議 |
| 3. 記錄錯誤 | Google Sheet (Append Row) | 寫入錯誤儀表板 |
| 4. 即時通知 | Discord | 推送錯誤摘要與建議 |
錯誤儀表板欄位設計：
| 欄位名稱 | 內容 |
|---|---|
Timestamp |
錯誤發生時間 |
workflow_name |
出錯的工作流 |
workflow_url |
執行紀錄連結 |
failedNode_name |
失敗的節點 |
raw_ErrorMessage |
原始錯誤訊息 |
AI_Suggestion |
AI 分析建議 |
| 應用場景 | 角色定位 | 主要功能 | 關鍵欄位 |
|---|---|---|---|
| 指令面板 | 發文控制台 | 預先規劃貼文內容與風格 | file_name, style, status, priority |
| 錯誤儀表板紀錄 | 系統健康追蹤 | 記錄所有錯誤事件 | Timestamp, workflow_name, AI_Suggestion |
| AI Agent 的資料庫 | Tool Integration | 提供 AI 查詢資料（如中獎號碼） | 依應用場景設計 |
| 操作類型 | 節點 | 使用時機 | 特性 |
|---|---|---|---|
| 讀取 | Read Row(s) | 取得任務清單、查詢資料 | 可設篩選條件(一列 = 一個 item) |
| 寫入 | Append Row | 新增錯誤記錄、發票資訊 | 每個 item 寫入一列 |
| 更新 | Update Row | 更新任務狀態、回寫 URL | 需指定定位欄位，找到要更新的列 |
| 情境 | 是否適用 Google Sheet | 建議方案 |
|---|---|---|
| 小型專案、快速原型 | ✅ 適用 | Google Sheet |
| 內容量大、頻率高 | ❌ 不適用 | Supabase, Airtable |
| 需複雜查詢 | ❌ 不適用 | 專業資料庫 |
| 教學示範 | ✅ 適用 | Google Sheet |
| 概念 | 比喻 | 說明 |
|---|---|---|
| Webhook | 瓦斯管路 + 地址 | 資料流動的管道與目的地 |
| 送出訊息 | 瓦斯公司 → 用戶 | 用對方的 Webhook URL |
| 接收訊息 | 用戶收瓦斯 | 用自己的 Webhook URL |
關鍵規則：要把 A 的資料傳到 B，就在 A 設定 B 的 Webhook URL
| URL 類型 | 使用階段 | 啟用方式 | 查看方式 | 適用情境 |
|---|---|---|---|---|
| Test URL | 開發測試 | 點選「Listen for test event」 | 節點介面直接顯示 | 開發、除錯 |
| Production URL | 正式上線 | 工作流設為 Active | Executions 頁籤查看 | 正式環境 |
重要：切換 URL 類型時，需重新綁定並驗證外部服務
| 步驟 | LINE | Facebook Messenger |
|---|---|---|
| 複雜度 | 簡單 | 複雜 |
| 核心流程 | 1. 貼 Webhook URL2. 點選 Verify | 1. 建立 Webhook Trigger (GET) →2. 添加 Respond to Webhook 節點→3. 回傳 hub.challenge →4. 填入驗證權杖→ 5. 可能需驗證兩次 |
| 特殊要求 | 無 | 需回傳 hub.challenge 驗證 |
| 訊息類型 | LINE | Facebook Messenger |
|---|---|---|
| 文字訊息 | message.type: text、message.text: 內容 |
body.entry[0].messaging[0].message.text |
| 圖片訊息 | message.type: image、message.id: 圖片 ID |
body.entry[0].messaging[0].message.attachments[0].payload.url |
| 判斷方式 | 檢查 message.type |
檢查是否有 attachments |
| 平台 | 方法 | HTTP 設定 |
|---|---|---|
| LINE | 透過 API 取得 | Method: POST、URL: https://api-data.line.me/v2/bot/message/{message.id}/content、Auth: LINE Bearer |
| Messenger | 直接下載 | Method: GET、URL: 回傳的圖片 URL、Response format: File |
| 方式 | 使用時機 | 識別方式 | 特性 | API Endpoint |
|---|---|---|---|---|
| Reply | 回覆剛收到的訊息 | replyToken |
只能用一次、時效短 | /v2/bot/message/reply |
| Push | 主動推送訊息 | userId |
隨時可用、無次數限制 | /v2/bot/message/push |
| 項目 | 說明 |
|---|---|
| API | Facebook Graph API |
| 節點 | Graph API 節點 或 HTTP Request |
| 識別方式 | sender.id |
| 特性 | 統一方式，較直觀 |
| 階段 | 主要動作 | 使用節點 |
|---|---|---|
| 1. 接收 | 透過 Webhook 接收訊息 | Webhook Trigger |
| 2. 判斷 | 提取關鍵欄位→根據訊息類型分流 | Edit Fields→If / Switch |
| 3. 處理 | 文字 → AI 分析；圖片 → Gemini 辨識 | AI Agent、Gemini Analyze Image |
| 4. 回覆 | 透過對應 API 回傳 | HTTP Request / Graph API |
重點：不同平台的差異主要在「接收」與「回覆」，「處理」邏輯大致相同
| 應用場景 | AI 任務 | 關鍵技巧 |
|---|---|---|
| 錯誤診斷 | 解讀錯誤並提供建議 | Output Parser 輸出 JSON |
| 發票辨識 | 從圖片擷取發票資訊 | Gemini Analyze Image |
| 記帳分析 | 提取消費項目與金額 | Structured Output Parser |
| 發票對獎 | 比對中獎號碼 | 掛載 Google Sheet Tool |
| 智慧客服 | 回答問題並推薦商品 | 掛載 Memory 記住脈絡 |
| 功能 | 用途 | 設定方式 | 適用場景 |
|---|---|---|---|
| Output Parser | 將 AI 輸出轉為結構化資料 | 開啟 Require Specific Output Format→添加 Structured Output Parser |
需寫入資料庫、需進行後續處理 |
| Tool Integration | 讓 AI 查詢外部資料 | 在 Tool 分支添加工具（如 Google Sheet Tool） | 需即時查詢資料（如商品庫存、中獎號碼） |
| Memory | 記住對話脈絡 | 在 Memory 分支添加 Simple Memory → 設定 Session Key（用戶 ID） | 多輪對話、需理解上下文 |
| 項目 | 說明 |
|---|---|
| 問題 | AI 只看單一訊息，無法理解上下文 |
| 解決方案 | 使用 Memory 記錄對話歷史 |
| Session Key | 用戶 ID，區分不同使用者的記憶 |
| 運作方式 | AI 回覆時自動抓取對應用戶的對話歷史 |
| 階段 | 動作 | 節點 |
|---|---|---|
| 1. 接收訊息 | 取得文字或圖片 | Webhook Trigger |
| 2. AI 判斷 | 判斷是否符合處理邏輯 | AI Agent / Gemini |
| 3. 分流處理 | 符合 → 繼續執行；不符合 → 回覆說明並中止 | If 節點 |
| 判斷類型 | 使用節點 | Prompt 重點 | 輸出格式 |
|---|---|---|---|
| 圖片判斷（是否為發票） | Gemini Analyze Image | 判斷是否為電子發票 | {"is_invoice": true/false} |
| 文字判斷（是否為記帳） | AI Agent | 判斷是否與消費記帳有關 | {"is_expense": true/false} |
| 情境 | 無保險機制 | 有保險機制 |
|---|---|---|
| 收到貓咪照片 | 誤判為發票，寫入錯誤資料 | 回覆「這不是發票喔！」 |
| 收到「哈哈哈」 | 嘗試提取消費金額，流程報錯 | 回覆「我只能幫你記帳喔！」 |
| 收到貼圖 | 無法處理，整條流程中斷 | 禮貌回覆說明 |
| 節點類型 | 主要功能 | 常見應用 | 注意事項 |
|---|---|---|---|
| Edit Fields | 提取、重新命名、轉換欄位 | 從複雜結構提取關鍵資料 | 保持命名清晰 |
| Code | 執行 JavaScript | 轉換資料格式、篩選 item | 善用 console.log 除錯 |
| Split Out | 將陣列拆分成多個 item | 多筆記帳項目分別寫入 Sheet | 每個 item 獨立處理 |
| Merge | 合併不同節點的資料 | 整合多個平台發文 URL | 選擇適當的合併模式 |
| 節點 | 適用情境 | 優勢 | 範例 |
|---|---|---|---|
| If | 二選一 | 簡單直觀 | 檔案是否存在 |
| Switch | 多選一（3+ 選項） | 避免冗長的 If 鏈 | 文案風格選擇（4 種） |
| Router | 同時執行多分支 | 並行處理 | 同時發布到多平台 |
| 服務 | 憑證類型 | 命名建議 | 用途區分 |
|---|---|---|---|
| Google Sheet | OAuth2 | Google_Sheet_Main |
主要資料管理 |
| Google Drive | OAuth2 | Google_Drive_Media |
媒體檔案 |
| LINE | Bearer Token | LINE_Bot_Accounting |
記帳機器人 |
| FB/IG | Page Access Token | FB_Page_Post / FB_Page_Reply |
發文 / 回覆 |
| Threads | Bearer Token | Threads_Bot |
Threads 機器人 |
| 層次 | 處理策略 | 實作方式 |
|---|---|---|
| 第一層：預防 | 事前檢查 | 上傳前檢查檔案、發布前確認 container、AI 判斷訊息有效性 |
| 第二層：狀態判斷 | 動作後確認 | If 判斷成功/失敗、失敗時更新狀態為 Error |
| 第三層：全域監控 | Error Trigger | AI 診斷、寫入錯誤儀表板、即時通知 |
在這七天裡，我們學到的不是工具，而是方法。我們用節點拆解問題，用條件判斷邏輯，用 AI 補上人類的判斷力，一步步把「想法」轉化為能真實運作的流程。
從影片自動化、錯誤監控、Webhook 到 AI Agent，每一次實作，都是在學會如何讓系統理解你的思維方式。而當你開始能夠設計自己的流程時，你已經不只是使用 n8n，而是在建立屬於自己的「自動化語言」。
明天，我想帶你進入下一個階段：試著從生活中那些重複卻必要的動作開始，
觀察、拆解、抽象化，把它們轉譯成一條條能自己運作的工作流。因為最強大的自動化，不只是節點的連線，而是讓每個流程都更貼近——你真正想完成的事。
iThome鐵人賽
看影片追技術