如何用 n8n 打造 LINE 庫存管理機器人？整合 Google Sheets 與 AI 影像辨識

每天花了大把時間在紙本庫存表上塗塗改改，到最後連自己都看不懂紀錄了什麼？傳統的手寫管理既沒效率，又容易出錯。—— 本文將與你分享，我如何透過自動化工具，將繁雜的店務庫存管理數位化，把時間留給更重要的事。

一、 前言：營運痛點與開發動機

解決方案：

預期目標：

1.即時訊息查詢： 同事能直接在 Line 發送訊息，秒級檢索精準的商品庫存量。

2.隨時訊息更新： 庫存管理人員可透過對話框輸入，即時同步並修正資料庫庫存。

3.智慧圖片辨識： 導入拍照功能，職員只需拍攝商品外觀，系統便能自動辨識並呈現該品項的庫存資訊。

二、 系統架構與工具介紹

• 前端互動： LINE Messaging API (接收文字、圖片、貼圖、回覆訊息)。
• 自動化核心： n8n (Webhook 接收、工作流設計、API 呼叫)。
• 資料庫： Google Sheets (儲存會員名單、商品資訊、庫存量管理)。
• AI 圖片辨識： open AI(處理商品圖片特徵辨識)。

運作流程概述： 簡單帶過從「使用者傳遞訊息」到「系統回覆結果」的生命週期。

三、 核心功能與工作流拆解 (Core Features)

這個段落是文章的主體，可以搭配 n8n 的局部截圖來輔助說明。

01. 🛡️ 第一關：安全名單過濾與流暢的 Line 互動緩衝

在主要工作流運作之前，系統必須兼顧「資安」與「操作體驗」。不是隨便一個路人傳訊息，都能動到後台資料庫。

• (1) Webhook（自動通知機制）：Webhook 就像一個「自動接收通知的網址」。當外部系統發生事件（例如使用者傳送 Line 訊息）時，會立刻將資料推送至該網址，讓 n8n 收到後能即時觸發後續的自動化流程。
• (2) 用戶事件判斷與 Loading 動畫：系統透過 Webhook 接收資料後，會自動辨識 Line 的訊息類型（如：傳送訊息 message、加入好友 follow 等）：
  • 新用戶引導： 當系統透過 If 節點偵測到使用者「加入好友（follow）」時，會自動發送客製化的使用說明，協助新夥伴快速上手。
  • Loading 動畫： 系統觸發時會同步啟用 Line 官方內建的載入動畫（Loading），明確提示使用者「數位助理正在處理中」，有效提升前線操作的互動體驗與擬真感。
• (3)會員查詢系統：每位使用者在首次傳送訊息給 LINE 機器人後，都會自動產生一組專屬的 LINE ID。系統可透過此 ID 串接 Google Sheets 建立會員資料庫，用來控管庫存查詢與庫存異動權限，避免任何人都能直接操作庫存系統。管理者也可依需求關閉驗證機制，改為開放所有使用者皆可使用該庫存管理機器人。

02.第二關：聰明的文字大腦——自動分流、改錯字與跨樓層運算

(1)「判斷意圖 / 整理訊息」節點：

此節點主要負責讀取 LINE 使用者傳送的訊息，並自動判斷使用者想執行的功能，例如：

• 查詢商品：當使用者輸入「查詢/找/看有沒有」等文字節點判斷後會輸出”search_product”
• 扣除庫存：當使用者輸入「補/扣/扣庫存/減」節點判斷後輸出”reduce_stock”
• 新增商品：當使用者輸入「新增商品」節點判斷後輸出”create_product”

同時也會整理訊息內容，移除像是「幫我」、「查詢一下」、「還有嗎」這類口語贅字，只保留真正需要的商品關鍵字，方便後續流程進行商品搜尋與庫存處理。

首先抓到關鍵字「查詢」，輸出”search_product”的結果並清理訊息冗詞後，在後續路徑輸出「可樂」。

(2)「分類意圖」節點：

這是一個switch節點用來判斷前面節點給出的「判斷使用者意圖輸出」假如前一個節點判斷出”search_product”，則可將訊息通過switch通道傳向第一條「新增商品」的工作流走去。

🟢分支1：新增商品

(1)code-整理使用者訊息

透過 code 搭配 Regex（正規表示式）解析使用者輸入的固定格式內容，自動擷取：

• 類別
• 商品名稱
• 1F庫存
• 2F庫存
• 售價

等欄位資料。

系統也會自動清理資料內容，避免使用者輸入像是：

• 300元
• 5個
• 空白字元
• 不必要符號

等內容影響後續 workflow 執行。

此外，此節點也會驗證：

• 欄位是否缺漏
• 數字格式是否正確
• 是否使用純數字

