用Prompt调教GPT写SQL老翻车，有没有系统的方法论？

表结构全文直接丢进去肯定不行，token一长模型注意力就散了。我一般会把表拆成几个逻辑模块，每个模块单独生成一段建表DDL再让GPT基于这个写，幻觉能少一半。你还可以试试让它先输出一段伪代码或者中文逻辑步骤，确认思路对了再让它转SQL，比直接要结果稳很多。

另外你那个“先把表结构贴进去再写需求”的顺序可能也有问题，我习惯先给角色设定（比如“你是资深数仓工程师”），再给需求，最后才贴精简过的表结构，并且明确告诉它“只能用我提供的字段，不能自己编造”。要是还翻车，就把报错信息原样丢回去让它自己修正，比重新描述一遍有效。

表结构摘要+字段字典是关键，再让GPT先写伪代码确认逻辑，比直接生成SQL稳得多。

表结构别一股脑全塞，我试过把字段按业务模块拆成几个小块，每次只给GPT相关的那部分，幻觉直接少一半。另外别光贴DDL，给它两三条带真实数据的INSERT样例，它自己就能摸清字段含义和关联逻辑，比写一堆角色设定管用。

试试把表结构转成DDL注释版+三个正反案例丢进去，再让它先写伪代码后转SQL，成功率能高不少。

表结构太长确实是个坑，我之前也踩过。直接丢全文的话，GPT经常在几百行DDL里迷路，反而更容易捏造字段。我的做法是先只给跟当前查询相关的表，每张表只保留需要的列，顺便把字段注释和类型也带上，这样幻觉率降了不少。另外可以要求它先输出分析步骤，比如“先列出涉及哪些表、哪些字段、join条件是什么”，确认没问题再让它写SQL，相当于让它自己先对一遍答案。示例这块也别给太简单的，最好给一个跟真实场景接近的few-shot，格式固定成“表结构+需求+正确SQL”，它模仿起来会稳很多。角色设定我一般会写成“你是资深数仓工程师，只使用我提供的字段，不允许假设任何未出现的列名”，这句话挺管用的。还有个偏方是让它生成完SQL后自己再检查一遍字段是否都在DDL里出现过，等于加了个自检环节。温度调到0或者0.2也有帮助，别让它太发散。

表结构太长确实得先做裁剪，我一般只给相关表和字段，不相关的全砍掉。另外你可以在prompt里加一两条“问题SQL→修正SQL”的few-shot示例，尤其是窗口函数那种，模型照着抄格式会稳很多。还有个小技巧是让它先输出查询思路再写SQL，中间步骤能帮你定位到底哪步开始跑偏。角色设定感觉作用有限，不如把DDL写成CREATE TABLE那种标准格式，它理解起来更准。

表结构别直接全丢，容易把模型带偏。我一般只给相关表，字段名和类型保留，顺便塞两三条示例数据，模型对字段理解会准很多。让GPT先复述需求再写SQL，中间有错能早点发现。复杂查询最好拆成子步骤，别指望一次生成到位。

表结构太长建议先精简，只保留相关表和字段，不然模型注意力容易散。我一般会固定一个模板：角色+表DDL+字段注释+一两个正确示例，再让它先输出思路再写SQL，幻觉会少很多。另外可以让它自己检查字段是否存在，比直接生成靠谱。

表结构直接丢全文确实容易翻车，我一般会先让模型把DDL压缩成“表名+字段+一句话说明”的精简版，再喂给生成SQL的那轮。模板结构挺关键的，我习惯固定成：角色（资深数仓）、方言（MySQL还是Hive）、表结构、需求、输出格式（只出SQL别解释）。另外少样本示例最好用真实字段，别用user/order这种泛化例子，模型对字段名一致性很敏感。表特别多的话，可以先让它列出需要哪几张表，再单独把那几张的完整结构喂进去。

表结构全丢进去反而容易让模型分心，我一般只保留跟这次查询相关的表和字段，再补一句“只能使用以上字段，禁止编造”。模板的话，角色设定成“资深数据分析师”有点虚，不如直接给两三个真实风格的SQL示例，让它照着格式走。窗口函数这种最好把预期输出列名也写清楚，不然它老爱自己起别名。

表结构全丢进去确实容易翻车，模型注意力会被稀释，尤其字段一多它就抓不住重点了。我一般会先让它根据问题反推需要哪些表，再只把那几张表的DDL贴进去，字段注释尽量写清楚，效果稳不少。示例也别给太简单的，最好给一个真实场景的输入输出对，让它模仿那个格式和推理路径。角色设定有点用但别指望太多，关键还是把需求拆成“先确定过滤条件、再确定聚合维度、最后拼窗口逻辑”这种步骤让它一步步来。另外可以要求它输出前先列个字段使用清单，确认每个字段都在DDL里存在，能压掉不少幻觉。表结构特别长的话，摘要不如分片召回，先把相关表筛出来再喂全文更靠谱。