上交大與清華等突破：AI實現數據庫自動技能擴展準確率提升突破

這項由上海交通大學主導，聯合清華大學、新加坡國立大學以及螞蟻集團共同開展的研究，發表于2026年6月的ACM數據管理頂級期刊《Proceedings of the ACM on Management of Data》第4卷第3期（SIGMOD 2026），論文編號為Article 141，DOI為10.1145/3802018。

數據庫，是現代軟件世界的"糧倉"。銀行記錄你的每一筆轉賬，醫院存儲你的每一次就診，電商平臺追蹤你的每一個訂單，背后都有數據庫在默默運轉。而數據庫里有一種東西，叫"原生函數"——你可以把它理解成數據庫內置的"小工具箱"，里面裝滿了各種預先寫好的功能：算平方根、截斷時間戳、拼接字符串、處理JSON格式數據……程序員只需呼喚一聲，比如寫下`date_trunc('hour', timestamp '2001-02-16 20:38:40')`，數據庫就乖乖把時間精確到小時，返回`2001-02-16 20:00:00`。

這些小工具的數量，這些年一直在飛速增長。以PostgreSQL為例，從2018年的237個函數，到2026年的630個，翻了將近三倍；DuckDB從60個漲到666個；SQLite也從52個攀升到143個。驅動這場增長的，是不斷涌現的新業務需求——比如企業要把Oracle數據庫遷移到PostgreSQL，就得把那些Oracle獨有的功能一一在新系統里重新實現，這項工作占到整個遷移預算的30%到60%，平均每一千行代碼需要花費40到80個小時。

問題在于，給數據庫手寫這些"原生函數"，極其困難。PostgreSQL的原生函數相關代碼，光是兩跳以內的依賴就超過11萬9千行；DuckDB的GitHub代碼倉庫里，和函數相關的問題單多達3791條。每寫一個新函數，開發者需要同時在多個文件里注冊、實現、引用內部接口，稍有不慎就會釀成編譯錯誤或者邏輯漏洞。這項工作長期依賴資深工程師的經驗，難以自動化。

正是為了解決這個痛點，上述研究團隊提出了一套名為**DBCooker**的自動化系統——借助大語言模型（也就是近年來廣為人知的ChatGPT、Claude之類的AI），讓機器自動完成數據庫原生函數的代碼合成。實驗結果顯示，DBCooker在SQLite、PostgreSQL和DuckDB三個主流數據庫上，平均準確率比當前最強的對手（包括Anthropic的Claude Code、阿里巴巴的Qwen Code等）高出34.55%，并且成功為最新版SQLite（v3.50）添加了四大類此前完全不存在的新函數。

一、為什么讓AI寫數據庫函數這么難？

要理解DBCooker解決了什么問題，先得摸清這件事到底難在哪里。

以PostgreSQL里的`date_trunc()`為例。這個函數的功能聽起來簡單：把一個時間戳"截斷"到指定精度，比如截到小時、截到天。但在數據庫內部，這一個SQL關鍵字，背后對應的是四個不同的"底層函數單元"：處理帶時區時間戳的`timestamptz_trunc`、處理時間間隔的`interval_trunc`、處理帶時區信息的`timestamptz_trunc_zone`，以及一個內部輔助函數`timestamptz_trunc_internal`。開發者必須把這四個單元分別注冊在系統目錄文件`pg_proc.dat`里，然后在`src/backend/utils/adt/timestamp.c`這個源文件里逐一實現它們，還要正確引用數十個數據庫內部的宏和工具函數，比如用`PG_GETARG_TEXT_PP()`獲取輸入參數，用`PG_RETURN_TIMESTAMPTZ()`格式化輸出結果。

假如不借助這些現成的內部工具，從零實現`date_trunc()`需要6235行代碼，涉及225個函數；而借助這些工具，只需要315行。節省了94.95%的代碼量。這說明，正確識別和復用數據庫內部的"參考函數單元"，是整件事的核心難點之一。

研究團隊通過大量觀察，總結出了三個主要障礙。

第一個障礙，是"一對多的映射"。一個SQL層面的函數，在數據庫內核里往往對應多個分工不同的底層單元，而且這種映射關系深埋在代碼倉庫的隱式約定里，沒有明確文檔，全靠經驗。

