昨天，我們教會了 n8n 「傾聽」外部世界 —— 透過 Webhook，即時接收使用者訊息，讓工作流不再只是被動地等待排程，而能在事件發生的瞬間自動啟動。

今天，我們要更進一步，讓 n8n 「看得懂」外部世界。

現代的自動化，不只是處理文字而已。在真實場景中，我們也會收到大量的圖片——像是收據、發票、截圖、表單拍照……如果能讓 n8n 自動判斷圖片內容、把資料妥善歸檔，甚至主動執行後續任務，那就能讓你的 LINE 助理更像一位真正的「智慧秘書」。

因此，今天我們要打造一個 “閹割版”的發票管理員（因為我沒辦法接財政部 API 😅，不然可以加更多功能），但他依然能幫你做到這些事：

1. 讓 LINE 使用者上傳發票圖片到聊天室
2. n8n 自動判斷圖片是否為發票，是的話將上傳到雲端並記錄在試算表中
3. 使用 AI Agent 對發票號碼進行「自動對獎」，並將對獎結果通知使用者

而這一切，仍舊是建立在同一個核心：Webhook。

以下是今天最終會完成的工作流示意圖：

準備好了嗎？讓我們一起準備讓這位(閹割版)發票管理員正式上線吧

一、從文字訊息到影像訊息的升級 : Line Webhook 圖片處理

昨天的範例中，我們只處理了使用者透過官方帳號傳遞的「文字訊息」。
今天，我們要再進一步升級——讓工作流也能處理使用者傳送的「圖片」，為後續的發票分析做好準備。

在開始實作前，我先思考了兩個關鍵問題：

• 要如何判斷使用者傳送的是文字還是圖片？
• 若是圖片，要如何取得圖片的檔案內容？

只要解決這兩個問題，我們的工作流就能正式具備「影像處理能力」。

1. 判斷訊息類型

在 Line Webhook 回傳的資料中，有一個重要的欄位 message_type：

• 若值為 text，代表訊息是文字
• 若值為 image，則代表使用者上傳了圖片

因此，我們可以在 Edit Fields 節點之後，接上一個 IF 節點（其實也可以用Switch），根據 message_type 進行分流：

• 若是圖片 → 進入「發票圖片處理流程」
• 若不是圖片 → 進入「記帳處理流程」(昨天的文章內容)
  

2. 取得圖片檔案

當訊息類型為 image 時，Line 並不會直接把圖片檔案附在 Webhook 回傳的資料中，而是需要我們透過 Line Message API，結合 message_id，再以 HTTP Request 節點 發送請求取得圖片的 Binary File。

• HTTP Request 節點的設定如下：
  • Method：POST
  • URL：https://api-data.line.me/v2/bot/message/{Webhook取得的 message.id}/content
  • Authentication：選 Line Bearer Credential
    

整體來說，這一步的重點在於：讓 n8n 能根據訊息類型做出不同反應。若為圖片，則需取得圖片，進而開啟「影像理解」的可能，我們後續才能進行發票影像辨識與自動歸檔。

二、保險機制：讓工作流別被亂來的訊息炸爛

我們的工作流預計要有兩個主要功能：

• 發票歸檔（圖片分析、上傳）
• 記帳處理（文字訊息分析）

不過，現實總是比理想更混亂 —— 使用者可能會傳貓咪照、自拍、貼圖，甚至一句「嗨」。如果我們沒有妥善處理這些「亂入訊息」，工作流可能會誤判、寫入錯誤資料，甚至整條流程報錯。為了避免這種狀況，我們需要替工作流買一份「保險機制」。

這份保險的核心問題是：我們要如何判斷一則訊息是否「符合工作流的目的」？ 答案其實相當直覺—— 交給 AI。

我們可以將收到的文字或圖片傳入 AI 節點，讓它先判斷內容是否符合我們的處理邏輯：

• 若符合（例如是發票、或是與記帳相關），就繼續往下執行。
• 若不符合，則停止處理並通知使用者。

