LINE 官方帳號串接開發 | 會員綁定、拍照上傳與 AI 辨識實戰

LINE 官方帳號串接開發能做到的，遠不只自動回覆和發優惠券。這次跟 BlueTrend 藍色脈動合作的藻礁生態保育專案，我們把一整套原本綁在網站上的複雜資料收集流程搬進 LINE——會員綁定、步驟式拍照上傳、GPS 定位、AI 圖像辨識全部在對話視窗裡完成。潛水攝影師不用開電腦，一支手機就能把剛拍到的藻礁照片送進海洋生物資料庫。

這個案子的起點，其實是一個很具體的使用情境問題。

為什麼要把上傳流程搬進 LINE

BlueTrend 專精海洋資料庫與 AI 辨識技術，這次跟桃園市政府合作藻礁生態保育。原本的網站平台讓海洋攝影愛好者上傳照片，一邊連結攝影師，一邊連結研究員——攝影師拿到物種鑑定，研究員拿到研究素材。

問題出在攝影師的使用場景。拍完照的那一刻，他們人在海邊、船上或潮間帶，手上只有一支沾滿海水的手機。要他們回家開電腦、登入網站、一張一張上傳，這條多步驟的路徑一長，記錄就流失了。很多有研究價值的影像，就這樣卡在相機記憶卡裡再也沒進資料庫。

我們的判斷是：與其要使用者遷就網站，不如把流程搬到他們手上已經開著的那個 App。攝影師本來就在用 LINE，這條路的門檻遠低於裝一個新 App 或記一組新帳密。把工具放到使用者已經在用的地方，往往是投報率最高的一步。

這裡要先講清楚一個常被誤會的邊界：很多人以為 LINE 官方帳號串接只能做客服、發推播，是因為只用到後台的圖文選單和自動回覆，真正的能力來自 Messaging API 加上 LIFF（LINE Front-end Framework）——前者讓後端能收發訊息、取得使用者傳來的圖片，後者讓我們在 LINE 裡開出一個完整的網頁前端，兩者組合起來，官方帳號就能變成一套會綁定會員、會叫用 AI 模型、會做地圖互動的資料收集系統。

底下四個功能，就是這套系統實際長出來的樣子。

功能一：LINE 帳號綁定，把 LINE 使用者對上網站會員

第一個要解的是身份問題。上傳的照片要標註貢獻者是誰，發現稀有物種時也要能通知本人，所以 LINE 使用者的身份得跟網站的會員系統對得起來。

我們用 LIFF 做了一個綁定頁，攝影師在圖文選單點「前往綁定」，開啟 LIFF 網頁後，透過 LINE Login 拿到使用者的 id_token，後端再用它換回 email 與基本資料，接著比對既有的 WooCommerce 會員：對得上就直接綁定，對不上就自動建立一個 customer 角色的帳號，把 LINE user ID 存進使用者的 meta 欄位。

實作時有一個容易漏掉的狀況：LINE 使用者不一定授權 email，也可能根本沒綁 email，id_token 因此換不到信箱，帳號就建不起來。缺 email 時，我們用 LINE 內部 ID 組一個 [email protected] 的備援信箱頂上，讓帳號流程不會斷。攝影師綁定完成後回到 LINE，就是已登入的網站會員狀態，之後不必再輸入任何帳密。

功能二：步驟式拍照上傳，把一張長表單拆成一問一答

一張有研究價值的照片，背後要填的欄位不少：物種名稱、拍攝的國家地區、精確位置、體長、水溫等等。如果在手機上一次攤開整張表單，光是捲動和點選就會勸退使用者。

我們把表單拆成對話流程。每一步 LINE 回一則訊息，附上 Quick Reply 按鈕給選項。拍攝年份就列出 2018 到 2025 的按鈕；拍攝深度給「潮間帶」「海面上」「15m」「510m」這類預設選項，點一下就好，不用打字。流程狀態用 transient 加 user meta 記著，系統隨時知道走到第幾題、每題答了什麼。使用者中途想放棄，輸入「stop」就能中止；體長、水溫這類數值欄位則加了驗證，擋掉亂填的內容。

照片本身沒有直接存 LINE 的連結，而是繞了一手。後端用 LINE content API 取回原圖，轉存到 Uploadcare CDN 拿一組穩定網址。這一步是為了後面著想——AI 辨識和資料庫入庫都需要一個長期有效的圖檔位置，而 LINE 的圖檔連結會過期，直接存下來遲早會失效。多做這一層轉存，換來的是資料庫裡每一張圖都指向可靠的來源。

功能三：GPS 位置選擇，從國家一路縮到地圖上的一個點

位置是這個資料庫最重要的欄位之一。研究員要知道生物出現在台灣哪一片海域，經緯度差一點，研究價值就差很多。

我們把位置選擇設計成三層漏斗：先選國家，再選地區，最後在地圖上點一個精確的點。國家和地區的選項不是寫死的，而是即時打資料庫 API 撈回來——選完國家才顯示對應的地區清單，資料庫新增了海域，選單就跟著長出來，不用改程式。

