學習我如何為我兄弟的汽車維修廠打造一個 AI 接線生。

我的兄弟經營一家豪華汽車維修廠，他每週錯過數百通電話，每月損失數千美元。他整天都在車底下忙碌。電話響了，他無法接聽，客戶掛斷電話並轉而聯繫其他店家。這就意味著一筆損失的生意——有時是 450 美元的煞車維修，有時是 2,000 美元的引擎維修——僅僅因為沒有人接聽就這樣消失了。

所以我正在為他打造一個 AI 接線生。我給它取名為 Axle（像汽車的傳動軸），因為這實在太貼切了。😏

這不是一個通用的聊天機器人。它是一個客製化的語音代理，可以接聽他的電話，了解他的確切價格、營業時間、服務政策，並且在它不知道的事情上能夠收集客戶的回電資訊。要正確實現這一點需要客製化建置，所以我首先爬取了他的網站資料，創建了一份產品需求文件（PRD），並將專案規劃成三個部分來建置。

第一步是確保 AI 能夠準確回答問題——不會出現幻覺或編造資訊。

原始的 LLM 在這裡非常危險。如果客戶詢問「煞車維修要多少錢？」，而 AI 猜測是 200 美元，但實際價格是 450 美元，這就會造成客戶期望落空並感到沮喪。解決方案是檢索增強生成（RAG）：而不是讓模型猜測，而是提供一個真實資訊的知識庫，並讓它僅從該知識庫中回答。

爬取了 Dane 的網站——我將他的服務頁面和價格提取成 markdown 檔案。從那裡我建立了一個結構化的知識庫，涵蓋了 21 個以上的文檔：每種服務類型、價格、週轉時間、營業時間、付款方式、取消政策、保固資訊、借用車輛，以及他專精的汽車品牌。

將知識庫嵌入 MongoDB Atlas——每個文檔都使用 Voyage AI (voyage-3-large) 轉換成一個 1024 維的向量。這些向量捕捉了每個文檔的語義含義，而不僅僅是關鍵字。它們與原始文本一起儲存在 MongoDB Atlas 中，並在嵌入欄位上建立 Atlas Vector Search 索引。

建置檢索管道——當客戶提出問題時，查詢會使用相同的 Voyage AI 模型進行嵌入，然後針對 Atlas Vector Search 索引進行搜尋。它會返回最語義上相似的前 3 個文檔——因此「煞車維修要多少錢？」即使這些確切的詞語沒有一起出現，也能正確檢索到煞車服務價格文檔。

連接 Claude 進行回應生成——檢索到的文檔會作為上下文傳遞給 Anthropic Claude (claude-sonnet-4-6)，並附帶嚴格的系統提示：僅從知識庫中回答，保持回應簡短且對話式，如果你不知道——就直接說明並提供留言選項。不允許出現幻覺。

在第一部分結束時，我可以在終端機輸入一個問題，並得到一個有根據、準確的答案。「換機油要多少錢？」→「傳統機油 45 美元，合成機油 75 美元。包含機油濾芯、液體補充和胎壓檢查。大約需要 30 分鐘。」

💡 我正在透過 MongoDB AI Learning Hub 邊學邊做——你也可以！快來看看如何建置你自己的 AI 代理！

接下來我必須將這個大腦連接到實際的電話線路上，讓客戶可以撥打。

我選擇 Vapi 作為語音平台。它處理了電話系統的所有事務：購買電話號碼、語音轉文字（透過 Deepgram）、文字轉語音（透過 ElevenLabs），以及即時將功能呼叫回我的伺服器。整個語音基礎設施都已處理好——我只需要建置它所呼叫的 webhook。

建置 FastAPI webhook 伺服器——每當有來電者提問時，Vapi 就會向我的 /webhook 端點發送一個工具呼叫請求，其中包含來電者的查詢。伺服器將其路由到 RAG 管道，從 Claude 獲得回應，然後將其發送回 Vapi，Vapi 會將其朗讀給來電者聽。整個往返過程必須足夠快，才能感覺像自然的對話。

透過 Ngrok 暴露——在開發過程中，伺服器在本地的 8000 埠上運行。Ngrok 會穿透一個隧道到一個公開的 HTTPS URL，我將其貼到 Vapi 的儀表板中作為 webhook 端點。Vapi 現在可以在電話打進來時即時訪問我的本地伺服器。生產環境中會將其移至雲端主機，但對於建置和測試，Ngrok 可以在兩分鐘內完成工作。

