針對 AI 外展的驗證與治理層

確定性驗證器決定您的 AI 外展被允許寄出什麼。

AI SDR 以數量為優化目標，而單次處理模型會把過時來源、錯誤實體與過度宣稱的陳述原封不動地寄出。Veracity Engine 讓 LLM 撰寫草稿，再由純 Python 檢查剔除每一項未經證實的陳述、為剩餘內容評分，並將其送入依風險校準的政策閘門。代理人提供建議，程式碼作出決定。

100%

當有陳述得以保留時的寄出完整性

寄出郵件中的每一項陳述皆有來源依據

25/25

標註黃金集上的判定準確度

確定性且可重現（25 案例基準）

寄出前的確定性檢查

依據檢驗、實體比對、時效有效性

這是可實際運行的示範。擷取、CRM 與郵件寄送皆為模擬，潛在客戶除 Werner Enterprises 外皆為合成；Werner Enterprises 的 10-K 摘錄為真實公開紀錄。

沒有驗證的數量，所摧毀的管線多於它所創造的

那些廣為人知的 AI SDR 翻車事件背後的失敗模式。

AI SDR 的設計就是要寄得更多。單次處理 LLM 會幻覺出可量化比例的潛在客戶特定陳述，而個人化工具從不把產出的陳述重新對照一份當前、實體正確的來源加以驗證。於是過時來源、錯誤實體與過度宣稱的陳述原封不動地寄出，驗證是寄出後才外掛上去，或根本從未發生。

產業背景很嚴峻。單次處理 LLM 會幻覺 12 至 18% 的潛在客戶特定陳述（AI SDR Industry Report, 2026）。企業 AI SDR 年度流失率達 50 至 70%（UserGems, 2026）。11x.ai 募得 $74M，卻在 2025 年崩潰，流失率達 70 至 80%（TechCrunch）。僅 7% 的企業已有針對代理式系統的專屬治理（Deloitte, 2026），而 Gartner 預估到 2027 年將有超過 40% 的代理式 AI 專案被放棄。自 2025 年 11 月起，垃圾郵件率高於 0.3% 即會觸發 Gmail 在 SMTP 層級拒收，網域恢復需 6 至 12 週。

真正的缺陷不是文法不佳。文法完美無瑕，這反而更糟。危險在於一項引用正確卻被誤導性使用的陳述：從過時來源抽出的真實事實、關於同名錯誤公司的真實事實，或來源本身即予反駁的廠商宣稱。我們稱之為脈絡誤用，更好的基礎模型並無法消除它。即使是完美的模型，仍無法向 FINRA 或 GDPR 證明是哪一份當前來源為哪一項陳述背書。

Veracity Engine 如何運作

LLM 撰寫草稿。確定性程式碼決定什麼能寄出。這是神經符號：神經撰寫，符號驗證。

管線依序執行 Lead，然後 Research（一份事實表（Fact Sheet），其中每一項事實都綁定一份註明日期的來源），然後 Draft（僅能使用事實表的 Writer LLM），然後 Verify（確定性檢查），然後政策閘門，然後簽署的稽核回執，然後模擬的 CRM 回寫。驗證步驟不是 LLM 評判 LLM。它是純 Python，因此相同輸入每次都產生相同判定。

三項確定性檢查

每一項事實陳述都會對照其引用來源加以檢驗。第一項未通過的檢查勝出，優先順序為：unsourced，然後 contradicted，然後 entity mismatch，然後 stale。

1. 依據檢驗

該陳述是否由來源片段所蘊含？內容 token 的重疊必須至少達到 0.5，且公司名稱 token 會被排除，因此陳述不能只靠重複公司名稱就拿高分。

2. 實體比對

來源是否關於這家確切的潛在客戶，而非同名的另一家公司？關於同名不同公司的來源會判定失敗，即使用字對得上。

3. 時效有效性

若陳述使用近況用語（「recently」、「just」、「now」、「this week」），來源必須在 365 天以內。較舊的來源會被標為過時，即使事實為真。