1. 分析圖片檔案 — Gemini: Analyze Image 節點

這個節點負責判斷上傳的圖片是否為發票。

我們將圖片 Binary 檔傳入 Gemini，並在提示詞中提及：「判斷這張圖片是否為電子發票，若是，則輸出的is_invoice欄位設為 true，否則設為 false。」

• 我的提示詞設計如下：
  

為了讓提示詞與輸出較整潔，我選擇無論是否為發票，輸出的格式都相同，後續才用is_invoice欄位來判斷。

2. 分析文字訊息

而對於文字訊息部分，我們可以調整昨天的工作流的AI Agent 的提示詞，直接將判斷過程直接寫在分析消費節點裡面，透過輸出判斷是否與消費金額有關。若無關，就不會接著寫入 Google Sheet，直接中止後續動作。

• 提示詞設計如下：
  

• 後續節點設計如下(與昨天非常類似)：
  

3. 不符合要求的訊息 — 回覆使用者

當 AI 判斷訊息與工作流的功能不符時，我們使用 HTTP Request 節點，透過 Line Message API 回傳一則說明訊息給使用者，避免系統資源被無效訊息佔用。

這一步就像幫工作流買了一份保險。

即使有人亂傳風景照、寵物照、或是隨便打句「哈哈哈」，n8n 也不會傻傻地把它存進 Google Sheet，而是停止處理並請使用者傳遞記帳、發票相關的訊息

三、發票的辨識歸檔

接下來，我們要讓工作流進化一下 —— 讓它自動將使用者上傳的發票圖片歸檔，並從圖片中擷取出發票資訊，寫入 Google Sheet。

整個流程會用到我們之前學過的幾個關鍵節點：

• Google Drive 節點：上傳發票圖片
• Gemini 節點：辨識並擷取發票資訊
• Google Sheet 節點：紀錄與更新發票資料

另外，我們還會用到 Code 節點 和 Merge 節點 來整理與合併資料，確保資料能順利流轉到下一個階段。

1. Gemini 分析圖片節點

目的 : 分析出發票上的資訊

前面分析圖片檔案的地方有提到：將發票圖片（Binary File）傳入 Gemini Analyze Image 節點，並在提示詞中清楚說明要擷取的欄位，這樣一來，AI 會回傳結構化的結果，讓我們可以後續寫入表格。

2. Code 節點

目的 : 將 Gemini 輸出轉成 JSON 格式

Gemini 節點的輸出通常是文字字串，因此我們可以使用一個簡單的 Code 節點，將其轉換成結構化資料（例如 JSON 物件），方便後續節點存取與使用。

程式碼如下 :

return [
JSON.parse($input.first().json.content.parts[0].text)
];
//建議在提示詞中請 Gemini 不要輸出多餘敘述文字，純粹輸出 JSON 內容。

• 後續的 IF 節點設計如下：
  

3. Google Drive 節點

為有效歸檔，我們直接將發票圖片內容作為檔名，方便後續查找

4. Google Sheet 節點

在這裡，我們可以將 Gemini 的辨識結果對應到試算表的欄位，像是年分、月份、日期、發票號碼、金額、店家資訊等欄，這樣就完成了整個「辨識 ➜ 歸檔 ➜ 紀錄」的自動化流程。
寫入完成後，利用 Message API 傳送歸檔成功的訊息。

理想狀況下，我們還可以再往前一步 —— 直接串接財政部電子發票 API，解鎖更多功能 : 查詢發票明細 (進而記帳)、取得中獎發票號碼、取得載具發票資訊 …等等，進而完善功能。
但現實是殘酷的 😅：要使用這個 API 必須要是營業人、且需要正式申請流程。(有錯還請更正)
身為一個平凡的消費者，我只能先做出這個「閹割版」的智慧發票管理員。(我曾經試過用分析QRCode 的 API 來解析電子發票上的條碼，但無法獲取明細訊息)
不過，即使是「閹割版」，它依然能自動分類、歸檔、對獎，已經讓手動整理發票的煩惱減少許多了。

