
客戶在北美 想開發能讓顧客用手機簡訊 訂餐的系統
可能是給自家多間餐廳使用 也可能是要做 SaaS
自家用的話資料庫設計單純一些
SaaS 的話 看是做成 multiple tenant vs Row-Level Tenancy
大致拆解為三塊模組:簡訊下單、訂單確認、送件到門市 POS 機器
Toast 是北美的餐飲 POS 業者 搜尋 toast pos api 就有公開文件
台灣常見的 iCHEF、肚肚、快一點 我印象沒聽過公開 api 也沒聽過有人在串 -> 需要確認
這模組難度不高 就是根據官方規格 驗證串接 -> 把訂單 送到 pos 雲端主機 -> pos 業者會完成後續整合
使用 SMS 作為 input
北美可以用 twilio api 發送簡訊
收到顧客簡訊 也可用 twilio webhook 發送 http post 到自家主機
文字訊息來來回回 跟 line chatbot 或各種通訊軟體 chatbot 沒有差別
台灣有多家 sms 業者 但好像沒聽過有人在串 webhook -> 需要確認
至於台灣廠商可以用 twilio 嗎 應該可以 -> 需要確認
這模組難度不高 但需要試用一下各家 sms 服務 確認簡訊送達率
這是整個專案最有挑戰性的地方
這個 ai agent 要在對話來回中 根據對話內容
如何讓 ai agent 能進入這四種流程 -> Pattern Note #01:AI Agent 與控制流程管理
這沒什麼 先把菜單上傳到 google drive 之類地方 再用縮網址服務即可
llm 領域有個術語叫做 inference
簡單講就是 llm 足夠聰明 你給他期待資料的結構定義
他就能從自然對話中知道 要推論出什麼資料傳到 tool function
過敏食材 就用一個 array of string 表示即可 系統紀錄這個陣列 廚師自然看得懂
[
'type' => 'function',
'function' => [
'name' => 'confirm_allergies',
'description' => '確認客戶的食材過敏資訊。這是必須的第一步,在確認訂單之前必須完成。',
'parameters' => [
'type' => 'object',
'properties' => [
'allergies' => [
'type' => 'array',
'items' => ['type' => 'string'],
'description' => '客戶過敏的食材列表,如果沒有過敏則為空陣列',
],
],
'required' => ['allergies'],
],
],
],
如此定義 tool function 即可 除非案主需求 要根據不同過敏食材 改變後續流程與邏輯
Pattern Note #02:AI Agent 的狀態預覽與確認模式
這個不難 確認訂單的時候 會在資料庫 orders table 建立一筆狀態未付款的 row
實作一個 routing 例如 /orders/{hashid}/payment
在後續對話中 -> 提供這個 url -> 顧客點擊之後 顯示一個頁面 -> 支援多種付款方式即可
我對這部份有點疑惑 研究了一下 做了些 poc
Pattern Note #03:AI Agent 的狀態持久化(存進資料庫)
Pattern Note #04:AI Agent 呼叫 tool function 之後的狀態持久化
我對這部份有點疑惑 研究了一下 做了 poc
Pattern Note #05:AI Agent 的會話續用與訂單重置
案主提到後續或許需要串接 DoorDash/Uber Eats
要留意在付款完成的當下 預留可以 trigger 更多 event 的彈性
然後就是根據外送平台的 api 文件 串接而已
如果呼叫的時間點不是付款完成 那就是看 POS 系統是否有 完成訂單 事件時間點 能否 webhook 繼續往外串接
簡訊每則來回都要費用 以台灣業者來說 我印象收費每則是1元吧 這很昂貴吧
各種點餐 ui、表單 ui 已經很成熟 有必要做成自然對話的 chatbot 嗎?
這位北美案主怎會想開發這種系統?這需要在會議上確認
但也是可以理解 案主想協助餐廳 擺脫第三方訂單系統的抽成