配置 Vapi 助理——在 Vapi 儀表板中，我設置了助理的問候語（「您好，感謝致電 Dane's Motorsport，有什麼可以幫您的嗎？」），連接了兩個工具（answerQuestion 用於 RAG 支持的回應，saveCallback 用於在問題無法回答時收集姓名和電話號碼），並將兩者都指向 webhook URL。

添加對話記憶——Vapi 會在每次請求時發送完整的對話歷史記錄，因此 RAG 管道會將先前的對話作為上下文。如果來電者詢問「你們的營業時間是？」然後接著問「輪胎輪換要多少錢？」，AI 會連貫地處理這兩者。

將每次通話記錄到 MongoDB——每次互動都會儲存在 calls 集合中：來電者的號碼、查詢、AI 的回應、是否轉接給真人、以及時間戳。來自未知問題的回電請求會進入一個單獨的 callbacks 集合，以便 Dane 可以跟進。這將電話系統變成了一個數據資產——他可以看到客戶最常詢問什麼、通話量何時激增，以及 AI 有多常轉接給真人。

然後，終於到了最需要迭代的部分：讓它聽起來對。

文字回應和語音回應完全不同。一個在螢幕上讀起來不錯的回應——帶有項目符號、格式化為「$45.00」的美元符號，或者以「當然！」開頭的句子——大聲說出來會非常糟糕。我必須專門為語音傳遞調整系統提示。

選擇合適的聲音——Vapi 與 ElevenLabs 集成，並提供了一個龐大的 AI 聲音庫供你選擇。我試聽了大約 20 種聲音，每次都朗讀相同的測試腳本：問候語、價格報價、轉接。大多數聽起來要麼太機械化，要麼太熱情，要麼根本不適合汽車維修廠。我最終選定了 Christopher——冷靜、自然、不急不徐。那種聽起來像真正懂車的人的聲音。讓這一點做得對比我預期的更重要；一個很棒的 AI 回應，如果用錯的聲音傳達，仍然會讓人感覺不對。

為語音重寫系統提示——短句子。沒有 markdown。沒有像「好問題！」或「當然！」這樣的填充詞。價格自然地說出來（「四十五美元」而不是「45 美元」）。回應限制在最多 2-4 個句子。目標是聽起來像一個知識淵博、友善的人——而不是一個讀網頁的聊天機器人。

測試轉接流程——當來電者詢問知識庫中沒有的資訊時，AI 不會猜測。它會告知來電者它沒有該資訊，詢問他們的姓名和一個方便的回電號碼，並將其儲存到 MongoDB。Dane 會收到一份回電列表——沒有遺漏的潛在客戶。

編寫整合測試——我建立了一個測試套件，涵蓋了 RAG 管道、webhook 處理器以及完整的端到端流程。這對於捕捉邊緣情況尤其重要：當 Vapi 發送格式錯誤的請求時會發生什麼，當向量搜尋未返回高於置信度閾值的結果時會發生什麼，當來電者沒有留下回電號碼時會發生什麼。

目前 AI 可以回答問題並收集回電。下一階段有幾個部分：將其連接到真正的日曆，以便它可以直接在通話中預約；添加簡訊通知，以便 Dane 在收到新的回電時立即收到 SMS；建置一個簡單的儀表板，以便他可以查看和管理所有待處理的回電；鎖定安全性以確保生產環境的穩健性；部署到 Railway，使其運行在持久的公共 URL 上；然後將其交給他實際與真實客戶一起使用。

Dane 每週錯過 100 多通電話。每錯過一通電話都可能是一筆生意。有些生意價值 50 美元，有些則高達 2,000 美元。這個系統 24/7 運行，從不讓客戶等待，並且像他一樣了解每一項價格和政策。

建置過程花了三個專注的衝刺。最困難的部分不是程式碼——而是讓語音語調聽起來對，使其聽起來像汽車維修廠的員工，而不是矽谷新創公司的代表。

如果你正在建置類似的東西，核心的見解是：不要為特定業務的語音代理使用原始的 LLM。將其建立在真實的知識庫上，限制它僅從該基礎回答，並在其他任何事情之前設計好備用流程。轉接路徑不是邊緣情況——它是一個核心功能。

這篇文章是在 AI 的協助下撰寫的。

將下一篇文章直接發送到你的收件箱，並在 Instagram 上關注我，獲取每日 AI 技巧和編碼內容。