2026 年的某個週五下午五點，辦公室的空氣逐漸瀰漫著週末的放鬆氛圍。正當我準備將筆電休眠時，老闆的頭從螢幕後方探了出來，輕描淡寫地丟出了一個「小需求」：「Eric 啊，我們下週一早上有個高管會議，你能不能把過去三個月、七位業務在 LINE OA 上的客戶對話，整理成每人一份的銷售行為分析報告？」

手邊的工具只有 n8n、一個已經取得權限的 LINE Official Account (OA) 帳號，以及剛儲值好額度的 OpenAI API。如果是剛入行的新手，可能會覺得「哇，好酷的挑戰！」；但身為在浪花科技打滾多年的資深工程師，我當下的心情只有無聲的崩潰。這絕對不是什麼輕鬆的 ETL (Extract, Transform, Load) 任務，這是一場與髒資料和 AI 幻覺搏鬥的生存戰。

打開電腦，按下計時器。這是一篇充滿血淚的技術復盤，記錄了我如何用 n8n 與 AI，在連續 36 小時沒闔眼的狀態下，把一坨亂麻的 LINE 對話變成讓高管點頭的銷售報告。

第一關：以為兩小時搞定，結果 LINE 資料清洗吃掉一整個下午

很多非技術主管總有一種錯覺：「資料都在 LINE 裡面，用 API 拉出來不就好了？」實際開始動手才發現，LINE OA 的訊息資料拉出來，根本是一場災難。

分頁限制與 API 的無情痛擊

首先是 LINE Messaging API 的限制。2026 年的 API 依然有嚴格的 Rate Limit 和分頁（Pagination）機制。你不可能一個 Request 就把三個月的歷史對話全部倒出來。每次最多只能拿固定的筆數，而且往回撈的邏輯如果沒寫好，很容易陷入無限迴圈或是漏掉關鍵對話。在 n8n 中，我必須架設一個精準的 HTTP Request 輪詢迴圈（Loop），搭配分頁游標（Cursor）來確保每一段對話都被完整拉取下來。

通靈級別的「發言者對應」

更大的坑在後面：這七位業務用的是「同一個」LINE OA 帳號跟不同的客戶對話。LINE 的匯出資料中，並沒有完美標記「這句話是哪一位業務回覆的」。聊天記錄與業務行為的對應關係，幾乎要自己土炮重建。

工程師的囉嗦時間：你以為資料庫都是乾淨的關聯表？現實世界中，業務可能會在對話開頭打個「您好，我是小王」，或者根本不署名。為此，我不得不在 n8n 裡面用 Code 節點（對，就是以前的 Function 節點）寫 JavaScript 來做土炮對應表。寫到第三版，利用 Regex 捕捉關鍵字與時間戳記交叉比對，才終於沒有噴錯。

// n8n Code 節點：處理 LINE 訊息與業務的粗略對應
const messages = $input.all();
const salesMapping = {
  'userId_A': '業務A',
  'userId_B': '業務B'
};
return messages.map(item => {
  let rawData = item.json;
  // 透過邏輯判斷或是預先建立的標籤來識別業務
  rawData.salesName = salesMapping[rawData.handlerId] || '未知業務';
  return { json: rawData };
});

第二關：把對話餵給 AI 摘要，第一次跑出來的結果讓我想掀桌

花了快 8 個小時把資料清洗乾淨、轉換成標準的 JSON 格式後，我天真地以為最痛苦的部分已經過去了。接下來只要把對話串塞進 OpenAI 的 API，請它分析就好，對吧？

第一次跑完 n8n 流程，AI 傳回來的報告簡直讓我想掀桌。七份報告長得幾乎一模一樣，充滿了正確的廢話：「根據您提供的對話，這位業務展現出優秀的溝通技巧」、「該業務能及時回覆客戶問題」。這種報告要是週一早上交出去，我大概週二就會出現在 HR 的面談室裡。

Prompt 不是玄學，是嚴謹的軟體工程

這讓我深刻體認到 Prompt Engineering（提示詞工程） 的核心：如果你給的指令是模糊的，AI 回傳的只會是沒有洞察的「作文」。我立刻著手重構 Prompt：

• 加入角色設定：「你現在是一位嚴格的 B2B 銷售總監…」
• 明確輸出格式：要求以 JSON 格式輸出，必須包含「客戶痛點洞察」、「報價談判技巧評分(1-10)」、「跟進速度評價」等具體欄位。
• 提供判斷維度：不准使用形容詞，必須引用對話中的「具體數字」或「原始對話片段」來佐證結論。