第二個障礙，是"海量引用中的精準尋找"。數據庫代碼倉庫極其龐大，以SQLite為例，每個文件平均有2619個可引用的函數和宏，但一個原生函數真正需要用到的，平均只有13.73個。在這片汪洋大海里找到那十幾顆關鍵的"明珠"，對AI來說并不容易。

第三個障礙，是"千人千面的復雜度"。有些函數，比如`sqrt()`，本質上就是套一個標準數學庫，實現極簡；有些函數，比如`json_agg()`，需要從頭構建復雜的聚合邏輯，代碼量可能是前者的數十倍。用一套固定流程統一對待它們，必然顧此失彼。

現有的AI代碼生成工具，包括著名的Claude Code和Qwen Code，在面對這三個障礙時都暴露出明顯短板。研究團隊做過統計：Claude Code在合成數據庫函數時，有63.70%的操作時間花在了"搜索倉庫"和"讀取文件"上，真正用于"生成代碼"的時間只占4.95%。換句話說，它把大部分精力用來在浩如煙海的代碼文件里找方向，而不是實實在在地寫代碼。與此同時，這些通用AI工具產生的錯誤里，有81.76%屬于"聲明錯誤"——要么把函數注冊在了錯誤的地方，要么引用了根本不存在的內部接口。

這就是DBCooker要攻克的戰場。

二、DBCooker的"烹飪哲學"：先備料，再按方煮，最后嚴格驗收

研究團隊把這套系統命名為"DBCooker"，這個名字頗有意思——數據庫（DB）加烹飪者（Cooker）。確實，整套系統的邏輯，像極了一個專業廚師的工作方式：先弄清楚這道菜的配方和所需食材（函數特征化），再按照菜譜一步步下廚（函數合成操作），最后對成品進行嚴格的口味檢驗（代碼驗證），而且整個流程會根據菜肴的復雜程度靈活調整（自適應工具編排）。

整個系統由三大模塊構成，彼此緊密協作。

第一大模塊叫做"函數特征化"，負責在開始寫代碼之前，把一個SQL函數需要的所有關鍵信息摸清楚——就像廚師在下鍋前必須先備好料。這個模塊從兩條路徑匯集信息：一條是解析數據庫官方文檔，提取函數的文字描述和使用示例；另一條是查詢數據庫系統目錄（比如PostgreSQL的`pg_proc.dat`），獲取精確的函數簽名、參數類型、返回類型等代碼層面的聲明。把這兩路信息合并成統一的JSON格式，就得到了一份完整的"函數檔案"。

備好基礎資料之后，這個模塊還要做一件更精細的工作：在代碼倉庫里把這個SQL函數背后所有需要實現的底層單元一一識別出來。系統采用了一種"圖遍歷"的方法——把代碼倉庫里函數之間的調用關系想象成一張地鐵線路圖，從SQL關鍵字這個"起始站"出發，沿著調用關系一站一站往下走，把所有相關的底層函數單元都找出來，同時把那些全局通用、并非這個函數專屬的單元排除掉。

找到所有相關單元之后，系統還會對同一類別的函數（比如所有處理時間的函數）做"成對比較"：把兩個同類函數的代碼對齊，找出它們共同的固定部分和各自不同的變化部分，把固定部分提煉為可復用的"模板"，把變化部分標記為需要填寫的"空格"。這套"找相同、標差異"的邏輯，為后續的代碼生成奠定了基礎。

第二大模塊叫做"函數合成操作"，負責真正把代碼寫出來——也就是那位廚師實際下廚炒菜的過程。這個模塊包含三個遞進的環節。

第一個環節是"偽代碼計劃生成"。在真正寫代碼之前，系統先讓AI生成一份詳細的實現方案——不是真正的代碼，而是一份像施工圖紙一樣的"骨架"：標明每個底層單元放在哪個文件里，每個單元內部分幾個代碼塊，每個代碼塊大概要用哪些內部接口。這就好比廚師在下鍋之前，先在腦海里過一遍"第一步加鹽、第二步翻炒、第三步收汁"的流程。為了確保這份計劃的質量，系統會同時生成多份候選計劃，然后用一個評分公式篩選出最好的那份。評分考慮兩個維度：一是"可信度"，即計劃里列出的引用接口實際存在、文件路徑實際正確的比例；二是"簡潔性"，即計劃列出的函數單元數量不要過于冗余。兩個維度加權平均，得分低于門檻的計劃直接淘汰。