另有兩道防護並行：廠商矛盾檢查，以及 0.3 的句子忠實度下限，以阻止即時 LLM 把有效的事實 id 掛在一句幻覺句子上。判定詞彙驅動介面顏色：supported（綠）通過；stale（琥珀色）、entity_mismatch（紅）、contradicted（紅）與 unsourced（紅）則否。

政策閘門

閘門會剔除每一項非 supported 的陳述，然後回報兩個數字。真實性分數是草稿中 supported 陳述除以事實陳述總數，也就是 AI 所寫內容實際上為真的比例。只要至少有一項陳述通過，寄出完整性即為 100%，因為寄出的郵件便只含有來源依據的陳述。這就是設計保證。

路由依風險而定。若沒有任何安全的陳述通過，或草稿涵蓋率低於 0.5，郵件會被改寫。即使是 100% 乾淨的草稿，若屬高價值（受監管、或高階主管、或至少 $100,000 的交易）也會送交人工審查。否則即為自動合格。對照模式「標準 AI SDR」會研究、撰寫並寄出，寄出前驗證的陳述為 0；應用程式以事後陰影檢查顯示那些已經寄出的內容。

關鍵破綻，從頭到尾走一遍

示範語料中的三個潛在客戶（錨定日期 2026-06-17）。以下每張圖都是運行中應用程式的螢幕截圖。

來自過時來源的真實事實，仍然不該寄出

對於 Northwind Logistics 這個潛在客戶（合成的中型市場 3PL），草稿聲稱該公司「recently expanded into APAC」。來源是真實的 Northwind APAC 新聞，依據重疊為 100%，實體正確。但來源日期為 2019-03-14，距今 2,652 天（約 7.3 年），對照 365 天的近況窗口，因此時效有效性未通過，該陳述被剔除。Veracity Engine 保留有依據的陳述（由一則日期為 2026-06-09 的職缺公告所證明、正在招募六名 Salesforce 管理員的動作領頭），抓到兩項不良陳述，並寄出一封 100% 有來源依據的郵件。

Northwind 潛在客戶的 Veracity Engine 結果：寄出郵件 100% 有來源依據，草稿 60% 可驗證，兩項陳述被抓到並剔除，原因於行內顯示。 — Veracity Engine 結果：寄出完整性 100%，草稿可驗證 60%，兩項陳述被抓到並劃掉，附原因。

證據面板顯示依據檢驗為 100% 且實體 OK，但時效檢查未通過：來源年齡 2,652 天超過近況陳述的 365 天，因此判定為 stale。 — 證據面板：依據檢驗通過、實體通過、時效有效性未通過（來源年齡 2,652 天超過 365 天窗口）。判定：stale。

同一缺口出現在真實的 SEC 申報文件上

Werner Enterprises, Inc. 是真實的上市公司，來源 W1 與 W2 是其 FY2023 Form 10-K 的逐字摘錄（SEC EDGAR，CIK 0000793074，申報於 2024-02-26）。草稿陳述「recently growing your One-Way Truckload fleet to 2,735 trucks」在事實上為真，但該申報文件已超過兩年，因此「recently」的框架被抓為 stale。這正是 SEC 申報文件個人化工具所留下的時效誤用缺口。（此潛在客戶中的聯絡人與職缺公告為合成；僅 Werner 及其 10-K 摘錄為真實。）

一項由 FY2023 SEC 10-K 背書的真實 Werner Enterprises 陳述，因申報文件對照 365 天近況窗口已超過兩年而被抓為 stale。 — 一項真實的 Werner 10-K 陳述，事實準確，卻因近況框架而被抓為 stale。

同名實體碰撞

回到 Northwind 潛在客戶，草稿還聲稱一輪「$40M Series B」。所引來源為真，但談的是「Northwind Inc.」，一家奧斯汀的資安新創，而非「Northwind Logistics」。實體比對未通過，該陳述在寄出前即被剔除。

