日本時(shí)尚租賃公司airCloset的CTO Ryan Tsuji最近曬了一組數(shù)字：15個(gè)數(shù)據(jù)庫(kù)schema、991張表、11個(gè)SQL數(shù)據(jù)庫(kù)、6個(gè)MongoDB實(shí)例。這不是在炫耀技術(shù)債厚度，而是在展示他們?cè)趺醋孉I把這些老古董盤(pán)活了。

他們的新工具叫DB Graph MCP。核心能力一句話：?jiǎn)T工用自然語(yǔ)言問(wèn)問(wèn)題，AI自動(dòng)去這991張表里找答案。不需要知道表名，不需要懂SQL，甚至不需要知道數(shù)據(jù)存在哪個(gè)庫(kù)。

聽(tīng)起來(lái)像給數(shù)據(jù)庫(kù)裝了搜索引擎。但Tsuji想解決的痛點(diǎn)更具體——那些只存在于老員工腦子里的「表與表之間的隱秘聯(lián)系」。

一個(gè)真實(shí)的跨庫(kù)追查：4張表、2個(gè)schema、0個(gè)外鍵

客服拋來(lái)一個(gè)典型問(wèn)題：「用戶App顯示退貨已完成，但倉(cāng)庫(kù)真的收到貨了嗎？」

這個(gè)問(wèn)題要拆成兩段。App端的退貨狀態(tài)在aircloset庫(kù)的delivery_order表，狀態(tài)碼「RETURNED」代表流程走完。但倉(cāng)庫(kù)端的實(shí)物確認(rèn)在另一個(gè)叫bridge的庫(kù)里，receive_record表的「COMPLETE」?fàn)顟B(tài)才是金標(biāo)準(zhǔn)。

麻煩的是，這兩個(gè)庫(kù)沒(méi)有外鍵關(guān)聯(lián)。中間靠一張映射表硬橋接：aircloset里存的是warehouse_order_code（字符串），bridge里對(duì)應(yīng)shipping_order_code（也是字符串），字符串匹配，手工維護(hù)。

Tsuji的原話：「公司里有幾個(gè)人知道這條查詢路徑？一只手?jǐn)?shù)得過(guò)來(lái)。他們要是休假，調(diào)查就卡死?！?/p>

這就是10年技術(shù)債的日常。不是「找不到表」，是「不知道表和表之間還能這么連」。

MCP協(xié)議：讓AI學(xué)會(huì)「翻箱倒柜」的通用語(yǔ)言

DB Graph MCP的底座是Model Context Protocol（模型上下文協(xié)議），Anthropic去年推出的開(kāi)放標(biāo)準(zhǔn)。簡(jiǎn)單說(shuō)，它給AI和外部系統(tǒng)之間定了套「對(duì)話語(yǔ)法」——AI能調(diào)用什么工具、傳什么參數(shù)、拿回什么格式，雙方提前約定好。

airCloset在這個(gè)框架上搭了兩層：DB Graph負(fù)責(zé)把991張表的結(jié)構(gòu)、關(guān)系、注釋吃進(jìn)去，建成一張可搜索的「元數(shù)據(jù)地圖」；MCP Server則負(fù)責(zé)把Claude Code的自然語(yǔ)言問(wèn)題，翻譯成對(duì)這張地圖的查詢指令。

員工在Claude Code里打字：「找跟退貨處理確認(rèn)相關(guān)的表」。后臺(tái)觸發(fā)search_tables工具，語(yǔ)義搜索跑一遍，返回候選表列表，帶相關(guān)性評(píng)分和字段說(shuō)明。

選中表之后，可以繼續(xù)問(wèn)：「這些表怎么關(guān)聯(lián)？」DB Graph會(huì)畫(huà)出關(guān)系路徑——哪張表的哪個(gè)字段，通過(guò)什么條件，連到哪張表。甚至能指出「這里用字符串匹配，沒(méi)有外鍵約束」這種坑。

Tsuji展示了實(shí)際返回格式：表名、字段類(lèi)型、業(yè)務(wù)注釋、關(guān)聯(lián)方式，結(jié)構(gòu)化輸出。不是黑盒，每一步都可審計(jì)。

安全設(shè)計(jì)：生產(chǎn)數(shù)據(jù)只能「看」，不能「碰」