第二個環節是"填空式代碼合成"。有了計劃骨架之后，實際寫代碼的過程被設計成"填空題"而非"作文題"。系統從同類函數里提取那些帶有空格標記的模板，把固定部分直接復用，讓AI只專注于填寫那些真正需要創新的、因函數而異的邏輯。這樣一來，AI的注意力被精準引導到最關鍵的地方，而不是從頭寫起、容易在細節上出錯。為了進一步提高質量，系統會同時生成多個候選實現，然后用"少數服從多數"的投票策略，選出出現頻率最高的方案作為最終代碼。

此外，這個環節還設計了一個"自動降級"機制。假如填空模板的質量不夠好，或者多次生成的代碼都以失敗告終，系統會逐步降低對模板的依賴程度——就像一道復雜的菜譜執行失敗幾次之后，廚師會選擇放棄照著菜譜做、轉而憑自己的經驗自由發揮。降級的速度由一個衰減參數控制，失敗次數越多，越快切換到完全自由生成的模式。

第三個環節是"三階段代碼驗證"。代碼寫完之后，要經歷三關考核，才算真正合格。第一關是"語法檢查"，用ANTLR這類專業的語法解析工具，確認代碼本身沒有拼寫錯誤、括號缺漏之類的低級問題。第二關是"合規檢查"，直接調用數據庫的編譯工具（比如PostgreSQL的`make install`），驗證代碼能否順利編譯并集成到數據庫里。第三關是"語義驗證"，讓AI自動生成一批測試用例——覆蓋各種輸入類型、邊界情況和異常情況——然后實際運行這些測試，檢查函數的輸出結果是否符合預期。三關里任何一關不過，系統都會把錯誤信息反饋給AI，讓它修改代碼，直到全部通過為止。

第三大模塊叫做"自適應工具編排"，負責把前兩個模塊里的所有操作智能地串聯起來——這就像那位廚師的"工作節奏管理"，根據今天要做的菜有多復雜，靈活決定先做什么、后做什么。

系統把每一個可用的操作（生成計劃、寫代碼、檢查語法、編譯驗證……）都包裝成一個標準化的"工具"，然后由一個AI控制器實時決定下一步調用哪個工具。這個控制器不是盲目決策的，它會參考一個"歷史經驗庫"——記錄了過去合成類似函數時用過的操作序列，包括哪些函數只需要簡單幾步就搞定了，哪些函數需要反復迭代。每次遇到新函數，控制器會從歷史庫里找出同類別的參考案例，綜合參考"最省事的做法"、"最費勁的做法"和"中間水平的做法"，再結合當前的實時狀態，動態決定接下來的行動。這種設計避免了"一刀切"——簡單函數不會被迫走冗長的流程，復雜函數也不會因流程太短而留下隱患。

三、實驗室里的成績單：數據說話

為了檢驗DBCooker的實際效果，研究團隊在SQLite、PostgreSQL和DuckDB三個主流數據庫上進行了全面測試，分別測試了75、145和128個函數，涵蓋數學函數、日期函數、字符串函數、JSON函數等多個類別，并設置了不同復雜度的函數樣本。

與之對比的方法涵蓋了目前最強的競爭者：直接用GPT-5、Claude Opus 4.1、Claude Sonnet 4.5、Qwen3 Coder Plus等大語言模型生成代碼；在大語言模型基礎上增加代碼檢索增強（CodeRAG）的版本；以及Claude Code、Qwen Code、TRAE（SWE-bench排行榜第一名）等專業代碼智能體系統。

評估指標分兩層：一是"合規準確率"，即生成的代碼能成功編譯并集成到數據庫的比例；二是"結果準確率"，即生成的代碼不僅能編譯，還能在所有測試用例上輸出正確結果的比例。