四、AI Agent 的升級：從分析到行動 — 讓 AI 幫你對獎

財政部的電子發票 API 雖然有提供介面可以查詢中獎號碼，但若我們沒有 API 權限，難道就無法自動對獎了嗎？
其實不然 —— 山不轉路轉，我們還是有其他方法透過 AI 幫我們完成這件事！
只要讓 AI 取得中獎資料，它就能自行比對使用者的發票是否中獎。而這件事有很多種實作方式，例如：

• 直接把中獎號碼寫在提示詞裡
• 或像我們今天要示範的 —— 把中獎資訊寫入 Google Sheet，並讓 AI Agent 掛載該 Sheet 作為 Tool。

這樣一來，AI 就能像查資料庫一樣，動態讀取最新的中獎號碼，自動完成對獎流程，同時也幫我們認識 AI Agent 的 Tool Integration（工具整合） 強大概念。

1. 先將中獎資訊寫入 Google Sheet 當中

首先，建立一個新的 Google Sheet，並在其中輸入最新的中獎號碼與期別資訊，作為 AI 的參考依據。

我為了測試對獎功能，有把頭獎的第一組換成有有我發票號碼的數字，第三組我也有換。

2. AI Agent 設計

• 提示詞設計
  

• 掛 Tool
  接著在 AI Agent 節點中掛載 Google Sheet Tool，讓 AI 能夠直接查詢中獎資訊。
  

新增方式是點選 Agent 下方 Tool 分支的「＋」

• Output Parser
  為了讓 AI 的輸出更結構化、方便後續使用，我們在此設定 Output Parser，將結果轉換為標準化的 JSON 格式。
  

設定完後， AI Agent 就會幫你自動對獎了，然後就可以把對獎結果透過 Message API 傳遞給使用者。

五、Push Message：打破 Reply Token 限制

在昨天的文章中，我們提到，透過 Line 的 Message API 回覆訊息時，有兩種方式可以選擇：

1. replyToken：針對 webhook 接收到的特定訊息回復。特性是 時效短、只能使用一次。
2. userID：針對指定用戶傳遞訊息。特性是 用戶 ID 固定不變、隨時可用。

在這個發票管理器範例中，我希望可以在歸檔發票時先發送一則歸檔成功的通知訊息，而對獎後再發送另外一則訊息。由於對獎訊息可能會延遲 (AI 分析需要時間)，因此使用 userID 來發送可避免受限於 replyToken 的一次性與時效性。

透過 userID 傳遞訊息

• 設定 : 其實與 reply token 相同，只是在 url 的地方要從 reply 改為 Push。
• 訊息內容 JSON 也需要稍微調整：”replyToken”:”{token}” → ”to”:”{user.id}”
  

這邊的設定不能說很難，只能說就是這麼簡單！關鍵在於找到正確的設定方式。現在 AI 工具非常發達，搜尋一下就能輕鬆找到教學或範例。

最終成果如下：

六、結語與明日預告

今天，我們成功打造了一個（閹割版）的發票管理員，讓 n8n 不只是聽 ，還能看。
我們完成了：

1. 升級工作流，使文字與圖片訊息都能被正確處理
2. 設立保險機制，避免「亂入訊息」破壞流程
3. 學習 AI Agent 的 Tool Integration 概念，實現自動對獎
4. 利用 Push Message 主動傳訊息給使用者，不受 replyToken 限制

整合昨天的工作流後，這個官方帳號就像你的貼身財務小助理，幫你管理發票、記帳。即使是「閹割版」，也能大幅減少手動整理的麻煩。
不過，目前這位小助理只會接收、處理透過 LINE 傳遞的訊息，對 Messenger 或其他通訊軟體還無感。

明天，我們就要讓它跨平台，學會接收 Messenger 的 Webhook 訊息，
準備好將你的自動化助理，從 LINE 專屬，進化成跨平台的智慧秘書了嗎？明天見！