Token 爆炸與 Map-Reduce 救場

改版後的 Prompt 確實讓報告品質直線上升，但隨之而來的是 API 帳單的噩耗。把七個人、三個月的對話直接塞進去，Context Window 撐爆不說，Token 費用直接比預期多出快兩倍。在凌晨三點，我緊急修改 n8n 流程，導入 Map-Reduce 架構：先將每位業務的對話按「週」分批讓 AI 產生微型摘要（Map），最後再把這些微型摘要彙整給 AI 產生最終的季報告（Reduce）。這不僅省下大量 Token，還大幅降低了 AI 的幻覺率。

第三關：n8n 流程跑到一半整個卡住，深夜十二點的除錯現場

就在我以為大功告成，按下 Execute Workflow 準備去泡碗泡麵時，災難發生了。流程在處理第四位業務的資料時，跑到一半直接停住。沒有紅色報錯，沒有 Error Log，就是一個令人毛骨悚然的「沉默失敗」（Silent Failure）。

身為後端工程師，最怕的就是這種不噴錯誤碼的狀況。因為你不知道是 OpenAI API 超時（Timeout）、記憶體溢出，還是資料格式炸了。我只能在 n8n 裡面的每個關鍵節點後方加上 Console Log 節點，然後用小批次（Batch）資料反覆測試。

真相大白時，我差點把滑鼠捏碎。原來某位業務在跟客戶對話時，複製貼上了一長串包含特殊不可見控制字元的產品規格碼，這個隱藏字元導致 n8n 在進行 JSON 解析時直接掛掉，連 Error 都不會吐。

這給我上了一堂寶貴的課：任何沒有錯誤處理機制的工作流，都是定時炸彈。我在流程中緊急加入了 Error Trigger 節點，並在 HTTP Request 啟用自動重試（Retry On Fail）機制，把容易出錯的 JSON 解析放入 try-catch 區塊，這套自動化流程才從「工程師的玩具」正式升級為「企業可用的系統」。

週一早上的驗收：這套系統帶來的震撼教育

週一早上 9 點，七份排版精美的 PDF 報告準時出現在老闆的信箱裡。雖然其中有一兩份因為原始對話實在太少，AI 寫得還是有點乾，但開會時，老闆拿著報告直接問了業務主管三個具體的問題：「為什麼業務 C 在提到價格時，客戶的猶豫期平均比別人多兩天？」

業務主管看著報告上精準的對話引用，震驚地說：「這比我自己花三天看對話紀錄得到的洞察還要深。」那句肯定，讓連續工作三十幾小時的肝痛瞬間緩解了不少。

但這次實戰讓我深刻體悟到三件事：

• 資料底層決定 AI 天花板：LINE 訊息的資料結構天生就不是為了數據分析設計的。如果你前期的資料清洗沒做好，後面的 AI 只會產出垃圾（Garbage In, Garbage Out）。
• AI 整合是一門架構學：在 n8n 中串接 AI，不能只想著一波帶走。大資料量必須切塊、分批處理，並且要有清晰的 Prompt 規格。
• 防呆與容錯是自動化的靈魂：永遠假設外部 API 會斷線、業務會輸入亂碼。沒有重試邏輯與異常捕捉的自動化，只會為工程師帶來無盡的半夜警報。

現實評估：你想複製這套全自動化流程嗎？

如果你們公司的業務也高度依賴 LINE OA 進行客戶互動，且你受夠了人工整理報告的痛苦，這條自動化之路絕對走得通。但入場門票是：你必須願意在前期投入大量的時間去搞懂企業內部髒資料的邏輯，並且具備基礎的 API 與 JSON 處理能力。

帶著正確的期待進入 AI 自動化領域，比帶著「兩小時搞定」的幻想進去，成功率要高得太多了。

推薦延伸閱讀

• 從「會動就好」到流量癱瘓：LINE OA 串接 n8n 與 AI 代理人的 30 天血淚實戰
• 2026 自動化災難現場：n8n 串接 AI Agent 失控怎麼辦？資深工程師的血淚救援實戰
• 導入 AI 代理人半年真實告白：從興奮爆棚到想拔插頭的血淚實戰錄

如果你們公司正計畫導入 n8n、WordPress 與 AI 代理人的自動化流程，但苦於技術門檻或曾踩過各種整合地雷，別讓內部工程師獨自面臨深夜除錯的崩潰。歡迎隨時 聯絡浪花科技，讓專業的技術團隊為您打造穩定、高容錯的企業級自動化系統！