證據面板顯示實體比對失敗：所引募資來源談的是 Northwind Inc.，一家奧斯汀的資安新創，而非 Northwind Logistics。 — 實體不符：募資來源描述的是 Northwind Inc.，而非 Northwind Logistics。

治理關乎風險，而不只是正確性

Atlas Capital Markets 是合成的、受 FINRA 監管的經紀自營商，聯絡人為營收長，交易金額 $220,000。即使草稿 100% 乾淨、完全有來源依據，政策閘門仍強制送交人工審查，因為它受監管、對象為高階主管，且高於 $100,000 門檻。乾淨的草稿並不等於可寄出的草稿。

Atlas Capital Markets 被轉交人工審查，因為它受監管、對象為高階主管、且為 $220,000 交易，即使草稿完全有來源依據。 — Atlas 在 100% 乾淨的草稿上仍被轉交人工審查：受監管、高階主管、交易高於 $100,000。

簽署的回執，以及可重現的基準

每一封郵件都會產出可下載的 JSON 稽核回執：模型供應商與版本、潛在客戶與風險層級、事實表、每一項陳述的判定及其來源區間與日期、真實性分數、觸發的政策規則，以及人工核可者。在 25 個案例的標註黃金集上，確定性驗證器的判定準確度為 25/25：10 項困難或不良陳述中的 10 項全數抓到，15 項乾淨陳述中的 15 項全數保留。這種可重現性才使它可被認證，而 LLM 評判者做不到。我們將 25/25 歸因於這份標註基準，絕不當成開放世界保證。

可下載的 JSON 稽核回執，含逐項檢查追蹤、模型版本、判定、來源區間、日期，以及觸發的政策規則。 — 簽署的 JSON 稽核回執，含完整的逐項檢查追蹤。

25 案例標註黃金集，判定準確度 25 分之 25，確定性且可重現。 — 25 案例黃金集：判定準確度 25/25，每次執行結果相同。

標準 AI SDR 對照 Veracity Engine

示範用來對照的同一個切換，並排呈現。

維度	標準 AI SDR	Veracity Engine
寄出前已驗證的陳述	0	每一項事實陳述，以確定性方式
誰決定什麼能寄出	LLM 寄出它所撰寫的內容	純 Python 檢查，而非 LLM
過時來源攔截	無	時效有效性，365 天窗口
錯誤的同名實體	無	實體比對檢查
稽核軌跡	無	每封郵件一份簽署的 JSON 回執
高風險處理	照樣寄出	轉交人工審查

本示範不做的事

✓ 它並不宣稱幻覺率為零。LLM 仍會撰寫草稿；保證是未經證實的陳述會在寄出前被剔除。任何聲稱幻覺率為零的人，都不是在誠實面對。
✓ 它不使用實際連接器。EDGAR、LinkedIn、Greenhouse、新聞擷取、CRM 讀寫與郵件寄送皆為 stub 或模擬，事實表（Fact Sheet）為預先建好。
✓ 它並不把 Northwind 或 Atlas 呈現為真實公司。它們是合成的。僅 Werner Enterprises 及其 W1/W2 10-K 摘錄為真實公開紀錄。
✓ 它並不把 12 至 18% 的幻覺區間報導為本產品自身的量測結果。該數字是市場背景；本示範的重點是出處涵蓋率與自動處理率。
✓ 它不帶客戶、案例研究、推薦文或 ROI 數字。目前都不存在。這是證明機制的示範，而非正式部署。

買家真正會問的問題

這不就是另一個 AI SDR（像 11x）嗎？

不是。我們並不往市場再加一個 AI SDR。Veracity Engine 是位於草稿之後的驗證與治理層：確定性的純 Python 驗證器，將 AI 所寫的每一項陳述對照一份註明日期、實體比對過的來源加以檢查，剔除任何未經證實的內容，並在郵件獲准寄出前寫入簽署的稽核回執。AI SDR 以數量為優化目標；我們決定什麼能安全寄出。