DBCooker在兩項指標上都大幅領先。綜合三個數據庫，合規準確率達到78.90%，結果準確率達到65.19%，分別比其他方法的平均水平高出124.37%和149.68%。換句話說，DBCooker在正確率上大約是競爭對手平均水平的兩倍以上。

按函數難度分層來看，DBCooker的優勢在難度較高的函數上尤為明顯。對于"簡單"函數，各方法差距相對較小，DBCooker的合規準確率達到78.44%；但對于"困難"函數，其他方法的平均合規準確率只有約22%，而DBCooker仍然保持在68.97%，差距達到197.10%。這說明隨著函數復雜度的增加，那些通用AI工具的能力急劇退化，而DBCooker的專項設計使它在復雜場景下依然保持穩定。

按函數類別來看，DBCooker在四大類PostgreSQL函數（數學、日期、字符串、JSON）上的合規準確率從89.19%到96.67%不等，整體穩定且均勻，比其他方法的平均水平高出151.11%。相比之下，競爭對手在不同類別上的表現參差不齊，尤其在數學函數這類看起來"簡單"實則充滿底層細節的函數上，大多數LLM方法合規準確率僅有6.67%到16.67%。

研究團隊還做了一個有趣的補充實驗：把正確的文件路徑、函數聲明和引用接口全部提前告訴那些競爭對手（相當于把所有"食材"都備好放在桌上），看看它們在徹底消除"文件搜索"障礙之后能達到什么水平。結果是，即便如此，這些競爭對手的準確率仍然比DBCooker低22.56%。這說明，數據庫原生函數合成的難點，不僅僅在于"找到正確的文件"，更在于生成符合數據庫內核規范的代碼本身——而這正是DBCooker通過三階段驗證和偽代碼計劃所著力解決的。

錯誤分布的分析同樣印證了這一點。通用LLM方法產生的錯誤以"聲明錯誤"為主，占到所有錯誤的約82%；Claude Code這類智能體工具雖然搜索能力更強，能主動驗證聲明位置，但生成的代碼仍然頻繁出現引用不存在接口的問題；DBCooker則通過函數特征化和三階段驗證，把各類錯誤壓到了最低水平。

四、消融實驗：每個零件都不能少

為了驗證系統各模塊的貢獻，研究團隊做了"拆零件"實驗——每次去掉一個模塊，看看準確率如何變化。

去掉"函數特征化"模塊（即不再預先提取函數的聲明信息和參考函數單元）時，三個數據庫上的合規準確率分別從81.33%、78.62%、83.67%下降到68.0%、31.25%、44.90%。尤其PostgreSQL的降幅最大，說明對于結構復雜的數據庫，預先理解函數組成至關重要。

去掉"三階段驗證"模塊時，PostgreSQL的合規準確率從78.62%驟降至6.9%。這個極端的下降幅度，反映了PostgreSQL的內部依賴關系極其復雜，沒有逐級驗證反饋，AI生成的代碼幾乎無法自行收斂到正確狀態。

單獨去掉"偽代碼計劃生成"（保留三階段驗證）時，準確率從78.62%下降至37.04%；單獨去掉"三階段驗證"（保留計劃生成）時，如上所述降至6.9%；兩者都去掉時則跌至9.66%。這表明計劃和驗證是相輔相成的——計劃幫助AI構建全面的實現藍圖，驗證幫助AI糾正執行過程中的錯誤，兩者缺一不可。

去掉"自適應工具編排"（改為固定流程的多LLM協作）時，三個數據庫上的結果準確率從69.33%、58.62%、67.35%分別下降到49.33%、21.19%、30.61%。這說明對于不同復雜度的函數，固定流程難以自適應地分配精力，而動態編排能有效提升資源利用效率。

五、讓SQLite"學會"它從未會過的新技能

除了在已有函數上的測試，研究團隊還做了一個更有野心的實驗：把PostgreSQL和DuckDB里有、但SQLite里沒有的函數，用DBCooker合成到SQLite里。

這項工作的難度更高，因為不同數據庫的內部架構差異極大，代碼不能直接移植，必須從頭適配SQLite的內部規范。研究團隊共嘗試了17個新函數，涵蓋聚合函數（如`covar_pop`、`bool_and`、`bool_or`）、日期函數（如`century`、`monthname`、`yearweek`、`last_day`）、數值函數（如`lcm`、`even`、`gamma`、`lgamma`、`nextafter`）和字符串函數（如`left`、`regexp_split_to_array`、`repeat`、`to_hex`、`translate`）。

