10年積累，15個(gè)數(shù)據(jù)庫(kù)模式，991張表，11個(gè)SQL數(shù)據(jù)庫(kù)加6個(gè)MongoDB實(shí)例。airCloset的CTO Ryan Tsuji最近公開了他們內(nèi)部的一個(gè)工具：DB Graph MCP。這東西讓員工用自然語(yǔ)言就能跨庫(kù)搜索，不需要知道任何表名。

「Find tables related to returns」，輸入這個(gè)，系統(tǒng)就能在15個(gè)模式里找出所有相關(guān)表。不是簡(jiǎn)單的關(guān)鍵詞匹配，是語(yǔ)義搜索。更關(guān)鍵的是，它能安全地查詢生產(chǎn)環(huán)境數(shù)據(jù)。

這聽起來(lái)像是個(gè)內(nèi)部效率工具。但Tsuji講了一個(gè)真實(shí)場(chǎng)景，讓我意識(shí)到問題的嚴(yán)重性。

一個(gè)退貨查詢，要4張表+2個(gè)數(shù)據(jù)庫(kù)+0個(gè)外鍵

客服收到投訴：用戶App顯示退貨已完成，但倉(cāng)庫(kù)真的收到貨了嗎？

要查這個(gè)，你需要知道：

App端的退貨狀態(tài)在aircloset模式的delivery order表里，狀態(tài)為RETURNED時(shí)前端顯示完成。但倉(cāng)庫(kù)端的確認(rèn)在bridge模式的receive record表里，狀態(tài)為COMPLETE才代表實(shí)物已入庫(kù)。

這兩個(gè)表在兩個(gè)不同的數(shù)據(jù)庫(kù)里，沒有外鍵關(guān)聯(lián)。中間靠一個(gè)varchar字段硬連：aircloset的warehouse mapping表里存著warehouse_order_code，對(duì)應(yīng)bridge的shipping order表里的shipping_order_code。字符串匹配，純靠人腦記憶。

Tsuji的原話：「Four tables, two schemas, a foreign-key-less varchar join. How many people in the company know this path? You could count them on one hand.」

公司知道這條路徑的人，一只手?jǐn)?shù)得過(guò)來(lái)。他們休假，調(diào)查就卡死。

這不是「不知道表名」的問題。是表與表之間的連接關(guān)系只存在于特定人的腦子里。991張表×15個(gè)模式，每天都是這樣。

DB Graph MCP怎么解決：把隱式知識(shí)變成顯式圖

Tsuji團(tuán)隊(duì)的做法是構(gòu)建一個(gè)數(shù)據(jù)庫(kù)元數(shù)據(jù)圖譜（Database Metadata Graph），然后用MCP（Model Context Protocol，模型上下文協(xié)議）把它接到Claude Code里。

核心組件分三層：

第一層是圖譜本身。節(jié)點(diǎn)是表、列、枚舉值。邊是外鍵關(guān)系、命名相似性、共現(xiàn)模式。他們用了pg_dump、INFORMATION_SCHEMA、手工文檔三種來(lái)源，把10年的 schema 歷史爬了一遍。

第二層是語(yǔ)義層。表和列的描述向量化，支持自然語(yǔ)言搜索。你搜「return processing confirmation」，它找的是語(yǔ)義相近的表，不是字符串匹配。

第三層是MCP服務(wù)器。把圖譜暴露給Claude Code，提供search_tables、get_table_details、execute_query三個(gè)工具。AI根據(jù)對(duì)話上下文決定調(diào)用哪個(gè)。

實(shí)際操作流程是這樣的：用戶用自然語(yǔ)言提問 → Claude選擇工具 → MCP服務(wù)器查詢圖譜 → 返回結(jié)構(gòu)化結(jié)果 → AI解釋給用戶。

Tsuji展示了真實(shí)的工具響應(yīng)格式。search_tables返回表名、schema、相似度分?jǐn)?shù)、匹配理由。get_table_details返回列定義、樣本數(shù)據(jù)、關(guān)聯(lián)表。execute_query返回查詢結(jié)果，但受權(quán)限系統(tǒng)管控。

權(quán)限設(shè)計(jì)：不是能不能查，是誰(shuí)能在什么場(chǎng)景下查什么

生產(chǎn)數(shù)據(jù)查詢是紅線。Tsuji的方案是分層的：

