我打造了一個不盲信 AI 的潛在客戶篩選器：實作方法揭秘

最近我收到一份客戶需求：從網站表單讀取所有詢問，用 Claude 進行資格篩選，儲存到 CRM，草擬回覆，並在發送前由人工批准。他們的驗收測試只有四行，我反覆閱讀：每個決定都需要理由。不能憑空捏造。沒有任何訊息可以在未經人工批准的情況下發送。

相同的詢問發送兩次不能重複。我見過的大多數 AI 潛在客戶評分工作流程都信任模型的判斷。這份需求不允許這樣做，所以我建立了一個讓模型展示其工作原理並隨後檢查其工作成果的系統。以下是其架構圖，以及每個階段背後的思考。

1. 潛在客戶接收：一個 Webhook 接收表單（姓名、電子郵件、電話、訊息）。一個 Code 節點清理欄位，並從電子郵件和訊息中建立一個 SHA-256 指紋，這樣即使有大小寫或額外空格，相同的詢問看起來也總是一樣。一個 IF 節點會丟棄垃圾訊息（沒有真實電子郵件，或訊息少於十個字元），以避免產生 AI 呼叫成本。

一個使用「行不存在」操作的 Data Table 節點會阻止任何已看過的內容。表單的雙擊絕不會產生兩個回覆。

2. AI 資格篩選：業務規則、回覆語氣等所有客戶設定都集中在一個名為「Client settings」的 Edit Fields 節點中。業務相關的內容沒有在其他任何地方寫死，因此將工作流程轉移到新客戶只需編輯一個節點。一個使用 Anthropic 模型和 Structured Output Parser 的 Basic LLM Chain 會根據這些規則對詢問進行評分。

對於每條規則，Claude 必須返回「符合」、「不符合」或「未知」，並附上訊息中的確切文字作為證據。然後是我最關心的部分：一個普通的 Code 節點會取出 Claude 給出的每個引文，並在原始訊息中搜尋它。如果「符合」的引文不在原文中，則會降級為「未知」。

如果「不符合」可以沒有引文，因為你無法引用不存在的東西，但錯誤的引文仍然會使其降級。結果會是「符合資格」、「需要更多細節」或「不適合」，模型無法憑空捏造出任何一個結果。

3. CRM 整合：透過四個 HTTP Request 節點與 Private Integration Token 連接 GoHighLevel：按電子郵件搜尋聯絡人，更新或插入聯絡人並加上標籤，更新或插入一個銷售流程卡片（不適合時狀態為「已丟失」，以保持銷售流程整潔），並將完整的評估作為備註寫入聯絡人。

我使用 HTTP Request 而不是 HighLevel 節點，因為該節點沒有更新或插入功能，也沒有備註功能。

4. 後續回覆草擬：第二個 LLM Chain 會撰寫一個簡短的回覆，回答它能回答的問題，並且只詢問標記為「未知」的規則。它被告知絕不能確認價格或可用性。草稿會進入 Data Table，標記為「等待批准」。

5. 人工批准：Slack 節點處於「Send and Wait」模式，帶有一個自訂表單：選擇「按原樣發送」、「用我的編輯發送」或「不發送」。訊息會顯示詢問內容、帶有引文的檢查結果、聯絡人是新客戶還是現有客戶，以及草稿。

6. 發送與記錄：只有在按下該按鈕後：Gmail 發送回覆（如果您選擇編輯，則為您編輯過的文字），Data Table 中的行會被標記為「已發送」並記錄決定，銷售流程卡片會移至「已聯絡」。選擇「不發送」則會記錄該決定，並且不會發送任何內容。

測試教會我的事：我最初的證據檢查過於嚴格。當 Claude 正確地將一個推銷電話稱為「不適合」並將規則 1 標記為「不符合」時，它沒有提供引文，因為沒有什麼可以引用的。我的程式碼將缺失的引文視為未驗證，將其降級為「未知」，然後該推銷被歸檔為「需要更多細節」，並帶有一個開放的銷售流程卡片。

經過四次測試詢問後，規則變成了現在這樣：聲稱某物存在需要引文；聲稱某物不存在則不需要。那一次執行比任何規劃都更能改變設計。

整個系統有 25 個節點。Claude 在其中兩個節點中運行。其他 23 個節點是讓這兩個節點值得信任的原因。我很樂意回答有關任何階段的問題，也很好奇是否有人有比字串搜尋更簡潔的方法來驗證模型輸出與原始文本的一致性。