DBCooker成功合成了全部17個新函數，而Claude Code合成了其中12個，TRAE合成了12個，Qwen Code只合成了7個。有幾個函數，三個競爭對手都無法合成，只有DBCooker成功，包括`century`、`monthname`、`even`、`gamma`、`lgamma`、`nextafter`和`translate`。

以`covar_pop`（計算協方差的聚合函數）為例，DBCooker正確識別出它需要三個底層單元：`covarPopStep`（逐行累加中間結果）、`covarPopFinalize`（計算最終協方差值）和`covarPopInverse`（用于窗口函數的逆運算），并把這三個單元用SQLite專屬的宏`WAGGREGATE`正確注冊在`src/func.c`文件里，使得用戶可以直接執行`SELECT covar_pop(...)`。Qwen Code則雖然正確注冊了聲明，但沒有實現`covarPopInverse`，導致編譯時報錯"WAGGREGATE宏中xInverse未聲明"。

以`regexp_split_to_array`（用正則表達式分割字符串為數組）為例，DBCooker正確使用了SQLite內部的`sqlite3_value_text`和`sqlite3_str_new`等引用接口；而其他三個方法則嘗試引用外部文件`sqlite3re.c`里的`sqlite3re_compile`和`sqlite3re_match`，這兩個接口在SQLite標準發行版里根本不存在，直接觸發合規錯誤。

六、和其他相關工作的區別在哪里

這項研究和幾個相鄰領域的工作之間，邊界是清晰的，值得簡單梳理一下。

通用代碼生成領域，涵蓋Codex、GitHub Copilot這類"提示詞驅動"的方法，Claude Code、SWE-Dev這類"智能體驅動"的方法，以及Code Llama、WizardCoder這類"訓練驅動"的方法。它們都是面向通用代碼倉庫設計的，缺少對數據庫內核架構的針對性理解，在數據庫原生函數這個專項任務上效果有限——這一點已經被實驗結果充分驗證。

用戶自定義函數（UDF）優化領域，代表性工作包括微軟的Froid（把命令式UDF轉換為關系代數表達式以提升執行效率）和Tuplex（把Python UDF編譯為原生機器碼）。這些工作聚焦的是"如何讓已有的函數跑得更快"，而不是"如何從零合成一個新函數并集成進數據庫內核"，和DBCooker的目標完全不同。

運行時代碼生成領域，代表性工作包括HyPer（把查詢計劃編譯為LLVM機器碼）和Weld（為跨庫數據分析流程生成優化的并行代碼）。這些工作生成的代碼是臨時性的、面向單次查詢執行的，而DBCooker合成的是持久性的、作為數據庫內核一部分的原生函數。

數據庫遷移領域，代表性工作包括CrackSQL（用LLM實現不同SQL方言之間的翻譯）和PARROT（跨系統SQL翻譯的評測基準）。這些工作處理的是SQL語句的表層語法轉換，而DBCooker處理的是函數在數據庫內核層面的重新實現，兩者粒度和難度都不在同一層次。

七、展望：這套系統未來面對哪些挑戰

研究團隊在論文中坦誠地指出了三個值得持續關注的深層挑戰。

第一個挑戰，是"代碼庫的碎片化與長上下文推理的矛盾"。PostgreSQL的源代碼超過一百萬行，而且聲明和實現往往分散在不同文件里（比如`pg_proc.dat`里是聲明，`src/func.c`里是實現）。即便未來的AI模型能夠處理超長上下文，把整個代碼庫一股腦塞進去，也會帶來高昂的推理成本，而且AI很可能在信息量過大的時候迷失方向、遺漏關鍵細節。DBCooker通過"函數特征化"提前精準定位相關內容，是解決這一矛盾的有效路徑。

