DBCooker深度解析：AI如何让数据库"自学会"新增原生函数
摘要
2026年6月，上海交通大学联合清华大学、新加坡国立大学及蚂蚁集团发布了一项重磅研究成果——DBCooker自动化系统。该系统借助大语言模型，让机器自动完成数据库原生函数的代码合成，在SQLite、PostgreSQL和DuckDB三个主流数据库上的平均准确率比当前最强的对手（包括Anthropic的Claude Code、阿里巴巴的Qwen Code等）高出34.55%。本文将深入解析DBCooker的核心设计理念、技术架构与工程实现，为数据库开发者、架构师以及对AI+数据库融合感兴趣的读者提供一份详尽的技术指南。
一、引言：当数据库遇见AI代码生成
1.1 数据库原生函数的"军备竞赛"
数据库是现代软件世界的"粮仓"。银行记录每一笔转账，医院存储每一次就诊，电商平台追踪每一个订单——这些背后都有数据库在默默运转。而数据库里有一种至关重要的存在，叫做"原生函数"（Native Functions）。
你可以把原生函数理解为数据库内置的"小工具箱"。以PostgreSQL为例，这个工具箱里的工具一直在飞速增长：从2018年的237个函数，到2026年的630个，翻了将近三倍；DuckDB从60个涨到666个；SQLite也从52个攀升到143个。这些数字背后，是不断涌现的新业务需求和技术演进。
以一个简单的SQL函数date_trunc('hour', timestamp '2001-02-16 20:38:40')为例，它能将时间戳精确到小时，返回2001-02-16 20:00:00。但在你看不到的数据库内部，这个SQL关键字背后对应着四个不同的"底层函数单元"：处理带时区时间戳的timestamptz_trunc、处理时间间隔的interval_trunc、处理带时区信息的timestamptz_trunc_zone，以及内部辅助函数timestamptz_trunc_internal。
1.2 手动编写数据库函数的"至暗时刻"
为什么给数据库手写原生函数如此困难？
首先，是"一对多的映射"问题。 一个SQL层面的函数，在数据库内核里往往对应多个分工不同的底层单元，而且这种映射关系深埋在代码仓库的隐式约定里，没有明确文档，全靠经验。
其次，是"海量引用中的精准寻找"问题。 数据库代码仓库极其庞大，以SQLite为例，每个文件平均有2619个可引用的函数和宏，但一个原生函数真正需要用到的，平均只有13.73个。在这片汪洋大海里找到那十几颗关键的"明珠"，对AI来说并不容易。
第三，是"千人千面的复杂度"问题。 有些函数比如sqrt()，本质上就是套一个标准数学库，实现极简；而有些函数比如json_agg()，需要从头构建复杂的聚合逻辑，代码量可能是前者的数十倍。
以PostgreSQL为例，其原生函数相关代码，光是两跳以内的依赖就超过11万9千行；DuckDB的GitHub代码仓库里，和函数相关的问题单多达3791条。研究数据显示，数据库迁移项目（比如从Oracle迁移到PostgreSQL）中，这项工作占到整个迁移预算的30%到60%，平均每一千行代码需要花费40到80个小时。
1.3 现有AI工具的尴尬处境
现有的AI代码生成工具，包括著名的Claude Code和Qwen Code，在面对上述三个障碍时都暴露出明显短板：
研究团队做过统计：Claude Code在合成数据库函数时，有63.70%的操作时间花在了"搜索仓库"和"读取文件"上，真正用于"生成代码"的时间只占4.95%。换句话说，它把大部分精力用来在浩如烟海的代码文件里找方向，而不是实实在在地写代码。
与此同时，这些通用AI工具产生的错误里，有**81.76%**属于"声明错误"——要么把函数注册在了错误的地方，要么引用了根本不存在的内部接口。
这就是DBCooker要攻克的战场。
二、DBCooker核心架构："烹饪哲学"的工程实现
2.1 设计理念
研究团队把这套系统命名为"DBCooker"——数据库（DB）加烹饪者（Cooker）。这个名字形象地概括了整个系统的逻辑：像一位专业厨师一样工作。
想象一位专业厨师的工作流程：
- 先备料 - 弄清楚这道菜需要什么食材和配方（函数特征化）
- 按方煮 - 按照菜谱一步步下厨（函数合成操作）
- 严格验收 - 对成品进行口味检验（代码验证）
- 灵活调整 - 根据菜肴的复杂程度调整工作节奏（自适应工具编排）
整个系统由三大模块构成，彼此紧密协作。
2.2 模块一：函数特征化（Function Characterization）
这个模块负责在开始写代码之前，把一个SQL函数需要的所有关键信息摸清楚——就像厨师在下锅前必须先备好料。
2.2.1 两条信息汇集路径
函数特征化模块从两条路径汇集信息：
路径一：解析官方文档
提取函数的文字描述和使用示例，获取函数的功能语义。
路径二：查询系统目录
查询数据库系统目录（比如PostgreSQL的pg_proc.dat），获取精确的函数签名、参数类型、返回类型等代码层面的声明。
把这两路信息合并成统一的JSON格式，就得到了一份完整的"函数档案"。
2.2.2 图遍历：定位底层依赖单元
备好基础资料之后，这个模块还要做一件更精细的工作：在代码仓库里把这个SQL函数背后所有需要实现的底层单元一一识别出来。
系统采用了一种"图遍历"的方法——把代码仓库里函数之间的调用关系想象成一张地铁线路图，从SQL关键字这个"起始站"出发，沿着调用关系一站一站往下走，把所有相关的底层函数单元都找出来，同时把那些全局通用、并非这个函数专属的单元排除掉。
2.2.3 成对比较：提炼可复用模板
找到所有相关单元之后，系统还会对同一类别的函数（比如所有处理时间的函数）做"成对比较"：把两个同类函数的代码对齐，找出它们共同的固定部分和各自不同的变化部分。
- 固定部分 → 提炼为可复用的"模板"
- 变化部分 → 标记为需要填写的"空格"
这套"找相同、标差异"的逻辑，为后续的代码生成奠定了基础。
以date_trunc()为例：假如不借助数据库内部的参考函数单元，从零实现需要6235行代码，涉及225个函数；而借助这些工具，只需要315行，节省了**94.95%**的代码量。
2.3 模块二：函数合成操作（Function Synthesis Operations）
这个模块负责真正把代码写出来——也就是那位厨师实际下厨炒菜的过程。它包含三个递进的环节。
2.3.1 环节一：伪代码计划生成
在真正写代码之前，系统先让AI生成一份详细的实现方案——不是真正的代码，而是一份像施工图纸一样的"骨架"：
- 标明每个底层单元放在哪个文件里
- 每个单元内部分几个代码块
- 每个代码块大概要用哪些内部接口
这就好比厨师在下锅之前，先在脑海里过一遍"第一步加盐、第二步翻炒、第三步收汁"的流程。
为了确保这份计划的质量，系统会同时生成多份候选计划，然后用一个评分公式筛选出最好的那份。评分考虑两个维度：
- 可信度：计划里列出的引用接口实际存在、文件路径实际正确的比例
- 简洁性：计划列出的函数单元数量不要过于冗余
两个维度加权平均，得分低于门槛的计划直接淘汰。
2.3.2 环节二：填空式代码合成
有了计划骨架之后，实际写代码的过程被设计成**"填空题"而非"作文题"**。
系统从同类函数里提取那些带有空格标记的模板，把固定部分直接复用，让AI只专注于填写那些真正需要创新的、因函数而异的逻辑。
这样一来，AI的注意力被精准引导到最关键的地方，而不是从头写起、容易在细节上出错。
为了进一步提高质量，系统会同时生成多个候选实现，然后用**"少数服从多数"**的投票策略，选出出现频率最高的方案作为最终代码。
此外，这个环节还设计了一个**"自动降级"机制**：
- 假如填空模板的质量不够好，或者多次生成的代码都以失败告终
- 系统会逐步降低对模板的依赖程度
- 就像一道复杂的菜谱执行失败几次之后，厨师会选择放弃照着菜谱做、转而凭自己的经验自由发挥
- 降级的速度由一个衰减参数控制，失败次数越多，越快切换到完全自由生成的模式
2.3.3 环节三：三阶段代码验证
代码写完之后，要经历三关考核，才算真正合格：
第一关：语法检查
用ANTLR这类专业的语法解析工具，确认代码本身没有拼写错误、括号缺漏之类的低级问题。
第二关：合规检查
直接调用数据库的编译工具（比如PostgreSQL的make install），验证代码能否顺利编译并集成到数据库里。
第三关：语义验证
让AI自动生成一批测试用例——覆盖各种输入类型、边界情况和异常情况——然后实际运行这些测试，检查函数的输出结果是否符合预期。
三关里任何一关不过，系统都会把错误信息反馈给AI，让它修改代码，直到全部通过为止。
2.4 模块三：自适应工具编排（Adaptive Tool Orchestration）
这个模块负责把前两个模块里的所有操作智能地串联起来——这就像那位厨师的"工作节奏管理"，根据今天要做的菜有多复杂，灵活决定先做什么、后做什么。
系统把每一个可用的操作（生成计划、写代码、检查语法、编译验证……）都包装成一个标准化的"工具"，然后由一个AI控制器实时决定下一步调用哪个工具。
这个控制器不是盲目决策的，它会参考一个**"历史经验库"**——记录了过去合成类似函数时用过的操作序列，包括：
- 哪些函数只需要简单几步就搞定了
- 哪些函数需要反复迭代
每次遇到新函数，控制器会从历史库里找出同类别的参考案例，综合参考"最省事的做法"、"最费劲的做法"和"中间水平的做法"，再结合当前的实时状态，动态决定接下来的行动。
这种设计避免了**"一刀切"**：
- 简单函数不会被迫走冗长的流程
- 复杂函数也不会因流程太短而留下隐患
三、实验结果：数据说话
3.1 测试设置
研究团队在SQLite、PostgreSQL和DuckDB三个主流数据库上进行了全面测试：
- SQLite：75个函数
- PostgreSQL：145个函数
- DuckDB：128个函数
涵盖数学函数、日期函数、字符串函数、JSON函数等多个类别，并设置了不同复杂度的函数样本。
3.2 对比方法
与之对比的方法涵盖了目前最强的竞争者：
- 直接用大语言模型生成代码：GPT-5、Claude Opus 4.1、Claude Sonnet 4.5、Qwen3 Coder Plus等
- 代码检索增强版本：在大语言模型基础上增加代码检索增强（CodeRAG）
- 专业代码智能体系统：Claude Code、Qwen Code、TRAE（SWE-bench排行榜第一名）
3.3 评估指标
评估指标分两层：
- 合规准确率：生成的代码能成功编译并集成到数据库的比例
- 结果准确率：生成的代码不仅能编译，还能在所有测试用例上输出正确结果的比例
3.4 核心结果
DBCooker在两项指标上都大幅领先：
| 指标 | DBCooker | 其他方法平均 | 提升幅度 |
|---|---|---|---|
| 合规准确率 | 78.90% | 35.17% | +124.37% |
| 结果准确率 | 65.19% | 26.11% | +149.68% |
换句话说，DBCooker在正确率上大约是竞争对手平均水平的两倍以上。
3.5 按难度分层
| 难度等级 | DBCooker | 其他方法平均 | 差距 |
|---|---|---|---|
| 简单函数 | 78.44% | ~45% | +74% |
| 困难函数 | 68.97% | ~22% | +197.10% |
DBCooker的优势在难度较高的函数上尤为明显。随着函数复杂度的增加，那些通用AI工具的能力急剧退化，而DBCooker的专项设计使它在复杂场景下依然保持稳定。
3.6 按函数类别分析
DBCooker在四大类PostgreSQL函数上的合规准确率：
| 函数类别 | DBCooker | 其他方法平均 | 提升 |
|---|---|---|---|
| 数学函数 | 89.19% | ~15% | +494% |
| 日期函数 | 92.31% | ~35% | +164% |
| 字符串函数 | 96.67% | ~40% | +142% |
| JSON函数 | 94.12% | ~30% | +214% |
尤其值得注意的是，在数学函数这类看起来"简单"实则充满底层细节的函数上，大多数LLM方法合规准确率仅有6.67%到16.67%。
3.7 消融实验：每个零件都不能少
研究团队做了"拆零件"实验，验证各模块的贡献：
去掉"函数特征化"模块时：
- 三个数据库上的合规准确率分别从81.33%、78.62%、83.67%下降到68.0%、31.25%、44.90%
- PostgreSQL降幅最大，说明对于结构复杂的数据库，预先理解函数组成至关重要
去掉"三阶段验证"模块时：
- PostgreSQL的合规准确率从78.62%骤降至6.9%
- 这个极端的下降幅度，反映了PostgreSQL的内部依赖关系极其复杂
单独去掉"伪代码计划生成"时：
- 准确率从78.62%下降至37.04%
去掉"自适应工具编排"时（改为固定流程）：
- 三个数据库上的结果准确率从69.33%、58.62%、67.35%分别下降到49.33%、21.19%、30.61%
这表明：
- 计划和验证是相辅相成的——两者缺一不可
- 动态编排能有效提升资源利用效率
四、实战案例：为SQLite添加"新技能"
4.1 实验设计
除了在已有函数上的测试，研究团队还做了一个更有野心的实验：把PostgreSQL和DuckDB里有、但SQLite里没有的函数，用DBCooker合成到SQLite里。
这项工作的难度更高，因为不同数据库的内部架构差异极大，代码不能直接移植，必须从头适配SQLite的内部规范。
4.2 测试函数
研究团队共尝试了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
4.3 对比结果
| 方法 | 成功数量 |
|---|---|
| DBCooker | 17/17 (100%) |
| Claude Code | 12/17 |
| TRAE | 12/17 |
| Qwen Code | 7/17 |
有7个函数，三个竞争对手都无法合成，只有DBCooker成功：
century、monthname、even、gamma、lgamma、nextafter、translate
4.4 案例一：协方差聚合函数covar_pop
以covar_pop（计算协方差的聚合函数）为例：
DBCooker的正确实现：
- 正确识别出它需要三个底层单元：
covarPopStep（逐行累加中间结果）、covarPopFinalize（计算最终协方差值）、covarPopInverse（用于窗口函数的逆运算） - 把这三个单元用SQLite专属的宏
WAGGREGATE正确注册在src/func.c文件里 - 用户可以直接执行
SELECT covar_pop(...)
Qwen Code的错误：
- 虽然正确注册了声明，但没有实现
covarPopInverse - 导致编译时报错"WAGGREGATE宏中xInverse未声明"
4.5 案例二：正则分割函数regexp_split_to_array
以regexp_split_to_array（用正则表达式分割字符串为数组）为例：
DBCooker的正确实现：
- 正确使用了SQLite内部的
sqlite3_value_text和sqlite3_str_new等引用接口
其他方法的错误：
- 尝试引用外部文件
sqlite3re.c里的sqlite3re_compile和sqlite3re_match - 这两个接口在SQLite标准发行版里根本不存在，直接触发合规错误
五、技术边界与局限性
5.1 当前适用性
目前DBCooker已经在SQLite、PostgreSQL和DuckDB三个主流数据库上经过了系统验证，能够处理：
- 数学函数
- 日期函数
- 字符串函数
- JSON函数
等多个类别的函数，包括从其他数据库移植全新函数。
5.2 主要限制
限制一：代码库的碎片化与长上下文推理的矛盾
- PostgreSQL的源代码超过一百万行，而且声明和实现往往分散在不同文件里
- 即便未来的AI模型能够处理超长上下文，把整个代码库一股脑塞进去，也会带来高昂的推理成本
- DBCooker通过"函数特征化"提前精准定位相关内容，是解决这一矛盾的有效路径
限制二：数据库的确定性正确性要求与AI的概率性生成本质之间的矛盾
- 数据库函数必须在所有情况下都输出正确结果，没有"大体上正确"这一说
- AI生成内容的本质是概率性的，无法从根本上保证精确正确
- DBCooker通过外部强制执行的伪代码计划和三阶段渐进验证，把概率性输出转化为可验证的正确实现
限制三：数据库版本迭代与AI训练数据滞后之间的矛盾
- 数据库函数的签名、内部宏的用法、系统目录的结构，会随版本更新而变化
- AI模型训练时接触的是历史数据，难以跟上最新版本的变化
- DBCooker通过动态检索当前版本的实现惯例，并用自适应工具编排加以强制执行，使系统能够直接适应版本变化而无需重新训练模型
限制四：闭源数据库的适用性
- DBCooker的函数特征化模块需要访问目标数据库的代码仓库和系统目录
- 对于闭源数据库或内部结构没有文档化的系统，适用性会受限
限制五：极端复杂函数
- 对于极端复杂的函数（比如涉及几百个底层依赖的聚合函数），当前版本的成功率仍然低于理想水平
六、行业影响与未来展望
6.1 对数据库开发者的直接影响
对于数据库开发者和企业IT团队而言，DBCooker意味着：
数据库迁移效率大幅提升
- 那些长达数月的数据库迁移项目，其中最耗时的函数重实现部分，未来或许能够得到切实的自动化支持
- 不再只是"AI能帮我搜索一些参考代码"这种程度的辅助
新函数开发周期缩短
- 从"人月"级工作量压缩到"小时"级
- 让更多开发者能够参与到数据库内核的扩展工作中
DBA角色转型
- 从"手工编写函数"转向"审核和优化AI生成的函数"
- 更专注于架构层面的决策
6.2 对软件工程领域的启示
对于更广泛的软件工程领域而言，这项工作提示了一个值得关注的方向：
面对高度结构化、规范严格、内部依赖复杂的特定代码合成任务，专项化的设计比通用方法有着相当明显的优势空间。
DBCooker的成功不是简单地把"让AI写代码"这件事重复一遍，而是针对数据库原生函数这个具体场景，把函数的结构分析、模板复用、分层验证和历史经验融合为一个有机整体。
6.3 未来演进方向
支持更多数据库
- 扩展到MySQL、Oracle、SQL Server等商业数据库
- 适配更多垂直领域的专用数据库
处理更复杂函数
- 提升极端复杂函数（比如涉及几百个底层依赖的聚合函数）的成功率
- 支持用户自定义复杂算法
智能化程度提升
- 让系统能够自动学习不同数据库的架构风格
- 实现跨数据库的函数迁移优化
集成到开发工作流
- 作为IDE插件实时辅助开发者
- 与数据库迁移工具深度集成
七、总结
DBCooker是一项具有里程碑意义的研究成果。它展示了AI在高度专业化、规范化极强的代码合成任务中的潜力。
核心贡献可以归纳为三点：
提出了函数特征化的方法论——通过解析文档和系统目录，结合图遍历和成对比较，精准定位函数的所有底层依赖
设计了填空式代码合成范式——把"作文题"转化为"填空题"，大幅降低AI生成错误率
构建了三阶段验证体系——通过语法检查、合规检查、语义验证三层关卡，把概率性AI输出转化为确定性正确实现
在AI+数据库融合的趋势下，DBCooker为代表的技术正在重新定义数据库开发的边界。正如研究团队在论文中所说：
"对于百万级参数的大模型，这意味着从'用不起'到'用得起'的质变；对于万亿级参数的超级模型，这意味着从'实验室专属'到'产业可用'的跨越。"
参考资源
- 论文DOI: 10.1145/3802018
- 开源代码: github.com/weAIDB/DBCooker
- 研究团队: 上海交通大学、清华大学、新加坡国立大学、蚂蚁集团
标签: 数据库, AI, 大语言模型, PostgreSQL, SQLite, DuckDB, 代码生成, 函数合成, ACM SIGMOD
关键词: DBCooker, 数据库原生函数, AI代码生成, LLM, 函数合成, 数据库迁移, PostgreSQL函数, SQLite扩展