Day 22 把整個自動化流程想清楚了：使用者結束對話 → 前端打一個 Webhook → n8n 接手後面的處理。今天要把第一步做出來——在 n8n 建立一個真正能接收資料的 Webhook，確認對話資料真的能從前端送到 n8n 手上。

今天的目標不求做完整個流程，只求打通第一關：資料送得過去、n8n 收得到、格式是對的。

建立 Webhook 節點

打開 n8n，新建一個 Workflow，從左側節點列表拉出 Webhook 節點當作第一個 Trigger。

設定上要決定兩件事：

HTTP Method：選 POST。這點完全對應到 Day 15 建立的判斷標準——前端要「送出」一整包對話資料給 n8n，這是會讓對方「處理新東西」的動作，不是單純查詢，所以用 POST。
Path：給這個 Webhook 一個好認的路徑，例如 /conversation-finished，n8n 會自動拼成一個完整的網址。

存檔之後，n8n 會顯示兩個網址：一個是測試用（Test URL），一個是正式啟用後才會生效的（Production URL）。今天先用測試網址,確認流程沒問題之後,才會換成正式版。

先用 Postman 驗證，而不是直接改前端程式碼

這裡用到 Day 16 學的方法論：不要一次把兩個不確定的東西（前端程式碼對不對、Webhook 設定對不對）綁在一起測試，先用 Postman 單獨驗證 Webhook 本身能不能正常收資料。

用 Postman 組一個 POST 請求，網址填 n8n 給的測試網址，Body 放一段模擬的對話紀錄 JSON（幾句使用者跟 AI 的往來訊息）。按下 Send 之後，回到 n8n 畫面，點一下「監聽測試事件」,就能看到剛剛送出的那包 JSON 整個被接收下來，顯示在 Webhook 節點的執行結果裡。

看到資料真的從 Postman 跑到 n8n 畫面上的那一刻，比單純理解「Webhook 是反過來的 API」這個概念有感很多——這是 Day 10 學的東西第一次真正在眼前跑起來。

資料格式要先講好，不然會卡住後面的 Node

測試過程中發現一個問題：我一開始隨便組了一包 JSON 當測試資料，裡面對話紀錄的結構是自己憑感覺寫的，跟實際前端會送出來的格式不一樣。

這讓我意識到，Webhook 這一關雖然看起來只是「接收資料」，但其實必須先跟前端那邊「講好」要送什麼格式過來——這其實又是 Day 9 學的 JSON 設計概念,只是這次要設計的是「對話紀錄」要包含哪些欄位，而不是情境生成的輸出格式。

今天先定下一個簡單版本：一個陣列，每個元素是一則訊息，包含「是誰說的」跟「說的內容」。先求有，堪用就好，之後如果 Day 22 想加的 success_criteria 判斷要用到更多欄位，再回來擴充。

接上第一個處理節點

Webhook 收到資料確認沒問題之後，今天再往下接了一個簡單的節點，試著把收到的對話資料做最基本的整理——把一串訊息陣列轉成一段完整的文字，方便之後 Day 24 要丟給 AI 做分析。

這一步沒有碰到太多問題，比較像是在練習「資料從一個 Node 傳到下一個 Node」的手感，對照 Day 6 當時摸介面的印象，這次操作起來明顯比較有方向。