第二個挑戰，是"數據庫的確定性正確性要求與AI的概率性生成本質之間的矛盾"。數據庫函數必須在所有情況下都輸出正確結果，沒有"大體上正確"這一說。而AI生成內容的本質是概率性的，無法從根本上保證精確正確。DBCooker通過外部強制執行的偽代碼計劃和三階段漸進驗證，把概率性輸出轉化為可驗證的正確實現，是應對這一矛盾的關鍵機制。

第三個挑戰，是"數據庫版本迭代與AI訓練數據滯后之間的矛盾"。數據庫函數的簽名、內部宏的用法、系統目錄的結構，會隨版本更新而變化。AI模型訓練時接觸的是歷史數據，難以跟上最新版本的變化，甚至可能把舊版本的寫法帶入新版本的代碼里，造成隱蔽的錯誤。DBCooker通過動態檢索當前版本的實現慣例，并用自適應工具編排加以強制執行，使系統能夠直接適應版本變化而無需重新訓練模型。

說到底，DBCooker做的事情，本質上是在為一項長期靠人工經驗維系的高難度工作，設計了一套有章法、有記憶、能自我糾錯的自動化流程。它并不是簡單地把"讓AI寫代碼"這件事重復一遍，而是針對數據庫原生函數這個具體場景，把函數的結構分析、模板復用、分層驗證和歷史經驗融合為一個有機整體。

對于數據庫開發者和企業IT團隊而言，這意味著那些長達數月的數據庫遷移項目，其中最耗時的函數重實現部分，未來或許能夠得到切實的自動化支持，而不再只是"AI能幫我搜索一些參考代碼"這種程度的輔助。對于更廣泛的軟件工程領域而言，這項工作也提示了一個值得關注的方向：面對高度結構化、規范嚴格、內部依賴復雜的特定代碼合成任務，專項化的設計比通用方法有著相當明顯的優勢空間。

有興趣深入了解技術細節的讀者，可以通過DOI 10.1145/3802018查閱完整論文，也可以訪問GitHub上的開源代碼庫 weAIDB/DBCooker，復現實驗或在自己的數據庫項目中嘗試應用。

Q&A

Q1：DBCooker和Claude Code這類AI編程工具相比，核心區別是什么？

A：Claude Code是通用代碼智能體，遇到數據庫原生函數合成任務時，會花大量時間在代碼倉庫里盲目搜索文件，真正用于寫代碼的時間只有不到5%，而且不了解數據庫內部的注冊規范，經常把函數聲明放錯地方或者引用根本不存在的內部接口。DBCooker則是專門針對數據庫原生函數設計的，它預先分析清楚每個函數對應哪些底層單元、這些單元應該放在哪里、應該引用哪些內部接口，然后按照數據庫內核的規范逐步生成和驗證代碼，把錯誤率壓到了Claude Code的三分之一以下。

Q2：DBCooker的三階段代碼驗證具體是怎么工作的？

A：三階段驗證是從淺到深的三關考核。第一關是語法檢查，用專業的語法解析工具（ANTLR）掃描生成的代碼，排除括號不配對、變量未聲明之類的低級語法錯誤。第二關是合規檢查，直接調用數據庫自身的編譯工具（比如PostgreSQL的make install命令），看代碼能否真正編譯并集成進數據庫，這一關能發現函數注冊位置不對、引用接口不存在等深層問題。第三關是語義驗證，讓AI自動生成覆蓋各種輸入類型和邊界情況的SQL測試用例，實際運行后檢查輸出結果是否符合預期，這一關專門針對"代碼能跑但結果不對"的情況。三關都通過才算合格，任何一關失敗都會把錯誤反饋給AI讓它修改。

Q3：DBCooker能用來給任意數據庫添加新函數嗎，有什么限制？

A：目前DBCooker已經在SQLite、PostgreSQL和DuckDB三個主流數據庫上經過了系統驗證，能夠處理數學、日期、字符串、JSON等多個類別的函數，包括從其他數據庫移植全新函數。主要的限制在于，DBCooker的函數特征化模塊需要訪問目標數據庫的代碼倉庫和系統目錄，對于閉源數據庫或內部結構沒有文檔化的系統，適用性會受限。此外，對于極端復雜的函數（比如涉及幾百個底層依賴的聚合函數），當前版本的成功率仍然低于理想水平，這也是研究團隊正在持續改進的方向。