解鎖條件
你對 n8n 感興趣，大概是某天突然意識到：「我每天在重複做同樣的事情。」
也許是每週手動從 Google 表單撈資料貼到 Notion，也許是每次發文前要複製貼上到三個平台，也許只是每天早上要打開五個分頁確認昨晚的系統狀態。這些事不難，但它們佔去你的注意力——而注意力是最貴的消耗品。
n8n 的賣點很明確：開源、可自架、視覺化拖拉就能連結各種服務。我第一次看到截圖時，腦袋裡浮現的是「這不就是我要的作業系統？」
然後我開始用。然後我開始踩坑。
這篇文章不是 n8n 的入門教學，網路上那些已經夠多了。這是一份真實的踩坑紀錄，給那些已經知道 n8n 是什麼、但還沒弄清楚「為什麼我的 workflow 跑不起來」的人。
坑一：API 認證不是你想的那樣
最常見的第一個坑，發生在你嘗試串接第三方服務的時候。
n8n 的 Credentials 系統看起來很友善，填入 API Key、選好 OAuth，按下 Test Connection，綠燈亮起——搞定了，對吧？
不對。
真正的問題在於：Test Connection 測的是「連線本身」，不是「你的 token 有沒有對應的權限」。
我的第一個教訓來自 Google Calendar API。Token 測試通過，workflow 也順利觸發，但到了實際寫入行程那步，整個 workflow 靜靜地失敗了，沒有錯誤提示，只有一個空的 response。排查了三十分鐘才發現：我的 OAuth scope 只有 calendar.readonly，沒有 calendar.events。
心法一：永遠去 API 服務商的官方文件確認 scope，不要只看 n8n 內建的設定欄位。 n8n 的 UI 無法替你驗證 scope 是否正確，它只確認 token 的格式是對的。
第二個認證坑是 token 失效。OAuth token 有過期時間，n8n 會自動嘗試 refresh，但前提是你的 Credentials 設定裡有正確儲存 refresh token。如果你是用「貼上 Access Token」的方式快速測試，記得：那個 token 大概一小時後就沒用了，你的排程 workflow 到了凌晨會靜靜地躺平。
坑二：資料格式是隱形的攔路虎
n8n 的資料流概念說起來簡單：每個 node 的 output 傳給下一個 node，資料以 JSON 格式流通。但這個「簡單」會在兩個地方讓你卡住。
第一個：陣列 vs 物件的混淆。
很多 API 回傳的不是單一物件，而是陣列——即使只有一筆資料，也會用 [{...}] 包起來。n8n 有個自動展開陣列的行為（叫做 “Split Into Items”），它會把陣列拆成一筆一筆的 item 往下傳。這通常很方便，但有時候你不想要它，比如你想把整包資料傳給下一個 node 做聚合處理。
搞不清楚當下資料的「形狀」，後面每一步都是猜謎。
解法： 用 n8n 的 debug 模式執行一次，點開每個 node 的 output 確認資料結構，不要憑直覺推測。這不是廢話，很多人跳過這步。
第二個：日期格式的地獄。
不同服務對日期的期望格式完全不同。有的要 Unix timestamp（秒）、有的要毫秒、有的要 ISO 8601、有的要 YYYY/MM/DD。n8n 內建的 DateTime node 可以做格式轉換，但問題是你要先知道「目標服務要什麼格式」，而這通常要去翻 API 文件的角落。
我最慘的一次是串接一個日本的服務，它的文件寫著接受 ISO 8601，但實際上只認 YYYY-MM-DDTHH:mm:ss+09:00 這種帶時區的格式，少了時區就回傳 400。
心法二：遇到日期相關的欄位，先用 Code node 印出你打算傳的值，確認格式完全符合文件的範例，再繼續往下蓋。
坑三：執行時序比你想的複雜
自動化的美夢，是「觸發 → 執行 → 完成」。但現實是，很多 workflow 需要等待——等 API 回應、等上游資料更新、等另一個 workflow 跑完。
n8n 處理這類場景的方式有幾種：Wait node、排程觸發、Webhook 回呼。但在你搞清楚這三個的邊界之前，很容易掉進兩個坑。
坑 A：以為排程會等前一次跑完才執行。
n8n 的排程觸發（Cron）是時間到了就觸發，不管前一次有沒有結束。如果你的 workflow 要跑三分鐘，但你設了每兩分鐘跑一次，就會出現多個執行實例同時運行，互相踩資料的狀況。
解法是在設計之初就評估執行時間，或是加上一個「鎖定機制」（可以用外部 KV store 或 n8n 自己的 Static Data 功能模擬）。
坑 B：以為 Webhook 回應後會繼續跑。
有些 n8n workflow 的設計是：接收外部 Webhook → 做一堆事 → 回傳結果。但 Webhook node 預設的行為是「收到請求就立刻回 200」，不等後面的 node 跑完。如果你需要讓呼叫方等待 workflow 的最終結果，要用「Respond to Webhook」node，而不是依賴預設行為。
心法三：用白板把 workflow 的時間軸畫出來，標明哪些步驟是「非同步」的，哪些需要等待，再決定要用哪種 node 組合。 不畫圖直接寫，之後除錯的代價會更高。
Before / After：同樣的 workflow，兩種結局
Before（踩坑版）： 啟動一個「每天 9am 自動發文到三個平台」的 workflow。測試環境跑得順，上線後第三天開始，偶爾有平台發不出去，沒有錯誤通知，只有用戶反映沒看到貼文。排查一週後才找到：OAuth token 在第三天到期，而我沒有設定錯誤通知，workflow 靜靜失敗。
After（有設計的版本）：
- Credentials 都檢查 scope 和 refresh token 有效性
- 每個對外 API 呼叫後加 Error 分支，失敗時發 Telegram 通知
- 在 Notion 或 Airtable 記錄每次執行狀態（成功/失敗/跳過）
- 排程執行時間設為「間隔 > 最長執行時間的 1.5 倍」
這個「After 版本」多花了兩倍的設計時間，但之後再也沒有靜默失敗。
收斂反思
n8n 很強，但它不是魔法。它是一個把複雜度從「寫程式」轉移到「理解資料流 + 系統邊界」的工具。如果你以為拖拉幾個 node 就能上線跑，那你會踩完上面列的每一個坑。
真正進入「真香」狀態的關鍵，不是用過多少個 node，而是建立一套「可觀測的 workflow 設計習慣」：
- 每個對外呼叫都有錯誤分支
- 每次執行都有狀態記錄
- 日期、格式、權限，先確認再動工
一旦這三件事成為你的預設動作，n8n 才真的開始替你省時間——而不是讓你花更多時間在追謎。
自動化的本質是把你從重複勞動中解放，但前提是你得先把「規則」搞清楚，不然你解放的不是自己，是 bug。