把用餐安排交給 AI
ByteBites 不是只回答餐廳問題，而是把餐廳搜尋、訂位確認、付款狀態、候補通知與停車提醒整合成一個跨 Web / LINE 的 AI Dining Concierge。
ByteBites
AI Dining Concierge
BYTEBITES DRAFT
確認訂位內容
500+
commits
從資料、AI、LINE、付款到部署持續迭代
120
AI tests
LINE / Web 對話與推薦回歸測試
2
entry points
Web 與 LINE 雙入口同步體驗
1
journey
從選店到出發的完整用餐流程
DEMO FLOW
上台就展示這 6 步
不要分散展示功能。照這條路線走，觀眾會看到一個完整產品，而不是幾個分開的小工具。
一句話說需求
使用者在 LINE 或 Web 輸入地點、料理、人數與時間，AI 先收斂意圖，不急著亂推薦。
回三張可行選項
推薦卡不只顯示店名，也帶出區域、菜色、適合情境與下一步動作。
對話產生訂位草稿
AI 整理店家、日期、時間與人數，先讓使用者確認，避免直接誤訂。
確認後才送出
Web 與 LINE 都支援確認卡；使用者也能回「沒問題」用自然語送出。
付款與候補同步
訂金、付款狀態、額滿候補與取消會同步在 Web / LINE 的同一套狀態 contract。
出發前停車提醒
訂位者若會開車，系統在出發前整理附近停車空位，並提供展示用車位保留流程。
WHY BYTEBITES
優勢要講成產品差異
你們的亮點不是 AI 會聊天，而是 AI 能把餐飲流程接起來，並且在高風險操作前先確認。
不是餐廳搜尋，是用餐安排
一般平台停在找店；ByteBites 把搜尋、訂位、付款、候補通知與停車提醒接成一條流程。
AI 先確認，再執行
高風險動作不靠猜。Web 與 LINE 都會產生訂位草稿，等使用者確認後才送出。
跨入口但同 contract
LINE 和 Web UI 可以不同，但背後共享推薦、訂位、付款、取消與通知狀態。
商家端也能展示價值
商家後台可以管理時段容量，讓 AI 訂位不是單純聊天，而是能落到營運資料。
ENGINEERING CREDIBILITY
不只 demo，是可演進的系統
報告時要讓教授知道：你們有處理資料治理、AI 回歸、LINE/Web contract、訂位付款狀態和部署穩定性，不是只有畫面。
Java backend 管理訂位、付款、候補、停車與商家容量
Python AI service 負責語意搜尋、LINE 對話、Web Agent 與狀態機
Qdrant semantic search 搭配分類 hard constraints，降低不相關推薦
RabbitMQ / notification flow 支援候補釋出與 LINE 主動通知
Flyway migrations 保持資料演進可追蹤，legacy seed 已安全移除
AI service 測試 120 passed，覆蓋 LINE / Web 對話與推薦回歸