如何在 AI 生成的銷售郵件寄出前驗證其中的陳述？

草稿中的每一項事實陳述都會經過三項確定性檢查：依據檢驗（該陳述是否由來源片段所蘊含，token 重疊至少 0.5）、實體比對（來源是否關於這家確切的潛在客戶，而非同名公司），以及時效有效性（若陳述使用近況用語，來源必須在 365 天以內）。只有通過的陳述會被標為 supported 並保留；其餘一律剔除。驗證器是程式碼，不是 LLM 評判 LLM，因此相同輸入永遠產生相同判定。

它如何抓到技術上為真、卻具誤導性的陳述？

那正是我們為此打造的失敗模式，示範稱之為脈絡誤用。在一個走完的潛在客戶中，「recently expanded into APAC」這句話有依據、也關於正確的公司，但唯一來源日期為 2019 年，對照 365 天近況窗口已有 2,652 天，因此被抓為 stale 並剔除。我們在一項由 FY2023 SEC 10-K 背書的真實 Werner Enterprises 陳述上展示同一模式：事實準確，但申報文件已超過兩年，因此「recently」的框架未通過時效有效性。

AI 外展能用在金融服務／FINRA 這類受監管產業嗎？

這正是驗證與治理層最關鍵之處，因為一項幻覺或張冠李戴的陳述帶有監管後果。在示範中，政策閘門會把任何受監管、寄給高階主管聯絡人、或綁定至少 $100,000 交易的郵件轉交人工審查，即使草稿完全有來源依據。此處的治理是風險的函數，而不只是正確性。

如何向合規稽核證明是哪一份來源為某項陳述背書？

每一封郵件都會產出可下載的 JSON 稽核回執，記錄模型供應商與版本、潛在客戶與風險層級、事實表、每一項陳述的判定及其來源區間與日期、真實性分數、觸發的確切政策規則，以及人工核可者。任何陳述都能在數秒內追溯回其來源。即使是完美的模型，仍無法向稽核人員證明是哪一份當前來源為哪一項陳述背書；回執可以。

更好／更新的 AI 模型不就能解決幻覺問題嗎？

不能，而這正是持久成立的要點。更好的基礎模型仍會撰寫草稿，任何聲稱幻覺率為零的人都不是在誠實面對，因此證明出處、保留稽核軌跡、並依風險把關的需求並不會消失。出處、稽核回執與政策閘門是持久的性質；更強的撰寫者並不會消除驗證並治理其所寫內容的要求。

這是正式產品還是示範？

這是證明機制的可運行示範，而非已部署的管線。擷取來源（EDGAR、LinkedIn、Greenhouse、新聞）、CRM 讀寫與郵件寄送皆為模擬，事實表為預先建好；潛在客戶除 Werner Enterprises 外皆為合成，其 10-K 摘錄為真實公開紀錄。確定性驗證器、政策閘門與稽核回執是真實的，並完全依所示運行。

技術研究

支撐此示範的研究——架構、驗證設計，以及企業藍圖。

完整解決方案

探索 AI 銷售情報 & 已驗證的外展解決方案 →

要把 AI 外展放到受監管買家面前？

驗證與治理層才是難處。我們打造它。

若您的團隊正在苦思如何在不冒幻覺陳述風險的前提下，把 AI 外展放到受監管買家面前，我們真心想聽聽您目前的想法。這個問題是全產業的，答案也將如此。

驗證評估

✓ 標出您的 AI 外展可能寄出未經證實陳述的位置
✓ 為您的資料定義依據、實體與時效規則
✓ 設計風險層級與人工審查閘門
✓ 訂出您的合規團隊所需的稽核回執

打造此層

✓ 針對您真實來源的確定性驗證器
✓ 依您受監管產業校準的政策閘門
✓ 每次寄出皆可下載的簽署稽核回執
✓ 可替換模型的撰寫（Anthropic、OpenAI、Gemini、Ollama）

透過 WhatsApp 聯繫以電子郵件聯絡我們的團隊