只讀訪問是基線。所有查詢通過(guò)只讀副本執(zhí)行，物理上阻斷寫入可能。

動(dòng)態(tài)脫敏是默認(rèn)。敏感列（郵箱、電話、地址）自動(dòng)哈?；蚪?cái)唷颖緮?shù)據(jù)隨機(jī)采樣，避免逐行泄露。

審批流是兜底。非敏感查詢自動(dòng)通過(guò)。涉及用戶明細(xì)的查詢，需要直屬上級(jí)在Slack里點(diǎn)確認(rèn)。審批記錄進(jìn)審計(jì)日志。

查詢水印是追溯。每個(gè)查詢嵌入執(zhí)行者ID和時(shí)間戳，泄露可溯源。

Tsuji特別強(qiáng)調(diào)：「We don't just block. We make safe access possible.」不是一刀切禁止，是讓安全訪問變得可能。

這個(gè)設(shè)計(jì)思路很產(chǎn)品經(jīng)理。風(fēng)險(xiǎn)不是來(lái)自查詢本身，來(lái)自無(wú)約束的查詢。給查詢加上上下文約束（誰(shuí)、何時(shí)、為什么），風(fēng)險(xiǎn)就變得可管理。

技術(shù)細(xì)節(jié)：圖怎么構(gòu)建，怎么更新

圖譜構(gòu)建分三步。第一步，schema提取。PostgreSQL用pg_dump，MongoDB用手工維護(hù)的映射文檔。第二步，關(guān)系推斷。顯式外鍵直接連，隱式關(guān)系用命名相似度（Levenshtein距離）和共現(xiàn)頻率補(bǔ)全。第三步，人工校驗(yàn)。核心業(yè)務(wù)流程的表關(guān)系，必須有DBA簽字確認(rèn)。

更新機(jī)制是事件驅(qū)動(dòng)。DDL變更觸發(fā)自動(dòng)重爬，每天凌晨全量比對(duì)一次。Tsuji說(shuō)他們的圖譜延遲通常在5分鐘以內(nèi)。

一個(gè)有趣的細(xì)節(jié)：他們故意保留了「歷史僵尸表」。10年積累里有大量廢棄表，直接刪除會(huì)丟信息，標(biāo)記為deprecated留在圖里，搜索時(shí)降權(quán)但不消失。Tsuji的解釋是：「Someone always asks about that old table eventually.」總會(huì)有人問到那張老表的。

性能方面，991張表的圖譜，節(jié)點(diǎn)數(shù)約12萬(wàn)，邊數(shù)約8萬(wàn)。全內(nèi)存加載，查詢延遲P99在200ms以內(nèi)。向量化搜索用pgvector，索引占用約400MB。

效果：從「等人回答」到「自己搞定」

Tsuji給了一組內(nèi)部數(shù)據(jù)。工具上線3個(gè)月，客服團(tuán)隊(duì)的數(shù)據(jù)查詢工單下降67%。不是因?yàn)樗麄冏兩倭?，是客服自己用Claude Code查掉了。

更隱蔽的變化是溝通模式。以前查一個(gè)跨庫(kù)問題，要在Slack里@三個(gè)人，等時(shí)區(qū)對(duì)齊?，F(xiàn)在一個(gè)人對(duì)著AI問，5分鐘出結(jié)果。Tsuji說(shuō)：「The knowledge graph didn't just capture schema. It captured the implicit wiring between teams.」

這個(gè)表述很關(guān)鍵。DB Graph解決的不是技術(shù)問題，是組織問題。10年積累的知識(shí)孤島，用圖譜+AI的方式重新連接。

但也有邊界。Tsuji坦誠(chéng)說(shuō)了不工作的場(chǎng)景：復(fù)雜聚合查詢、實(shí)時(shí)性要求高的監(jiān)控、需要業(yè)務(wù)判斷的決策。這些還是得人來(lái)做。

工具的定位是「降低門檻」，不是「取代專家」。知道那條varchar連接路徑的人仍然有價(jià)值，但他們的知識(shí)現(xiàn)在可以被復(fù)制和加速了。

Tsuji最后放了一個(gè)用戶反饋截圖。某個(gè)工程師的評(píng)價(jià)：「I finally understand why our returns data is always weird.」