到最後一步，Quick Reply 給一個「開啟地圖」按鈕，點下去開 LIFF 地圖頁，並且先把該地區中心的經緯度帶進去，省得使用者從世界地圖找起。攝影師在地圖上拖曳、放大，點下實際的拍攝位置，系統回傳一段像這樣的字串：拍攝位置：某某海岸 (24.123, 121.456)。後端再用正規表達式把地址、緯度、經度拆開分別入庫，換來的是能直接畫在地圖上、能跑空間分析的座標，而不是一段模糊的文字描述。

功能四：AI 圖像辨識，讓機器人先猜猜這是什麼物種

這段是整個案子的亮點。BlueTrend 手上已經有訓練好的海洋生物 AI 辨識模型，我們要做的是把它接進 LINE 的上傳流程。

攝影師選好照片分類後，如果那個分類有訓練過的模型，機器人會問一句：「是否要辨識？（需約 10~15 秒）」。點「好的」就開 LIFF 頁，直接在手機瀏覽器裡跑 TensorFlow.js，載入從 Google Vertex AI 匯出的模型，對照片做分類。

這裡有一個刻意的技術選擇：辨識是在使用者的手機瀏覽器端跑，不吃伺服器資源。模型吐出候選物種和信心度，我們只留信心度超過 35% 的結果，再把模型的英文標籤對映回中文物種名。使用者確認「猜對了」或「都不是」，這個回饋會連同資料一起入庫，成為日後訓練模型的素材——辨識這件事因此會越用越準。

順帶一提，Wiki 裡既有的 AI 案例（OrderChatz 的 Function Calling 文字客服）跟這裡是兩條不同的技術路線。那邊是伺服器端呼叫 OpenAI 處理文字問答，這邊是客戶端跑圖像分類模型，一個管對話、一個管辨識，別混為一談。

我們幫這個 AI 角色取名叫「布魯」，猜對時說「布魯猜對了！」，猜錯就說「布魯會再多學習的！」。除了辨識，布魯也串了客服機器人，攝影師在上傳流程之外問海洋生物相關的問題也能答；答不出來時，會自動寄信通知管理員補資料。

這個案例對想做 LINE 應用的你意味著什麼

把原本綁在網站上的複雜流程完整搬進 LINE，而且用起來比網站順。攝影師省掉「回家開電腦」這一步，記錄回收率跟著上來；資料庫拿到的是帶座標、帶 AI 預辨識的結構化資料，研究員也省下大量整理工作。這是一次雙邊都受益的遷移。

要提醒的一個現實邊界是：這套系統的地基是 LINE 平台本身。LINE 若調整 API 費率、功能限制或政策，建在上面的流程都會受影響——深度整合帶來便利，也意味著把一部分主導權交給了平台，做的時候心裡要有數。

撇開這個前提，重點是門檻沒有想像中高。接上 Messaging API 與 LIFF 之後，LINE 官方帳號可以是完整的資料收集系統，可以綁會員、可以叫用 AI 模型、可以做地圖互動。真正的關鍵不在技術有多難，而在於先想清楚使用者是在什麼情境下用它——藻礁這個案子成立，是因為我們先看懂了「攝影師拍完照那一刻手上只有手機」這件事，剩下的功能才有意義。

如果你手上也有「使用者已經在用 LINE，但流程卡在網站上」的問題，不管是預約、回報、資料收集還是客製化 AI 應用，都可以聊聊。

常見問題 FAQ

LINE 官方帳號串接開發跟一般的自動回覆設定差在哪？

自動回覆是官方帳號後台內建的功能，只能做關鍵字對應的固定回覆。串接開發是接上 Messaging API 與 LIFF，讓後端能收發訊息、取得圖片、比對會員、叫用 AI，等於把官方帳號變成一個可以跑任意邏輯的應用程式，能力天差地別。

LIFF 是什麼？跟 Messaging API 有什麼不同？

Messaging API 負責訊息的收發與資料交換，是後端與 LINE 溝通的管道；LIFF（LINE Front-end Framework）則是在 LINE 裡開啟網頁前端的框架，用來做綁定頁、地圖選點、AI 辨識這類需要完整畫面的互動，這個案子兩者都用到——對話用 Messaging API，需要畫面的步驟開 LIFF 頁。

在手機瀏覽器端跑 AI 辨識，效能會不會有問題？

這個案例用 TensorFlow.js 載入 Vertex AI 匯出的模型，在使用者手機端執行，單張照片辨識約 10 到 15 秒，不佔用伺服器資源。適合模型體積可控、辨識頻率不極端的場景；如果模型很大或要即時大量辨識，就要改用伺服器端推論。

LINE 傳來的圖片可以直接存資料庫連結嗎？

不建議。LINE content API 取得的圖檔連結會過期，直接存下來遲早失效。我們的做法是後端取回原圖後轉存到 Uploadcare CDN，換一組長期穩定的網址再入庫，確保後續 AI 辨識和資料庫都指向可靠的來源。

---

有類似的 LINE 官方帳號串接需求，或想進一步討論怎麼把卡在網站上的流程搬進 LINE？歡迎聯絡我們，或加入我們的 LINE 官方帳號聊聊你的專案。