背景
我們有一個診所案場,在通訊頻道上處理病患的預約往來。病患用自然語言留言——改約、療程問題、「我可以改成星期四下午過去嗎」——由 AI 助理負責對話。診所的班表就放在診所原本習慣的地方:一份由櫃檯維護的共用試算表,格子裡的標記慣例是同仁沿用多年的做法。
最直覺的做法,是讓模型自己讀班表,看到空檔就直接約下去。我們沒有這樣做,而不這樣做的理由,正是這篇文章有價值的部分。
規則一:哪些時段可以約,永遠不由模型決定
診所的班表把政策藏在慣例裡:某些時段保留給回診與諮詢專用,而且是用視覺標記呈現的,不是資料庫裡的欄位。新客療程永遠不該被排進這些時段。櫃檯同仁都知道這件事;讀著表格的語言模型卻不知道——它只看到一個空檔。
所以我們最先上線的功能根本不是預約,而是一道硬性閘門:保留時段在結構上就對助理關閉。不是「用提示詞叮嚀它避開」——是直接封死,由一段在模型之後、在任何動作碰到班表之前執行的程式碼強制把關。提示詞可以被說服;純函式不行。
一句話講完整個架構:LLM 負責萃取,確定性程式碼負責決定。 模型很擅長讀懂「下週四三點以後都可以,療程跟上次一樣」,並產出結構化的意圖:希望的時段、療程類型、病患身分。在那之後的一切,都是平凡、可測試的邏輯——時段分類、資格規則、時長計算——以資料上的純函式寫成,附帶單元測試,和其他程式碼一樣經過審查。
安全藏在無聊的細節裡
大部分的工程心力,都花在 demo 永遠不會展示的細節上:
- 療程時長來自診所自己的對照表。 每一個可預約的療程都有前置準備時間與療程時間,逐行與診所的紙本對照表核對——包括那一輪我們找出並修正了十九處不一致的核對。助理不可能提供一個實際時長塞不進去的時段。
- 報到時間是推導出來的,不是用猜的。 前置準備時間決定病患該幾點到,確認訊息會直接寫明。模型少做一次判斷,櫃檯少一次意外。
- 電話號碼以文字格式寫入。 試算表會毫不留情地吃掉以數字格式儲存的電話號碼開頭的 0。小 bug,真實世界的後果,確定性的修法。
- 模稜兩可的情況一律轉真人。 當需求無法乾淨地通過閘門——少見的療程組合、規則解不開的時段衝突、病患問到政策表沒有涵蓋的事——助理不會即興發揮,而是把對話連同完整脈絡一起交給真人。轉接是功能,不是故障模式。
清單裡的每一條判斷規則之所以存在,都是因為診所經營者做了一個決定,我們把這個決定寫進程式,而這段程式從此可被檢視。當經營者調整政策,我們改的是一個函式和它的測試——不是改一段提示詞然後祈禱。
我們為什麼這樣做
這個專案有一個週末就能出貨的版本:把班表丟給一個夠強的模型,加一段系統提示詞,讓它自己約。demo 會非常漂亮,而且大多數時候都能正常運作。問題就出在「大多數時候」。診所的班表是對真實病患與真實員工的承諾;失敗的樣子,是診療室被重複預約,以及櫃檯在第二次出狀況之後就再也不信任這個工具。
我們採用的切分——模型負責理解、確定性閘門握有決定權、閘門之外的一切轉交真人——前期多花工程成本,換回的是提示詞給不了的東西:預約邏輯在碰到病患之前可以被測試、事後可以被稽核,政策改變時只需要在一個地方修正。
這個模式不限於診所。任何 AI 助理觸碰到他人賴以運作的資源——行事曆、庫存、帳本——同一條界線都適用。讓模型讀,但別讓它說了算。