#W9 — LINE@ 自動化 + Chat System 整合

老闆 wish:「做一個 line@ 自動化程式,可以經過 AI 分析層,輸出訂位資料給 POS,POS 彈出新的訂位提示。聊天系統可否使用 line@ 服務?」3 個方向(推薦 B 雙系統)+ Phase Plan + cost 估算。

📍 老闆原話

做一個 line@ 自動化程式,可以經過 AI 分析層,輸出訂位資料給 POS,POS 彈出新的訂位提示。
不知道網站上和 POS 的客人端和餐廳端的聊天系統可否使用 line@ 服務就好?把客人端的聊天訊息送到 line@ 或是餐廳端的 line

📊 現狀 audit

既有的 chat 系統

chat_conversations 表(client-server 對話)
chat_messages 表
ChatWidget.tsx(客人端網站懸浮窗)
POS 端有對應 view 接收

既有的 LINE 整合(初級)

notify_rejection_via_line() trigger function 存在
但只用 LINE Notify(已停用 API 2025/04)做 1-way 通知,不是 LINE OA
沒 LINE webhook,沒收訊息回 server

沒做的事

LINE OA(Official Account)— 完全沒接
LINE webhook → AI 解析訂位 → 寫 DB → 推 POS
客人 LINE 訊息 ↔ 餐廳老闆 LINE 雙向轉發

🔴 為什麼這 wish 不能完全睡覺時段完成

要 LINE OA 帳號 + Channel Access Token:老闆自己去 LINE Business 申請,AI 做不到
LINE 官方審核:Messaging API 申請 + Webhook URL 設定要老闆同意
AI 分析成本估算:每次客人傳訊都吃 Claude API token,要先設計成本上限
隱私 + 法規:LINE 對話資料屬於個資,需 PIPA / GDPR 同意流程
客戶體驗複雜:客人在哪裡傳 ?(LINE 對話 / 網站 chat widget / app 內 chat)雙向同步邏輯複雜

💡 設計選項 — 3 個方向

Option A · 純 LINE OA 取代既有 chat(激進)

客人加 LINE OA 才能聊
不再用 chat_messages 表
餐廳老闆從 LINE 後台 / app 回訊

優點:用 LINE 既有 UX,客人熟悉
缺點:綁死 LINE,不能 web / app 直接聊;非 LINE 用戶失聯

Option B · 雙系統並存 ⭐ 推薦

chat_messages 仍存 DB
加 LINE bridge:LINE OA 訊息 → server → 寫 chat_messages
餐廳老闆在 POS 回 → 寫 chat_messages → bridge 推回 LINE OA
客人愛用哪邊都可

優點:不破壞既有體驗,LINE 是 added channel
缺點:雙系統同步邏輯

Option C · LINE OA 純做訂位 entry(最 minimal)

只接收訂位相關訊息「我要訂位明天晚上 6 點 4 人」
AI 解析 → 寫 reservation → 推 POS
其他訊息走既有 chat

優點:範圍最小,風險低
缺點:客人可能用 LINE 問非訂位事被 ignore

🛠 Phase Plan(假設老闆選 B)

Phase 0 · 商業 + LINE 設定(老闆做)1-3 天

申請 LINE OA(免費 200 則訊息 / 月,超過 NT$0.20/則或月費 NT$800 6,000 則)
啟用 Messaging API
給 AI Channel Access Token + Channel Secret
餐廳老闆裝 LINE Official Account app 接收 push

Phase 1 · Webhook + 基礎接收1 週

新檔案:

supabase/functions/line-webhook/index.ts — 接收 LINE event
supabase/functions/line-reply/index.ts — 推訊息回客人

DB:

CREATE TABLE line_oa_channels (
  id UUID PK, restaurant_id UUID,
  channel_id TEXT, channel_secret TEXT,
  access_token TEXT,
  webhook_url TEXT,
  enabled BOOLEAN
);

CREATE TABLE line_user_bindings (
  id UUID PK,
  user_profile_id UUID NULL,  -- 若客人連結帳號
  line_user_id TEXT UNIQUE,
  display_name TEXT, picture_url TEXT,
  restaurant_id UUID
);

Phase 2 · AI 解析訂位意圖1-2 週

邏輯:

LINE webhook 收到 message
Claude API 解析:「我要訂位明天晚上 6 點 4 人」→ {action: "book", date, time, guests}
走既有 create_reservation orchestrator
推 LINE OA「✅ 已為您訂位...」+ POS 端 silent push

Tech:

@anthropic-ai/sdk(已用過,token 約 100-500 / message)
prompt template:few-shot examples 餐廳訂位場景
不確定時走「請輸入完整訊息」fallback

Cost 估算:假設 100 則 LINE / 天 × 200 token = 20K token / 天 / 餐廳。Claude Haiku $0.25 / 1M token → ~ $0.005 / 餐廳 / 天 → 月 NT$5 — 超低成本

Phase 3 · 雙向 chat bridge1-2 週

邏輯:

非訂位的 message(問營業時間 / 客訴 / 等)→ 寫 chat_messages 表
餐廳老闆在 POS chat view 回 → 同時推 chat_messages 跟 LINE
客人在 LINE 看到回覆

Edge case:

客人在 LINE / chat widget / app 三邊都聊 → 全部歸到同一 chat_conversation
識別方式:line_user_id 或 user_profile_id

Phase 4 · Rich UI(LINE Flex Message)1 週

範圍:訂位確認 / 訂金通知 / 取消按鈕用 LINE 卡片(豐富 UI)

⏱ 時間估計

Phase	時間	依賴
0 老闆 LINE 申請	1-3 天	老闆
1 Webhook + 基礎	1 週	Phase 0
2 AI 解析	1-2 週	Phase 1
3 雙向 bridge	1-2 週	Phase 1
4 Rich UI	1 週	Phase 1

MVP(Phase 0-2)約 2-3 週,完整體系約 5-7 週。

❓ 給老闆的問題

Q1. 要選 A / B / C 哪個方向?

⚠️ 風險

LINE Messaging API 申請審核 1-3 天
Webhook URL 必須 HTTPS + 公開可訪問(我們有 chefsmate.app OK)
LINE channel secret / token 洩漏 = 整個 OA 被盜 → 必須 supabase vault 存
客人 LINE display name 可能不是真名 → 訂位識別要靠手機 / email
AI 誤解訂位意圖風險:必須有「確認訂單」步驟才寫 DB

2026-05-17 #W9 spec · 等老闆 confirm Option + 5 問題 + 申請 LINE OA 才動 code