讓AI碰生產(chǎn)數(shù)據(jù)庫(kù)，第一反應(yīng)是風(fēng)險(xiǎn)。airCloset的解法是分權(quán)限層級(jí)。

DB Graph MCP默認(rèn)只開(kāi)放「元數(shù)據(jù)查詢」——表結(jié)構(gòu)、字段注釋、表間關(guān)系。這些不涉及業(yè)務(wù)數(shù)據(jù)本身，員工本來(lái)就有權(quán)限看。

真要查生產(chǎn)數(shù)據(jù)？需要額外申請(qǐng)，走審批流。而且查詢是只讀的，帶審計(jì)日志。Tsuji強(qiáng)調(diào)：「我們可以讓它安全地查詢生產(chǎn)數(shù)據(jù)」，前提是權(quán)限和流程到位。

另一個(gè)細(xì)節(jié)是schema隔離。15個(gè)schema的元數(shù)據(jù)統(tǒng)一索引，但查詢時(shí)按用戶權(quán)限過(guò)濾?？头床坏截?cái)務(wù)schema的表結(jié)構(gòu)，工程師也進(jìn)不了HR的數(shù)據(jù)域。

這種設(shè)計(jì)把「AI能做什么」和「人被允許做什么」解耦了。AI的能力邊界由MCP工具定義，人的操作邊界由現(xiàn)有權(quán)限系統(tǒng)接管。

圖數(shù)據(jù)庫(kù)打底：991張表的「關(guān)系圖譜」怎么建

支撐自然語(yǔ)言查詢的，是一張預(yù)計(jì)算的圖。節(jié)點(diǎn)是表、字段、schema；邊是外鍵關(guān)系、命名相似性、人工標(biāo)注的業(yè)務(wù)關(guān)聯(lián)。

外鍵關(guān)系直接從數(shù)據(jù)庫(kù)元數(shù)據(jù)提取，最可靠。但airCloset的痛點(diǎn)恰恰是「沒(méi)有外鍵的地方」，所以補(bǔ)充了兩條線索：

一是命名模式。warehouse_order_code和shipping_order_code這種，字段名語(yǔ)義相關(guān)，可能被歸到同一業(yè)務(wù)域。二是人工注釋。老員工在DB Graph后臺(tái)標(biāo)記的「這張表和那張表其實(shí)是一對(duì)一」，變成圖上的加權(quán)邊。

Tsuji沒(méi)透露具體用的什么圖數(shù)據(jù)庫(kù)，但提到「向量搜索+圖遍歷」的混合查詢。自然語(yǔ)言先向量化，找語(yǔ)義相近的表名/字段注釋；再沿著圖邊擴(kuò)散，找出關(guān)聯(lián)表。最后綜合排序返回。

這套機(jī)制解釋了為什么「return processing confirmation」能命中receive_record表——不是關(guān)鍵詞匹配，是語(yǔ)義相近的字段注釋+圖上路徑的綜合得分。

從「人腦維基」到「可查詢的基礎(chǔ)設(shè)施」

Tsuji的總結(jié)很直白：「以前這些連接只存在于特定人的腦子里，現(xiàn)在變成了可搜索、可驗(yàn)證的系統(tǒng)?！?/p>

這不是替換DBA，是降低「知道該問(wèn)誰(shuí)」的門(mén)檻。新員工不用先花三個(gè)月摸清哪個(gè)老員工管哪塊schema，直接問(wèn)AI就行。老員工也能從「人肉查詢接口」里解放出來(lái)。

airCloset把這套系統(tǒng)開(kāi)源了。GitHub倉(cāng)庫(kù)里能看到MCP Server的實(shí)現(xiàn)、圖構(gòu)建的流水線、權(quán)限模型的配置模板。Tsuji說(shuō)歡迎提issue，但提醒「991張表的規(guī)?？赡懿皇敲考叶加小埂?/p>

一個(gè)有趣的后續(xù)：發(fā)布后一周內(nèi)，有讀者反饋說(shuō)用類(lèi)似思路接上了自家公司的2000張表，但查詢延遲從2秒飆到15秒。Tsuji在評(píng)論區(qū)回復(fù)：「我們?cè)诳紤]分層緩存，熱schema常駐內(nèi)存，冷數(shù)據(jù)按需加載?！?/p>

10年老數(shù)據(jù)庫(kù)的自然語(yǔ)言接口，性能優(yōu)化才剛開(kāi)始。