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

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

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

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

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

一、為什么讓AI寫數(shù)據(jù)庫函數(shù)這么難？

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

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

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

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

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

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

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

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

這就是DBCooker要攻克的戰(zhàn)場。

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

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

整個系統(tǒng)由三大模塊構(gòu)成，彼此緊密協(xié)作。

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

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

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

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

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

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

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

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

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

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

三、實驗室里的成績單：數(shù)據(jù)說話

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

六、和其他相關(guān)工作的區(qū)別在哪里

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

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

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

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

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

七、展望：這套系統(tǒng)未來面對哪些挑戰(zhàn)

研究團隊在論文中坦誠地指出了三個值得持續(xù)關(guān)注的深層挑戰(zhàn)。

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

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

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

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

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

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

Q&A

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

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

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

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

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

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