例如若使用者輸入中文數字、缺少欄位或格式錯誤，系統就會在輸出資料中的 status 欄位標示為 error，方便後續節點進行判斷與錯誤處理。

(2)if-判斷格式是否正確
前一個節點會輸出一個 status 欄位，用來表示訊息是否成功解析。

當 status = success 時，代表：

• 所有欄位完整
• 格式正確
• 數字可正常辨識

workflow 才會繼續執行後續新增商品流程。

若 status = error，則會自動中斷新增流程並導向錯誤回覆節點，避免錯誤資料被寫入 Google Sheets，作為整個庫存系統的重要防呆機制。

(3)google sheets(append row)-新增商品資料至 Google Sheets
此節點在成功串接 Google API 後，可直接存取指定 Google Sheets 試算表。

系統會根據前面節點整理完成的商品資訊，自動將：

• 類別
• 商品名稱
• 1F庫存
• 2F庫存
• 售價

依序新增至指定工作表中的新列資料，作為商品庫存資料的正式建立流程。

(4)Get row(s) in sheet-重新抓取新增的商品資訊
透過 Get row(s) in sheet 節點再次讀取剛新增的商品資料，並透過商品名稱進行搜尋比對。

此步驟除了能讓 LINE 機器人回傳完整的新增成功資訊外，也能作為資料二次驗證機制，確認商品確實已成功寫入 Google Sheets，並避免資料寫入異常或欄位錯誤。

(5)code+HTTP request-回傳新增成功結果

透過 code 節點整理商品資訊與庫存內容，組合成較易閱讀的回傳訊息後，再透過 HTTP Request 節點串接 LINE Messaging API。

系統會利用使用者的 replyToken 與 LINE ID，將新增成功的商品資訊即時回傳至該使用者的 LINE 聊天視窗中，讓使用者能立即確認新增結果與商品內容是否正確。

🔵分支二：搜尋商品

(1)google sheets－掃描商品工作表

此節點會透過 Google Sheets API 讀取指定試算表中的所有商品資料，作為後續商品搜尋的資料來源。

系統會從「商品總表」中抓取：

• 商品名稱
• 總庫存量
• 售價
• 備註
• 商品照片

等欄位資訊，讓後續節點能針對所有商品進行關鍵字比對與模糊搜尋。

由於此節點會一次掃描整張商品表，因此即使後續新增商品，也能立即被搜尋系統讀取與查詢。

(2)code－修正使用者錯字（模糊搜尋機制）

此節點主要負責商品名稱的模糊比對與錯字修正。

系統會先取得使用者輸入的商品關鍵字，再與 Google Sheets 中所有商品名稱進行相似度判斷。
除了完全相同的商品名稱外，此節點也支援「錯一個字」、「少一個字」和「部分關鍵字重疊」等情況。

(3)Filter－過濾搜尋結果

此節點會根據上一個節點產生的”isSimilar”結果，過濾掉不相關的商品資料。

只有被判定為：

isSimilar = true

的商品才會保留下來，繼續進入後續流程，這個節點的作用相當於「將模糊搜尋後真正符合條件的商品留下來。」，避免後續回傳大量不相關商品給使用者。

(4)code+HTTP request－整理搜尋後的商品資訊並回傳

此節點主要負責「整理搜尋結果」、「排序商品相似度」、「生成 LINE 回覆訊息」。
系統會先過濾掉空資料及不相似商品，接著依照”matchScore”進行排序，讓最符合使用者搜尋內容的商品優先顯示。
之後會自動組合成較易閱讀的商品資訊，例如：

商品名稱：可樂
總庫存量：15
售價：35
備註：常溫保存
照片：https://...

若完全搜尋不到商品，系統則會自動回傳：

查無此商品，請確認名稱是否正確。

作為搜尋失敗提示。

最後再透過HTTP request串接API回傳搜尋結果的訊息給使用者。

🟠分支三：扣商品庫存

(1)Get row(s) in sheet－讀取商品資料

此節點會先從 Google Sheets 商品總表中讀取目前所有商品名稱及庫存量等資訊，作為後續扣庫存時的比對依據。

(2)code－拆開名稱/數字並篩選出所需商品

這段 code 的主要功能是：

「讀取使用者輸入的扣庫存內容 → 找到對應商品 → 檢查庫存 → 自動計算新庫存 → 回傳結果。」

整體流程可以拆成 4 個階段：

