官網 AI 客服要做得可靠，關鍵不是「接上一個 LLM API」這麼簡單，而是要把對話路由、留單邏輯、通知機制與防濫用機制一起設計進去。以下我們用自家官網 noise-and-signal.com 正在運作的聊天機器人當實例，拆解實際架構、四層防護，以及上線第一週的真實數據——包含數據量還很小、也還沒有訪客自己手動輸入問題的誠實現況。
架構：一支路由、三種模式
我們官網的聊天機器人走同一支後端路由，用 Vercel AI SDK 的串流函式處理訊息，把訪客的對話紀錄轉成模型看得懂的格式後，以串流方式即時把回覆送回前端，單次請求的執行時間上限設在 30 秒。模型供應商是 OpenAI，程式碼中呼叫的模型字串是 gpt-5.6-luna。
對話分成三種模式：「報價」「釐清需求」與「一般問答」，由前端在請求中指定，每種模式各自有專屬的系統提示詞。三種模式共同遵守幾條規則：絕不在對話中透露具體價格、回覆一律用 Markdown 格式、每次只問訪客一個問題，而且要等到偵測到訪客有明確意圖之後，才會主動問一次聯絡方式——不會一開口就跟訪客要資料。
留單與通知：擷取到聯絡方式後怎麼處理
當對話中偵測到訪客留下聯絡方式，我們會用一支獨立的擷取邏輯處理，屬於「盡力而為」的設計：如果環境沒有設定對應的 AI 服務金鑰，這段擷取邏輯就會安靜地不執行，不會讓整個對話中斷。擷取到聯絡方式後，後端會用 Email 服務寄出通知信給我們——分成「新對話開始」與「擷取到聯絡方式」兩種通知信，兩者都用資料庫的原子更新操作（先確認尚未寄送過，才標記為已寄送並回傳結果）防止同一則通知被重複寄送兩次。同樣地，如果沒有設定寄信服務所需的金鑰與收件信箱，通知功能也會整個安靜地不執行，不影響訪客端的對話體驗。
所有對話紀錄存在資料庫的兩張表：一張存對話本身（包含國家、地區、城市、來源網址、UTM 行銷參數、裝置類型與聯絡方式等欄位），一張存逐則訊息內容。兩張表都啟用了列級安全性（RLS），而且刻意沒有設定任何存取規則——這代表只有伺服器端用服務金鑰才能讀寫，一般訪客端使用的金鑰完全沒有存取權限，等於資料庫本身多一層保護。至於訪客的地理位置資訊，我們只讀取平台（Vercel）預先解析好的標頭資料，從一開始就不會讀取或儲存訪客的原始 IP。
四層防濫用防護
一個公開的聊天端點，如果沒有防護，等於讓任何人都能免費耗用你的 LLM API 額度。我們官網目前疊了四層防護：
- 同源請求檢查：檢查請求的 Origin／Referer／Sec-Fetch-Site 標頭，擋掉不是從我們官網本身發出的請求。
- 速率限制：分兩層做，一層是記憶體內的權杖桶（token bucket），永遠啟用、反應最快；另一層是資料庫的原子計數，用來處理多台伺服器實例同時運作的情境。目前的規則是同一個訪客 10 分鐘內最多 20 次請求、一天最多 200 次請求，訪客身分是用 IP 加鹽後做雜湊識別，全程不存原始 IP。
- 請求體積與訊息數上限：限制單次請求的資料量、對話中保留的訊息則數與訊息總數上限，以及單則訊息的字數上限，避免有人送出超大的請求把系統塞爆。
- 輸出長度上限：限制模型單次回覆能產生的最大輸出 token 數，這同時也涵蓋了推理模型可能額外產生的思考過程 token。
值得誠實說的是，這套四層防護是「後來才補上」的：在最早期版本，這個公開端點基本上是直接花用我們自己的 OpenAI 額度、沒有任何防護，後續才陸續把同源檢查、雙層速率限制、體積上限與輸出上限一起補齊。如果您也在規劃官網 AI 客服，這條時間軸的教訓是：這些防護最好在上線「之前」就設計進去，而不是等被濫用了才回頭補。
上線第一週的真實數據
從 2026 年 9 月 15 日（UTC）起算的 7 天裡，我們官網的聊天機器人累積了 3 則對話、來自 3 位不重複訪客（2 位在台北、1 位在高雄，全部使用桌機、全部來自台灣），沒有任何一位訪客留下聯絡方式，每則對話都只有 2 則訊息（1 則訪客訊息加 1 則 AI 回覆，沒有人繼續追問）。
更值得誠實揭露的一點是：這 3 則對話的第一句話，全部逐字對應到我們設計的「一鍵起頭提問」預設按鈕文字，這代表當週沒有任何一位訪客是自己手動打字提問的。這不是行銷話術想呈現的漂亮數字，而是早期真實數據該有的樣子——樣本數小、互動深度淺，這種早期現況很適合拿來提醒自己：上線第一週的數據，還不足以拿來下任何結論，需要更長的觀察期。
下一步
官網 AI 客服真正的難度，不在把 LLM API 接進網站，而在把留單、通知與防濫用這三件事一起設計進架構，並且對早期數據保持誠實。如果您正在規劃官網或產品的 AI 客服導入，歡迎參考我們的 AI Agent 導入服務，或直接聯絡我們聊聊您的情境與需求範圍。