減脂小豬

減脂小豬是一個完全活在 LINE 裡的飲食日記產品。使用者拍下午餐照片，bot 會辨識菜色、依照台灣的六大類食物代換份量估算份數、請使用者一鍵確認，然後回覆今天還剩多少額度。不用下載 app、不用註冊帳號、不用手動查熱量。

這篇案例研究會說明它是怎麼打造的、為什麼這樣做，寫給正在考慮自己在 LINE 上做產品的團隊。

為什麼選 LINE 而不是 app

在台灣、日本和泰國，大家本來就在 LINE 上。要求別人再裝一個減肥 app 是很大的請求；請他們加一個 LINE 好友則不是。這影響了每一個產品決策：

• 零安裝、零註冊。 LINE 使用者 ID 就是帳號。新手流程就是「加好友 → 傳第一張照片」。
• 對話就是介面。 最快的互動，是使用者早就會的那種：傳照片、點按鈕。
• 推播是原生的。 提醒和每週回顧會出現在使用者每天都會打開的同一個聊天室——沒有通知權限對話框，也沒有 email。

代價是聊天視窗是一塊很窄的畫布。任何比訊息更豐富的東西——瀏覽歷史、編輯紀錄、圖表——都需要另一個介面。這就是 LIFF 出場的地方。

使用者體驗

1. 照片 → 結構化紀錄，一次來回搞定

1. 使用者傳一張食物照片（或輸入 紀錄 拿鐵 224克）。
2. Webhook 把圖片送給視覺模型，模型回傳結構化的拆解：菜名、估計克數，以及各類食物的份數。
3. Bot 以 LINE Confirm Template 回覆：一段簡短摘要，加上 ✅ 儲存 / ❌ 取消 按鈕。
4. 按下 ✅ 後，紀錄會被儲存，bot 回覆今天剩下的額度：

✅ 已儲存：雞腿便當

今日還能吃：
五穀雜糧  ▓▓░░░  剩 2.0 份
豆魚肉蛋  ▓░░░░  剩 9.0 份
蔬菜      ░░░░░  剩 6.0 份
油脂堅果  ░░░░░  剩 4.0 份

確認這一步很重要。AI 估算很準，但不是完美的；使用者如果看到一個自己沒同意過的錯誤數字，就會不再信任這個產品。「先暫存、再確認」的流程讓使用者保有掌控權，同時仍然只需要一次點擊。

2. 把 Rich Menu 當作 app 的首頁

Rich menu 是聊天室底部常駐的導覽列。它由程式碼產生（SVG → PNG），透過 Messaging API 上傳，並用一支腳本設為預設，所以修改選單是一次 commit，而不是一次手動的後台操作。

3. 用 LIFF mini app 處理聊天做不到的事

點下「拍照記錄」會在 LINE 裡開啟一個 LIFF（LINE Front-end Framework）網頁 app。它就是一般的 Next.js 頁面，但帶著使用者的 LINE 身分執行，所以沒有登入畫面。它提供：

• 週檢視，包含每日統計與各類食物標籤
• 編輯與刪除紀錄
• 體重追蹤與趨勢圖
• 個人化營養目標

它也會默默把裝置的時區回報給伺服器，讓「今天」指的是使用者的今天——一個小細節，卻消除了一整類對旅行中或住在國外的使用者會發生的「差一天」bug。

4. 自然語言指令與可選的 AI 夥伴

除了照片，bot 也看得懂一般中文：日記（今日摘要）、週報（7 天回顧）、我今天還可以吃什麼（根據今日剩餘額度的 AI 建議）、低脂那一份來自什麼（哪一餐貢獻了那一份）、目標 蔬菜 5（更新目標）。使用者可以用 跟我聊天 開啟自由對話的 AI 聊天，再用 閉嘴 關掉——沒被邀請時，bot 從不主動開口。

架構

LINE app
  └─► Messaging API
        └─► /api/line/webhook  (Next.js on Vercel, Tokyo)
              ├─ text     → command router / AI chat
              ├─ image    → vision parse → confirm card
              └─ postback → save or cancel → allowance reply

