你有沒有遇到過這種情況？問"我們有多少客戶"，得到三個不同的數(shù)字。

銷售報一個數(shù)，財務(wù)報另一個，創(chuàng)始人打開儀表盤，跟前兩個都對不上。沒人撒謊，他們只是看了不同的系統(tǒng)，用了稍微不同的定義。而公司用這些數(shù)字做決策，已經(jīng)好幾個月了。

上周我在一個BI論壇看到個帖子。一位分析師把兩個團(tuán)隊的數(shù)據(jù)儀表盤并排對比，都有"收入"這一列，數(shù)字卻不一致。他追查下去："兩個分析師寫了兩個不同的收入計算公式，一個是毛收入，一個是凈收入。都沒錯，只是從沒統(tǒng)一過定義。"

這是老問題的新版本。三周的另一個帖子，426個贊，樓主說CEO干掉了BI工具，讓所有人"直接問Claude"要數(shù)字。結(jié)果可想而知："銷售VP拉的數(shù)據(jù)跟財務(wù)對不上。Claude在編造留存率數(shù)字，因為底層數(shù)據(jù)表從2022年就沒清理過。"

最高贊評論216個贊，一句話點(diǎn)破本質(zhì)："AI只在底層數(shù)據(jù)干凈、指標(biāo)定義清晰時才管用。跳過這一步，Claude只是更快地把胡說八道包裝成自信答案。"

問題形態(tài)不同，結(jié)構(gòu)一樣：定義漂移。AI加持讓漂移速度翻倍。

所以我搭了一個不會漂移的agent。

我在工作區(qū)數(shù)據(jù)庫里塞了大多數(shù)公司真實會有的混亂數(shù)據(jù)。兩個表：一個叫stripe_customers，存賬單數(shù)據(jù)；一個叫hubspot_companies，存CRM視角。同一批業(yè)務(wù)，同一批客戶，對"企業(yè)級"的定義卻不同。

然后我問了那個簡單的問題。

同一個問題，六個數(shù)字。agent把它們?nèi)谐鰜恚忉尀槭裁床灰恢隆?/p>

兩個總數(shù)都顯示9。但它們數(shù)的是不同的9。沒人說謊，兩個數(shù)字都站得住腳。agent用大白話解釋原因——"同步或命名/域名不匹配，而非計數(shù)錯誤"。

我沒寫對賬邏輯，沒寫SQL。只問了一個問題。

市面上"問AI要數(shù)字"的工具，沒人聊底層在發(fā)生什么。大多分兩種套路：

第一種把數(shù)據(jù)硬塞進(jìn)提示詞。客戶表有一萬行？你每次提問都要付費(fèi)讀完整張表。而LLM是預(yù)測引擎，不是計算器——讓它加一千個數(shù)字，它會愉快地編個總數(shù)給你。

第二種在數(shù)據(jù)庫外包個聊天框。AI從不真正查詢，它讓翻譯器猜一段SQL，返回一個數(shù)字。你看不到計算過程。數(shù)字錯了，你也查不出原因。

上面那個agent兩種都不沾。它有真正的SQL工具。它看了表結(jié)構(gòu)，自己寫