01拆解使用者輸入內容
程式一開始會先取得使用者輸入的文字，並依照換行拆開。例如使用者輸入：
「補：
　小煤球1
　陶瓷手繪貓貓勺-灰耳1
　陶瓷手繪貓貓勺-橘貓(虎斑)*1」
系統會自動拆成三筆商品資料，同時也會清理空白行、「補:」或是「減:」這類不需要參與計算的文字。
接著系統會開始解析每一行商品，例如「小煤球*1」會被拆成：
「商品名稱：小煤球
　扣除數量：1」
這段邏輯同時支援”商品*數量”、”商品x數量”、”商品數量”，例如：”小煤球*3”、”小煤球x3”、”小煤球3”，都能被正確辨識。如果格式無法判讀，系統會回傳錯誤訊息避免扣到錯誤的品項庫存。

02商品模糊搜尋與比對
成功拆出商品名稱後，系統會開始和 Google Sheets 內的所有商品進行比對。比對方式透過「關鍵字重疊」、「相似度評分」來找最接近的商品。例如商品表內有「元寶小馬-白」，使用者輸入「元堡小馬」、「元寶馬」系統仍然可能成功找到商品。
程式會替每個商品計算”matchRate（匹配率）”和”finalScore（匹配分數）”，最後只保留最接近的候選商品。

03檢查庫存並執行跨樓層扣除
找到唯一商品後，系統會先檢查總庫存是否足夠，如果總庫存不足系統就會直接回傳錯誤訊息，避免出現負庫存。
若庫存足夠，系統會開始扣除庫存且優先扣除2F庫存不夠再扣 1F 庫存，例如：

原1F庫存	原2F庫存	扣5個庫存	新1F庫存	新2F庫存
10	3	⮕	8	0

這樣比較符合實際店面先從特定樓層出貨的情境。

04整理並輸出結果
最後系統會將每筆商品的結果整理成標準格式。成功時會輸出：商品名稱、新庫存、剩餘總庫存、扣除數量等資訊讓使用者再次確認。

最後把所有結果回傳給n8n讓後續Google Sheets更新並回覆LINE訊息。

Input:

code node的Output:

(3) Google Sheets(update rows in sheet)－更新商品庫存

此節點主要負責將前面計算完成的新庫存數量更新回 Google Sheets。功能與前面的「新增商品」流程類似，但這次不是新增資料，而是更新既有商品的庫存數量。
系統會透過「商品名稱(外觀)」作為 matchingColumns 比對依據，自動找到對應商品列後更新「1F庫存」與「2F庫存」欄位。
例如：
「元寶小馬」原本：1F：10、2F：3
扣除後計算結果：1F：8、2F：0
此節點就會自動把試算表中的庫存更新成最新數值。

(4)Code－合併訊息 ＋ HTTP Request－回覆扣庫存資訊

由於使用者可能一次扣除多項商品，因此此節點會先將所有商品的扣庫存結果整理成一段完整訊息，再透過 HTTP Request 回傳至 LINE。
例如使用者輸入：
「小煤球2」
「元寶小馬3」
前面的工作流會產生多筆商品結果，而此節點會利用：
.all() → 取得全部商品資料
map()、join() → 合併所有訊息內容
避免 LINE 一次傳送過多零散訊息。

最後 HTTP Request 會透過 LINE Messaging API 與 replyToken，把整理完成的扣庫存結果回傳給原本的 LINE 使用者，讓使用者立即看到扣除結果與目前剩餘庫存。

03. 📸 第三關：強大的視覺大腦——免手動輸入的拍照查庫存功能

在店內有較多商品庫存的營運日常中，常常會遇到標籤失蹤這類型的困擾，各種商品堆裡突然翻出一件商品，上面的商品貼紙掉了。想重新補印貼紙，卻因為商品已經年代久遠或是只剩單獨一個商品，只能去翻找很久以前（甚至幾年前）上架時拍的庫存照片或備註，但在line相簿裡幾百張的庫存照片中要找出來實在不容易。

為了徹底解決這個痛點，我用 n8n 串接 OpenAI GPT 與 Google Sheets，打造了一套「傳照片就能自動比對特徵、撈出前三名最相似商品」的智慧庫存助理！

以下就為大家完整拆解這套工作流的運行邏輯與核心節點設計。

(1) HTTP Request－取得 LINE 圖片內容

當使用者在 LINE 傳送圖片時，Webhook 一開始收到的並不是圖片本身，而是這張圖片的 message id。
因此系統需要先透過 HTTP Request 節點，依照 LINE 傳來的 message id，把圖片內容下載回 n8n，作為後續 AI 圖片辨識的資料來源。

簡單來說，這一步就是先把 LINE 聊天室裡的圖片「取出來」，交給後面的 AI 大腦分析。

(2) AI Agent－辨識圖片外觀特徵

取得圖片後，workflow 會將圖片交給 AI Agent，並搭配 OpenAI 模型進行圖片理解。