LIFF mini app ──► Next.js API routes
Cron jobs     ──► weekly review · re-engagement · D1 reminder

Everything reads and writes Supabase (Postgres + RLS).

• Next.js App Router 用同一套程式碼提供 webhook、LIFF app、行銷用的 landing page，以及 SEO 部落格。
• Vercel，固定在東京區域，離 LINE 的伺服器與台灣使用者都近。
• Supabase Postgres，嚴格區分公開的 anon key（瀏覽器端，受 RLS 保護）與 service-role key（僅限伺服器端）。16 個編號的 SQL migration 追蹤資料表結構。
• OpenAI 模型，依任務挑選：照片與修正用較強的模型，文字紀錄用較便宜的模型。每次呼叫都經過同一個 gateway 函式，記錄每位使用者的 token 用量，所以每位活躍使用者的成本是一個查詢，而不是猜測。
• 把領域知識寫進程式碼。 六大類食物的份量規則被寫成程式，在模型回應後進行驗證，而不是相信模型記得營養表。

LINE 特有的經驗

幾件在 LINE 上很容易做錯、而我會帶進任何客戶專案的事：

• Reply token 很快就會過期。 Webhook 必須在幾秒內回應。慢的工作（視覺模型呼叫、資料庫寫入）必須夠快，或經過設計讓使用者能立刻得到回應。
• Push 訊息會消耗額度；reply 訊息不會。 設計流程時讓大多數訊息都是對使用者動作的回覆，把 push 留給高價值的時刻（每週回顧、一次性的喚回提醒）。
• 不要嘮叨。 喚回任務只會在使用者沉默 N 天時提醒一次——絕不每天提醒。被洗版的流失使用者會封鎖帳號，而封鎖是永久的。
• Template 與快速回覆勝過自由輸入。 按鈕能減少錯字、降低 AI 成本，也讓 bot 用起來像個 app。
• Webhook 簽章與密鑰。 每個請求都會以 channel secret 驗證；只限伺服器的金鑰絕不進入前端 bundle。

在正式環境營運

把 bot 上線只完成了一半。身為獨立開發者，要讓它保持健康需要一些自動化：

• 透過 LINE 的 on-call 告警。 每一個未捕捉的伺服器錯誤都會被指紋化並去重。第一次出現（以及任何回歸）會推送告警到我自己的 LINE 帳號。
• Agent 輔助修復。 一個排程執行的 coding agent 會接手新錯誤、調查 repo、撰寫修正、跑 lint 與測試，然後開一個草稿 pull request 給我審查。合併仍由人來做；agent 只是縮短從錯誤到修復的時間。
• 漏斗與留存報表。 第一張照片、第一次確認、回訪等事件都會被記錄，讓我看到使用者在哪裡流失——喚回提醒與改良後的新手訊息就是這樣來的。
• 每個 PR 都跑 CI。 Lint 加上 50 多個檔案的 Vitest 測試，包含所有依賴「今天」的功能都有凍結時間的測試。
• 用內容帶來新用戶。 一個實用指南部落格（便利商店怎麼吃、火鍋、大夜班餐點、TDEE）把搜尋流量導向 LINE「加好友」的 CTA。

如果你需要一個 LINE 產品，這代表什麼

減脂小豬是我自己的產品，但它的組成元件和大多數 LINE 專案需要的是同一套：

• 讓客戶不用安裝 app 就能互動 → LINE 官方帳號 + webhook bot
• 在 LINE 裡的表單、儀表板、預約或編輯畫面 → 內建 LINE 登入的 LIFF mini app
• 聊天室裡有品牌感的首頁 → 由程式碼產生的 rich menu
• 看得懂照片或自由文字的 AI → 視覺 + LLM pipeline，搭配「先確認再儲存」
• 排程提醒與報表 → 以 cron 驅動、考量額度規則的推播
• 確信它會持續運作 → 錯誤告警、CI、用量追蹤

我能協助的典型專案：店家與診所的會員與集點 bot、預約與提醒流程、用於訂單表單或客戶儀表板的 LIFF mini app、AI 客服或資料收集 bot，以及把 LINE 與既有後端整合。