不用裝 App，在 LINE 查單、簽核、收告警｜把系統介面搬進 LINE，權限與稽核一樣不少

• 現場人員不開電腦的產業物流、餐飲、工程、零售、維修。師傅在車上，外場在跑單，你叫他登入後台不會發生，但他的 LINE 一直開著。把進度回報、查單、查庫存、簽核做進 LINE，資料才收得回來。
• 想讓客戶免下載 App 的品牌客戶不會為了查一次訂單或保固去裝一支 App。LIFF 讓網頁直接跑在 LINE 裡，還拿得到使用者身分，這是免下載 App 的替代方案。
• 已經有官方帳號、但只會群發的行銷與客服主管帳號有了，好友也有了，缺的是把它接上內部系統：查訂單、查庫存、查進度、送簽核、推異常告警。LINE 官方帳號客製開發要做的就是這一段：從群發變成可以問、問得到答案。

還有一種：有設備要看狀態的。廠務、機房、冷鏈、門禁，也就是一般說的 LINE 控制 IoT。設備端的資料怎麼收、怎麼判斷異常，寫在 IoT 與監控系統整合，這一頁講的是它最後怎麼變成 LINE 上的一則訊息。

• 想找人代操推播行銷、寫貼文、養粉絲的不接。那是行銷代理商的工作，我們寫程式。
• 只想買一套現成的月租聊天機器人市面上有便宜很多的 SaaS，功能夠用就不必做客製。客製的理由只有一個：要接你自己的資料。
• 內部沒有任何可查的資料來源連一份共用的 Google Sheet 都沒有的話，LINE 接上去也沒東西可回。先把系統做出來，走 企業系統客製開發。
• 主體其實是流程自動化的如果你要的是表單進來自動跑、資料自動整理、跨系統接力，LINE 只是其中一個出口，那主體在 AI 工作流與流程自動化。
• 想把 LINE 當唯一客戶資料庫的好友名單匯不出完整資料，userId 還是綁在單一 Channel 上，換一個 Channel 就對不上。資料主體必須留在你自己的系統。
• 期待推播不用錢也不限量的主動推播佔額度，量大就是固定成本。這件事要在設計前算，不是上線後才發現。

先說清楚證據等級：以下 LINE 串接系統開發的成果都是我們自己寫過的程式碼與做出來的系統，不是簡報上的示意圖。

最完整的一套：員工用的 LINE 查詢機器人，已上線

不是回罐頭訊息的機器人，是把內部系統的查詢介面整個搬進 LINE。員工加好友後先綁定員工編號，沒綁定或已停用的帳號在查詢前第一道閘就擋掉，什麼資料都不給。對外的版本則是 LINE 綁定會員：用 LINE Login 把使用者身分對應到你系統裡的會員，之後查訂單、查保固都認得出人。綁好之後，LINE 圖文選單客製成六格切換查詢模式，目前上線的有四種：

• 查商品與報價— 打關鍵字，回 Flex Message 開發出來的卡片輪播，顯示完整品名、料號、依該員工權限決定看得到哪一層價格、以及在庫可賣的數量。
• 查客戶— 用唯一識別碼可以直達，也能用手機或姓名找，帶出聯絡方式、名下項目、累計消費與最近五筆訂單，可以點進訂單詳情。
• 我的訂單— 預設只顯示待處理與處理中，已完成與作廢不佔版面。
• 查訂單— 單號、網路單號、倉儲單號、收件人、出貨電話都查得到。

這套系統真正難的地方，不在 LINE 那一側

• 權限由後端決定，不由對話決定。按鈕的 postback 只帶查詢意圖，員工編號、權限層級、價格分層一律後端反查，不夾在訊息裡。進價與成本在資料庫欄位層級就擋死，機器人拿不到整包資料自己挑欄位。
• 客戶口語跟系統命名對不起來，所以自建兩份詞典。客戶講的名稱、料庫裡的正式名稱、以及同一個東西的多種寫法，全部靠同義詞表展開；還要排除會誤中的字。這部分沒有現成方案，是逐筆從實際資料逼出來的。
• 驗簽與冪等是身分命門。Webhook 取原始位元組、在解析之前驗簽章，失敗一律 401 不進業務邏輯；事件依 ID 去重、回覆權杖只用一次、webhook 先回 200——LINE 一定會重送，這幾件事沒做好就會重複扣款、重複發通知。
• 防呆擋的是全表掃描。查詢字串跳脫萬用字元、空白與純萬用字元直接不進查詢、超長截斷、全形轉半形、貼圖與圖片不動對話狀態。
• 稽核只存「誰在什麼時候查了什麼」，不存價格、成本與精確庫存。
• Flex 卡片無法選取複製，所以每張詳情卡另附純文字版。這種事不寫在規格書裡，是真的有人用了才會知道。

