数据库原生函数的开发，一直是困扰工程师们的难题。这些内置在数据库中的“小工具”，承担着处理时间戳、拼接字符串、解析JSON等关键任务。以PostgreSQL为例，其原生函数数量从2018年的237个激增至2026年的630个，DuckDB更是从60个跃升至666个。然而，手动实现这些函数的过程异常繁琐——PostgreSQL的相关代码依赖关系超过11.9万行，DuckDB的GitHub仓库中相关问题单多达3791条。每新增一个函数，开发者需在多个文件中注册、实现并引用内部接口，稍有不慎便会引发编译错误或逻辑漏洞。
针对这一痛点，上海交通大学联合清华大学、新加坡国立大学及蚂蚁集团的研究团队，提出了一套名为DBCooker的自动化系统。该系统借助大语言模型，实现了数据库原生函数的自动合成。实验数据显示，在SQLite、PostgreSQL和DuckDB三大数据库上，DBCooker的平均准确率比当前最强对手高出34.55%，并成功为SQLite最新版添加了四大类全新函数。这一成果发表于ACM数据管理顶级期刊《Proceedings of the ACM on Management of Data》第4卷第3期。
数据库原生函数开发的复杂性，源于三个核心障碍。其一，SQL层面的函数往往对应多个底层单元。以PostgreSQL的`date_trunc()`为例，其背后涉及处理时区时间戳、时间间隔等四个底层函数，这些映射关系深埋在代码仓库中，缺乏明确文档。其二，代码仓库规模庞大，SQLite每个文件平均有2619个可引用函数，但实际需要的仅13.73个，精准定位关键函数如大海捞针。其三，函数复杂度差异显著，从简单的`sqrt()`到复杂的`json_agg()`，代码量可能相差数十倍，通用流程难以兼顾。
现有AI代码生成工具，如Claude Code和Qwen Code，在面对这些挑战时表现乏力。研究显示，Claude Code在合成数据库函数时，63.70%的时间用于搜索仓库和读取文件，真正生成代码的时间仅占4.95%。其错误中81.76%属于声明错误，如函数注册位置错误或引用不存在的接口。DBCooker则通过专项设计，针对性地解决了这些问题。
DBCooker的工作流程分为三大模块。首先是“函数特征化”模块，它通过解析数据库文档和系统目录，提取函数的文字描述、使用示例及精确签名，生成统一的JSON格式“函数档案”。随后，系统采用图遍历方法，从SQL关键字出发，沿调用关系识别所有相关底层单元，排除全局通用单元。对于同类函数，系统还会进行“成对比较”，提炼可复用模板并标记变化部分。
其次是“函数合成操作”模块，包含伪代码计划生成、填空式代码合成和三阶段代码验证三个环节。伪代码计划生成阶段，系统生成多份候选实现方案，通过评分公式筛选最优方案，评分考虑可信度（引用接口实际存在比例）和简洁性（函数单元数量）。填空式代码合成阶段，系统复用模板固定部分，让AI专注于填写变化逻辑，并采用“少数服从多数”策略选出最终代码。若模板质量不佳，系统会自动降级，逐步减少对模板的依赖。三阶段代码验证则依次进行语法检查、合规检查和语义验证，确保代码无拼写错误、能成功编译并通过所有测试用例。
最后是“自适应工具编排”模块，它将生成计划、写代码、验证等操作包装为标准化工具，由AI控制器根据函数复杂度动态决定操作序列。控制器参考历史经验库，记录过去合成类似函数时的操作序列，综合最省事、最费劲和中间水平的做法，结合当前状态决定下一步行动。这种设计避免了“一刀切”，简单函数无需冗长流程，复杂函数也能得到充分处理。
在SQLite、PostgreSQL和DuckDB上的测试中，DBCooker展现了显著优势。综合三个数据库，其合规准确率达78.90%，结果准确率达65.19%，分别比其他方法平均水平高出124.37%和149.68%。在难度较高的函数上，DBCooker的优势尤为明显，困难函数的合规准确率达68.97%，而其他方法平均仅约22%。按函数类别看，DBCooker在PostgreSQL的数学、日期、字符串、JSON四大类函数上，合规准确率从89.19%到96.67%不等，整体稳定且均匀。
研究团队还进行了补充实验，将正确的文件路径、函数声明和引用接口提前告知竞争对手，结果这些方法的准确率仍比DBCooker低22.56%。这表明，数据库原生函数合成的难点不仅在于“找到正确文件”，更在于生成符合数据库内核规范的代码。错误分布分析显示，通用LLM方法的错误以声明错误为主，占约82%；Claude Code等智能体工具虽能主动验证声明位置，但仍频繁出现引用不存在接口的问题；DBCooker则通过函数特征化和三阶段验证，将各类错误压至最低水平。
消融实验进一步验证了系统各模块的贡献。去掉“函数特征化”模块后，PostgreSQL的合规准确率从78.62%骤降至6.9%；去掉“三阶段验证”模块后，准确率从78.62%降至37.04%；两者都去掉时则跌至9.66%。这表明计划和验证相辅相成，缺一不可。去掉“自适应工具编排”模块后，三个数据库的结果准确率分别下降至49.33%、21.19%和30.61%，说明动态编排能有效提升资源利用效率。
除了在已有函数上的测试，研究团队还尝试将PostgreSQL和DuckDB中有、但SQLite中没有的函数，用DBCooker合成到SQLite中。这项工作难度更高，因不同数据库内部架构差异极大，代码需从头适配SQLite规范。DBCooker成功合成了全部17个新函数，涵盖聚合、日期、数值和字符串四大类，而Claude Code和TRAE各合成12个，Qwen Code仅合成7个。以`covar_pop`为例，DBCooker正确识别出其需要三个底层单元，并用SQLite专属宏正确注册；Qwen Code虽正确注册了声明，但未实现`covarPopInverse`，导致编译时报错。以`regexp_split_to_array`为例，DBCooker正确使用了SQLite内部接口，而其他方法尝试引用不存在的外部接口，直接触发合规错误。
与通用代码生成、用户自定义函数优化、运行时代码生成及数据库迁移等领域的工作相比，DBCooker的边界清晰。通用代码生成工具缺乏对数据库内核的针对性理解；用户自定义函数优化工作聚焦于提升已有函数执行效率；运行时代码生成工作生成临时性代码；数据库迁移工作处理SQL语句表层语法转换。而DBCooker专注于从零合成新函数并集成进数据库内核，粒度和难度更高。
研究团队指出，DBCooker未来仍面临三大挑战。一是代码库碎片化与长上下文推理的矛盾，PostgreSQL源代码超百万行，声明和实现分散在不同文件，即便AI能处理超长上下文，也可能遗漏关键细节。DBCooker通过“函数特征化”提前定位相关内容，是解决这一矛盾的有效路径。二是数据库确定性正确性要求与AI概率性生成本质的矛盾，数据库函数必须输出正确结果，而AI生成内容本质是概率性的。DBCooker通过伪代码计划和三阶段验证，将概率性输出转化为可验证的正确实现。三是数据库版本迭代与AI训练数据滞后的矛盾，数据库函数签名、内部宏用法等会随版本更新变化，AI模型训练时接触的是历史数据，难以跟上最新变化。DBCooker通过动态检索当前版本实现惯例，并用自适应工具编排强制执行，使系统能适应版本变化而无需重新训练模型。
DBCooker为数据库原生函数开发提供了一套自动化流程，将函数结构分析、模板复用、分层验证和历史经验融合为一个有机整体。对于数据库开发者和企业IT团队而言，这意味着数据库迁移项目中耗时的函数重实现部分，未来可能得到自动化支持。对于软件工程领域，这一工作提示，面对高度结构化、规范严格、内部依赖复杂的特定代码合成任务，专项化设计比通用方法更具优势。感兴趣者可查阅论文DOI 10.1145/3802018，或访问GitHub开源代码库weAIDB/DBCooker复现实验或尝试应用。
