把客人的一句話
變成一筆正確的訂位

在拆解任何一個零件之前，先記住一個觀念：無論客人是想訂位、改訂、取消，還是只是問「有沒有停車場」，所有訊息走的都是同一條鏈。差別只在「中間哪一段需要動用比較重的工具」。把這條鏈記熟，後面每一章都只是在放大其中一塊。

要看懂後面所有設計，只需要先建立一個直覺：把「理解」和「事實」這兩件事，交給兩個完全不同的東西去做。這條分工就是整個系統的第一條定律。

1.1為什麼一定要分工

大型語言模型（LLM）非常會「猜人話的意思」，但它不可靠地計算事實。如果讓它自己決定「今天還有沒有位子」「訂金收多少」，它會用很有自信的口氣講出錯的數字——這在餐廳場景是災難：超賣、報錯訂金。所以我們把責任切開：

• LLM 只負責兩件事：把客人任何寫法的話讀懂（理解層）、決定用什麼語氣跟客人講。
• 所有事實由程式算：有沒有位、剩幾位、訂金多少、能不能改——這些一律走確定性程式（真相層）。

1.2四層架構：把規則關進閘門

「說真話」不是寫在 AI 的腦袋裡，而是寫在一套四層架構裡。任何商業規則都不可以塞進畫面或 AI，而要拆成四層，各司其職：

理解層的工作，是把客人那句口語變成結構化資料（日期、時間、人數、意圖）。早期我們只「問 LLM 一次」就收工——但這太笨。這一章把它升級成會自己查資料再回答的 Agent 迴圈。

2.1一次性抽取器的極限

「問一次」的模式是：訊息進來 → 丟給 LLM → 它吐一段回覆。問題是它什麼都不能查——不知道今天有沒有位、不知道客人之前有沒有訂位，只能憑訊息本身猜。客滿了它只會乾巴巴說「客滿」，不會主動找替代時段。

2.2Agent 迴圈：想 → 查 → 再想

Agent 迴圈（業界稱 tool-calling / function calling）讓 LLM 多了一隻手：它可以在回答前，自己決定「我需要先查一下」，呼叫一個工具，看到結果後再繼續想，繞上好幾圈，最後才給出接地的回覆。

Agent 有手，但手要握得住東西。這一章是全書的「元件表」：AI 能呼叫的工具。工具分兩種——唯讀工具（只看不動）可以放心讓 AI 自由用；寫入工具（會改資料）一律加護欄。

3.1唯讀工具：AI 的眼睛

每一個工具內部都是確定性程式——它去查真實資料、回傳事實，AI 不自己算。這就是第一原則的延伸：AI 透過工具「看見」真相，而不是「想像」真相。

3.2寫入工具與三層護欄

會「改資料」的工具危險得多。我們用一道護欄光譜把它們分成三級，越不可逆的動作，AI 的權限越小：

這一章是骨幹。AI 給出的回覆，在送到客人面前之前，要先通過一道決策閘。它的作用就像電子電路裡的箝位：把 AI 過度樂觀的承諾，強制壓回「事實允許的安全範圍」。

4.1箝位：把承諾壓回事實

AI 可能讀懂了「今晚 8 位」，也擬了一句溫暖的「幫您留好了」。但在出口前，程式會去 check_availability 查真相。如果真的可訂，就放行 AI 那句溫暖的話；如果其實客滿，就把回覆換成確定性版本——「不好意思客滿了，這幾個時段還可以…」。AI 的語氣再好，也不能突破事實的天花板。

4.2哪些事走真相層

當客人想改訂位、取消，AI 不會自己動手——它提議，老闆按下。這一章談兩件事：怎麼把提議變成按鈕；以及怎麼讓系統記得「這顆按鈕已經給過、已經被按過」，不重複騷擾老闆。

5.1提議 → 按鈕 → 老闆按

客人說「前面兩筆都取消」，AI 先用 find_customer_reservations 查出他有哪幾筆，然後輸出一組 提議動作（proposed_actions），每筆指名「對哪一天那筆做什麼」。POS 把每筆比對到真實訂位、長出一顆按鈕；老闆按下去，才跑第 1 章的四層 API（Gate 在伺服器端再驗一次）。

5.2用「現有欄位」管理按鈕狀態

一張「待接單」卡片有三種狀態。我們不發明複雜的新欄位，而是用三個既有訊號精準描述它的一生：

前五章讓 AI 會做事；這兩章讓它越用越聰明。核心洞見是：學習的東西要分兩種——私有知識（這家店的事實）和共有知識（怎麼讀懂訊息）。分清楚，才不會存一堆沒用的流水帳。

6.1流水帳 ≠ 記憶

如果把每一則訊息原封不動存起來叫「學習」，最後只會得到一大堆沒結構的紀錄。業界一定把兩者分開：

6.2私有：好冷啟動，靠認可累積

私有知識（營業時間、座位數、寵物友善、菜單）很好冷啟動：開店前把設定、FAQ、菜單填完就有足夠的料。剩下的邊界案例靠日積月累——而且只有「老闆原封不動送出的回覆」才會晉升成記憶（代表這題答對了）。老闆大改過的，學改後的版本；沒送的，不學。這叫回饋閘門（feedback-gated memory）。

6.3共有：問題共有，答案私有

巧妙的地方在這：「有沒有停車場」這個問題，每家店都該回答，所以它屬於共有問題清單；但海邊小巫答「有」、別家答「沒有」，答案是私有的。新店一開張，系統就能拿這份清單請他預填——這就是數據護城河：用得越久、店越多，新店冷啟動越快。

6.4零重複設定：完整度儀表板

新店要回答共有清單時，怕跟 POS 既有設定重複填。解法是把帳號管理頁做成完整度儀表板，而不是第二個輸入框：

• POS 已有對應設定的問題（營業時間、座位數）：只讀現況顯示狀態（✅已設定 / ⚠️未設定 → 點了跳去 POS 設定）。單一真相＝POS，不重複輸入。
• POS 沒有欄位的問題（停車、Wi-Fi）：才在這頁用選擇題作答（有 / 沒有）→ 存成 FAQ。

共有知識的第二種，是「怎麼讀懂訊息」的判斷規則。這一章用一個經典難題收尾：6.21 到底是 6 月 21 日，還是 18:21，還是 6:21？答案不是死背，而是一套判斷流程。

7.1標準消歧流程：四步決策

遇到任何模糊的數字，都套用同一套優先序。能在前一步定案就不往下走：

7.2防汙染：共有規則要審核才上線

共有規則一旦更新，會影響所有餐廳。一條壞規則就是全網災難。所以共有規則走「提議 → 審核門檻 → 晉升」：門檻可以是「跨 M 家店、被同方向更正 N 次」，或人工審。未達門檻只記不啟用。共有內容一律去個資、去店名。

客人不只在 LINE。他們也在 Instagram、Facebook 私訊。但我們不為每個平台養一隻 AI——而是一個大腦，多個管道：所有平台的訊息正規化進同一個收件箱，交給同一套理解層處理，再用對應的送出器回覆。

A.1該認識的零件一覽

A.2建議的實作順序（Roadmap）