純函式的部分（查詢解析、卡片組裝、狀態機轉換）用 Node 內建測試框架覆蓋九組情境矩陣：綁定門檻、狀態過期與疊加、翻頁、模式切換、跳脫與空輸入、全半形正規化、同義詞展開、結果呈現、冪等並發。不靠 LINE 就能在本機跑完。

官方帳號本身也是我們在管

多租戶的官方帳號設定（每個租戶配置自己的 LINE 官方帳號）、LINE Login 身分綁定走 OAuth、LIFF 開發的網頁應用、邀請頁、推播管理，都在同一套後台裡。channel secret 加密存放，不是寫在環境變數裡就算了。

LINE 推播通知與告警這一側

• 報價與合約管理系統（自研產品）報價送出、客戶簽署完成、報價即將到期，三個事件以 LINE 通知。台灣的商務溝通實際上跑在 LINE 上，寄一封 Email 沒人看。技術是 Nuxt 4 加 LINE Messaging API。
• 免拆箱保固登記 SaaS（白牌多租戶系統）消費者掃外箱 QR 就開始登記，全程在手機上完成，LINE 通知與後續互動都已寫進系統裡。
• 設備監控系統設備狀態進 MQTT，經規則判斷後由 Messaging API 送出告警。告警在送出前先做分流與去重——同一個異常在恢復前只發一次，並依嚴重度決定發給誰。LINE 控制 IoT 這條路線的程式碼是現成的。

這幾套都是我們自己做的系統，寫在這裡是因為程式碼在我們手上、講得出細節，不是拿別人的案子當佐證。

帳號與頻道設定這一段沒有 repo，但每一次串接都必須做

LINE Developers 的 Provider 與 Messaging API 串接用的 Channel、Webhook URL 與簽章驗證、官方帳號後台的聊天模式與自動回應切換、圖文選單的區塊與動作綁定、LIFF 的 endpoint 與 scope——這些是平台設定，不會產生程式碼，卻是最常卡住的地方。啟用 Webhook 之後，官方帳號原本的自動回應行為會變；這一步沒處理好，使用者會同時收到系統回覆與罐頭訊息，看起來就像帳號壞掉。另外圖文選單只支援文字動作、不支援 postback，多種查詢並存時要用文字指令分流，這個限制是實作時才會撞到的。

公開寫過的

我們發表過一篇 LINE Bot 開發教學，用 Google Apps Script 串 Messaging API 與 Gemini API，含 Flex Message 卡片互動與完整原始碼。想先自己試一遍的人可以照著做，做完會比較知道自己真正要的是什麼。

LINE 要接的那一端長什麼樣，可以看我們做過的全通路訂單整合平台——ERP 讀鏡像、寫走 API、前台統一入口。那套本身不是 LINE 專案，放在這裡是因為 LINE 再多一個對外介面不難，難的一直是後面那層。

1. 盤點要推什麼、誰收先列事件清單：哪些狀態變化值得發一則訊息、發給誰、需不需要回覆。同時決定要不要做查詢類指令，也就是讓使用者反過來問系統「這張單現在到哪」「那台設備現在什麼狀態」——單向推播和雙向查詢是兩種設計，工作量差很多。這一步做不完整，上線後就會變成洗版，然後大家把通知關掉。
2. 帳號與頻道設定在客戶自己的 LINE Developers 帳號下建立 Provider 與 Channel，設定 Webhook、簽章驗證，以及官方帳號後台的聊天模式與自動回應。
3. 介面設計查詢結果與簽核用 Flex Message，常用功能放圖文選單，需要填表或多步驟的走 LIFF。這一步決定使用者願不願意用第二次。
4. 身分綁定用 LINE Login 把 userId 對應到你系統裡的員工編號或會員編號，首次綁定走一次性驗證碼或員工登入。沒有綁定，系統不知道問話的是誰，權限就無從談起。
5. 串接與測試接上內部系統的 API 或資料來源，用測試頻道整輪跑過，包含推播分流、去重、失敗重送與逾時處理。
6. 上線與移交權限、憑證、部署文件交回客戶，撤掉我們的管理員身分。

