# 官網 AI 客服怎麼做：串接、留單、通知與防濫用

> 以諾訊官網的 AI 聊天機器人為例，拆解架構、留單與通知、四層防濫用，以及第一週真實數據。

- URL: https://noise-and-signal.com/insights/website-ai-chatbot-implementation
- Author: 翁睿承 (諾訊科技 Noise & Signal)
- Published: 2026-09-27
- Tags: AI Agent, 網站製作
- Language: zh-TW

---
官網 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 額度。我們官網目前疊了四層防護：

1. **同源請求檢查**：檢查請求的 Origin／Referer／Sec-Fetch-Site 標頭，擋掉不是從我們官網本身發出的請求。
2. **速率限制**：分兩層做，一層是記憶體內的權杖桶（token bucket），永遠啟用、反應最快；另一層是資料庫的原子計數，用來處理多台伺服器實例同時運作的情境。目前的規則是同一個訪客 10 分鐘內最多 20 次請求、一天最多 200 次請求，訪客身分是用 IP 加鹽後做雜湊識別，全程不存原始 IP。
3. **請求體積與訊息數上限**：限制單次請求的資料量、對話中保留的訊息則數與訊息總數上限，以及單則訊息的字數上限，避免有人送出超大的請求把系統塞爆。
4. **輸出長度上限**：限制模型單次回覆能產生的最大輸出 token 數，這同時也涵蓋了推理模型可能額外產生的思考過程 token。

值得誠實說的是，這套四層防護是「後來才補上」的：在最早期版本，這個公開端點基本上是直接花用我們自己的 OpenAI 額度、沒有任何防護，後續才陸續把同源檢查、雙層速率限制、體積上限與輸出上限一起補齊。如果您也在規劃官網 AI 客服，這條時間軸的教訓是：這些防護最好在上線「之前」就設計進去，而不是等被濫用了才回頭補。

## 上線第一週的真實數據

從 2026 年 9 月 15 日（UTC）起算的 7 天裡，我們官網的聊天機器人累積了 3 則對話、來自 3 位不重複訪客（2 位在台北、1 位在高雄，全部使用桌機、全部來自台灣），沒有任何一位訪客留下聯絡方式，每則對話都只有 2 則訊息（1 則訪客訊息加 1 則 AI 回覆，沒有人繼續追問）。

更值得誠實揭露的一點是：這 3 則對話的第一句話，全部逐字對應到我們設計的「一鍵起頭提問」預設按鈕文字，這代表當週沒有任何一位訪客是自己手動打字提問的。這不是行銷話術想呈現的漂亮數字，而是早期真實數據該有的樣子——樣本數小、互動深度淺，這種早期現況很適合拿來提醒自己：上線第一週的數據，還不足以拿來下任何結論，需要更長的觀察期。

## 下一步

官網 AI 客服真正的難度，不在把 LLM API 接進網站，而在把留單、通知與防濫用這三件事一起設計進架構，並且對早期數據保持誠實。如果您正在規劃官網或產品的 AI 客服導入，歡迎參考我們的 [AI Agent 導入服務](https://noise-and-signal.com/services/ai-agent)，或直接[聯絡我們](https://noise-and-signal.com/#contact)聊聊您的情境與需求範圍。

## FAQ

### 官網 AI 客服的基本架構是什麼？

核心是一支後端路由接收訪客訊息、串接 LLM 供應商並把回覆以串流方式送回前端，再依模式切換不同的系統提示詞。我們自家官網用 Vercel AI SDK 的串流函式處理，並分成「報價」「釐清」「一般問答」三種模式各自設計提示詞。

### AI 客服要怎麼把訪客資料變成名單？

除了讓訪客直接留下聯絡方式，也可以在偵測到明確意圖後才主動詢問一次聯絡方式，避免一開口就要資料造成反感；擷取到聯絡方式後，再用後端服務即時寄出通知信給窗口，避免漏接。

### 官網 AI 客服要防範哪些濫用？

至少要考慮同源請求檢查、速率限制（避免短時間內被大量呼叫）、請求體積與訊息數上限，以及輸出長度上限，這四層合起來才能讓一個公開端點不會被人濫用去耗用你的 API 額度。

### 聊天機器人上線後多久才會有有意義的數據？

我們自家官網從 2026 年 9 月 15 日起算的 7 天裡，對話量還很小，而且訪客多半是點擊預設的一鍵提問按鈕，很少有人自己手動輸入問題；建議先誠實看待早期數據的樣本數，不要急著下結論。

### 諾訊的官網 AI 客服導入怎麼報價？

諾訊的 AI Agent 導入專案採依需求評估，不提供固定價目表。我們會先釐清要串接的系統、留單與通知流程，再抓出時程與預算區間。