這個節點的重點不是直接猜出商品名稱，而是先請 AI 觀察圖片中的商品外觀，例如：
顏色/形狀/材質/花紋/主體特徵/可能的商品類型

系統會要求 AI 以結構化格式輸出結果，避免 AI 回傳一大段自然語言，導致後續節點不好處理。
例如 AI 可能會整理出：
商品是否可辨識：”是”
商品外觀描述：”主體為一個白色絨毛動物造型小物，擁有大大的藍色刺繡眼睛與黃色邊框，鼻子突出且有棕色條紋。整體外觀可愛柔軟，類似貓咪臉的造型。”

這樣後續就可以拿「商品外觀描述」去跟 Google Sheets 中已建立好的商品備註做比對。

(3) If－判斷圖片是否可辨識

AI Agent 完成圖片分析後，系統會透過 If 節點判斷這張圖片是否真的能辨識出商品。

如果 AI 判斷圖片太模糊、商品被遮住、畫面中有太多干擾物，或是根本不像商品照片，workflow 就不會繼續往下比對，避免回傳錯誤結果。
此時系統會直接回覆使用者：
無法辨識該圖片，請確認照片是否能清楚辨識商品外觀且無其他物品干擾。

這個步驟是圖片辨識分支中很重要的防呆機制，因為圖片搜尋不像文字搜尋可以靠關鍵字修正，若一開始圖片品質太差，後面再怎麼比對都容易出錯。

(4) Google Sheets＋第二個 AI Agent－比對商品資料庫

當圖片成功被辨識後，系統會讀取 Google Sheets 中的商品總表，並取得每筆商品的：
商品名稱/售價/總庫存量/圖片網址/備註 / 商品外觀描述

這裡要注意的是，圖片辨識功能能順利運作的關鍵，在於商品上架時就先把商品照片或商品特徵整理進 Google Sheets 中。
也就是說，這套流程不是讓 AI 憑空猜商品，而是讓 AI 先描述使用者照片中的商品特徵，再拿這段描述去跟資料庫中既有的商品備註進行比對。

另外，workflow 也會同步將使用者傳來的圖片上傳至圖床，保留一組圖片網址，方便回傳結果或日後人工複查。

接著第二個 AI Agent 會根據：
顏色是否相似/材質是否相似/形狀是否相似/商品類型是否接近/備註描述是否符合
從 Google Sheets 商品清單中挑出最接近的 3 筆商品。

這裡我沒有讓 AI 自由產生商品名稱，而是要求它只能從 Google Sheets 既有資料中選出商品，並且輸出的商品名稱、售價、庫存與圖片網址都必須完全來自資料庫。
這樣可以避免 AI 憑空幻想出不存在的商品，也能降低庫存查詢時最怕的「看起來很像但其實資料是假的」這種問題。

(5) Code＋HTTP Request－整理前三名相似商品並回傳 LINE

四、 技術亮點與開發心得 (Technical Highlights)

在這次開發 n8n 庫存管理 workflow 的過程中，我發現 n8n 不只是單純串接 LINE、Google Sheets 和 API。只要搭配 Code 節點，其實可以做出更接近實際系統邏輯的功能。

例如在商品搜尋與扣庫存流程中，我透過 Code 節點加入模糊比對機制，讓使用者即使輸入少字、錯字或部分商品名稱，系統仍然有機會找到相近商品，讓整體操作更符合實際使用情境。

這次也嘗試使用多個 AI Agent 節點協作分工。以圖片辨識功能來說，第一個 AI Agent 負責辨識圖片並整理商品外觀描述，第二個 AI Agent 則負責將描述與 Google Sheets 中既有的商品資料進行比對。這樣能讓每個 AI 節點各自負責不同任務，也讓整體流程更容易拆解。

不過，開發過程中也花了很多時間反覆 debug。雖然透過 vibe coding 可以很快產生第一版功能，但實際放進 n8n 後，常常會因為資料格式、欄位名稱或節點輸出入結構不同，而需要不斷測試與修正。

另外，AI 模型的判斷仍然有一定限制，尤其在圖片辨識與商品比對上，不一定能做到 100% 精準。

五、 結語與未來展望 (Conclusion)

整體來說，這次建構的 n8n 庫存管理 workflow 目前還只是一個初步雛型。

雖然它已經可以完成查詢商品、新增商品、扣除庫存，以及透過圖片尋找相似商品等功能，但距離真正穩定、完整、可以長期使用，還有很多需要修正的地方。

未來我希望可以持續修正這個 workflow，讓它更符合實際應用層面的需求，甚至有機會變成可以被更廣泛使用或商業化應用的庫存管理工具。

除此之外，我也希望可以加入更多前端設計與使用體驗上的巧思，讓這套系統用起來更精緻、更人性化，也更直觀。