要多久，取決於這四件事

• 只推通知，還是要雙向查詢與簽核
• 介面停在文字與 Flex Message，還是要做 LIFF 網頁應用
• 要不要身分綁定與多層權限
• 要接幾個系統、那些系統有沒有 API（沒有 API 的舊系統最花時間）

單純的告警推播最短，加上 LIFF 與身分綁定會明顯拉長，要串沒有 API 的既有系統最久。實際排程在需求盤點結束後以書面確認——我們不在看過你的系統之前給沒有依據的週數。

一、開發費（我們收）

一次性，按範圍計。影響價格的因素：

• 事件與流程數量：三個推播事件和二十個，工作量差很多
• 介面層級：純文字最輕，Flex Message 次之，圖文選單再次，LIFF 網頁應用最重
• 身分綁定與權限：有沒有 LINE Login、有沒有角色分層與操作稽核
• 串接對象：有 REST API 的系統快，只能讀資料庫或要處理舊系統的慢
• 是否包含 IoT 設備狀態查詢與控制指令（多一層權限與紀錄）
• 上線後要不要持續維運與調整

二、LINE 平台費用（客戶自己付）

官方帳號的方案月費與訊息額度由 LINE 收取，開在客戶帳號、由客戶付款，0 元經過我們，也不加價。

訊息成本要在設計階段就算進去

程式要主動發訊，現在只剩 Messaging API 一條路——LINE Notify 已於 2025 年 3 月 31 日終止服務——所以每一則主動發出的訊息都佔額度。依 LINE 官方說明，Messaging API 的 Reply（使用者先發話、系統在時限內回應）不計入訊息費用，群發、分眾與主動推播則計入。我們的做法有三個：能用回覆訊息解決的就不主動推；同一批資訊合併成一則 Flex 卡片，不逐筆發；告警做去重與抑制，同一個異常在恢復前只發一次，並補一則恢復通知。這不是省小錢，是避免額度被雜訊吃光，以及避免使用者把通知靜音。

另外一件現在就該知道的事：LINE 官方帳號的價格方案將於 2026 年 11 月 1 日調整。額度規劃一律以 LINE 官方最新公告為準，我們在盤點階段會一起算進去。

實際費用依需求評估，盤點結束後提供書面報價與範圍說明。

• LINE 官方帳號開在客戶名下，客戶是管理員。我們以受邀的管理員或成員身分進去做事。
• LINE Developers 的 Provider 與 Channel同樣開在客戶帳號。Channel secret 與 access token 由客戶保管，我們只在開發期間使用，結案後輪替。
• 好友名單與 userId屬於客戶。userId 綁在該 Channel 上，所以 Channel 開在誰名下這件事比想像中重要——帳號換手，綁定關係就得重做。
• GA4、Search Console、Google 商家檔案客戶帳號，我們受邀。
• 雲端專案（GCP／Cloudflare）開在客戶帳號，帳單也開給客戶。
• 原始碼放客戶的 Git 帳號或組織，交付即完整移交，含部署與環境變數文件。

結案時撤掉我們的所有權限。要不要繼續找我們維護是另一件事，不能靠扣著帳號來綁。

• 驗簽不是我們加戲LINE 官方文件白紙黑字要求：機器人伺服器可能收到來自 LINE 平台以外的惡意請求，處理事件前務必驗證簽章，見 Verify webhook signature。我們把它做成「解析前先驗、失敗一律 401」。
• Flex Message 的能力與限制卡片版面能做到什麼、不能做到什麼（例如訊息內的文字無法選取複製），依據是 Flex Message 文件。我們每張詳情卡另附純文字版，理由就在這個限制。
• Webhook 會重送，所以必須冪等事件接收與重送行為見 Receiving messages。事件依 ID 去重、回覆權杖只用一次、先回 200 再處理，這三件事都是照官方行為設計的，不是保守起見。