用Prompt调教GPT写代码，为什么总在复杂逻辑上翻车？

说实话你这个场景我太熟了，GPT-4对复杂业务逻辑的理解其实就是“表面拼接”，它根本不理解权限和数据流之间的约束关系。我试过最有效的办法是给它画“输入-处理-输出”的极简表格，再在表格里标注每个边界case应该返回什么，比写一堆自然语言描述管用得多。至于单元测试反推，我觉得可以搭配着用，先让它生成代码，再用几个必挂的测试用例去逼它修，但别指望它能自己想到所有边界条件，那真得靠人肉补。

说实话你遇到的这个情况我太懂了，GPT写那种“表面逻辑”的代码确实好用，但一到状态机、权限矩阵这种隐含约束多的场景，它就容易自作聪明。我个人试下来，最有效的不是把需求写得更细，而是逼它先输出一份“伪代码+边界case清单”，让它明确列出空输入、None、权限缺失时分别该返回什么，然后再让它落地成Python，这比直接写函数靠谱得多。另外你提到用单元测试反推，我觉得这思路真没错，但别指望对话式补全一步到位，更实际的做法是让模型先生成带类型注解和docstring的骨架，你再拿pytest去卡边界，报错了就把traceback贴回去让它修，这比反复描述需求要高效。还有个偏门但好用的技巧，就是故意在prompt里塞一个错误示例，告诉它“这种写法会在list为空时崩”，模型往往能避开同类坑。说到底，这种场景GPT更像是个需要反复review的实习生，你得把“验收标准”前置，而不是指望它一次写对。你现在是卡在生成阶段，还是觉得调试阶段来回贴代码太耗时间？

这问题我太有同感了，GPT写那种带状态流转或者权限边界的逻辑，基本就是看着能跑，一测就炸。我后来发现拆子任务不如直接让它输出“策略描述+伪代码”再转成正式实现，相当于逼它先梳理逻辑树。另外你提的代码补全模型配单测，我觉得才是正道，与其赌它一次写对，不如让它生成骨架，你用断言把边界条件钉死，迭代几轮反而稳。你试过把数据库schema和权限规则直接塞进system prompt里吗？我发现给它看真实结构比抽象描述管用很多。

说实话你这路子我试过，拆子任务和few-shot对简单逻辑还行，一复杂照样崩。我后来发现关键不是让模型“想清楚”，而是把每个分支条件都写成明确的assert或者类型检查，逼着它把边界情况当一等公民处理。另外你可以试试把输出格式固定成伪代码加注释，再让模型自己翻译成Python，有时候比直接写代码稳很多。但说实话，真到了这种复杂度，不如自己搭个骨架，让GPT填函数体，配合pytest跑几轮，比纯靠prompt硬调效率高多了。

我之前也踩过这个坑，后来发现让GPT直接写完整逻辑确实容易崩。我的做法是先让它把伪代码或判断分支列出来，我确认没问题再让它逐段翻译成代码。另外权限拼接SQL这种场景，与其让它自由发挥，不如把边界条件一条条喂进prompt里当硬性约束，比什么“一步步思考”管用多了。

逻辑密集的活儿还是让模型先写测试用例再补实现，比硬憋代码靠谱。

拆成子任务反而容易丢上下文，不如直接给完整函数签名和边界case让它补全。

我也遇到过类似情况，感觉GPT在处理多层逻辑时容易“丢分支”，特别是权限校验这种需要全局一致性的地方。后来我改成先让它输出伪代码或流程图，确认逻辑没问题再让它翻译成Python，稳不少。另外空列表和None这种边界，最好在prompt里直接列出来当约束条件，别指望它自己想到。复杂逻辑还是得配合单元测试反推，光靠prompt调教确实有上限。

复杂逻辑别硬让GPT一次写完，拆成小函数逐个生成再串起来，配合单元测试卡边缘case，稳很多。

我之前也踩过这个坑，后来发现关键是别让模型一步到位写完整逻辑。我的做法是先让它把权限校验、字段映射这些子逻辑拆成独立函数，每个函数单独生成再拼起来，边缘case用注释明确写进prompt里。另外SQL拼接这种场景，直接上ORM或者查询构造器比让模型手写字符串靠谱得多，模型很容易漏掉转义和参数化。单元测试反推确实有用，但得你先写好测试用例喂给它，不然它自己编的测试覆盖不到边界。

拆成函数签名加类型标注再让它填逻辑，比整段生成稳不少。

我之前也踩过差不多的坑，后来发现关键问题不在Prompt写得够不够细，而在于这类动态SQL拼接本身就不太适合让模型一把梭。GPT在多层条件里很容易把“权限校验”和“字段过滤”这两个关注点混在一起，结果就是顾此失彼。我现在的做法是强制它先输出一份伪代码或者决策表，把每个分支和边界条件都列清楚，确认逻辑没漏再让它转成Python。另外你提到的单元测试反推思路我觉得挺靠谱，尤其是空列表、None这种case，直接写成测试用例喂给它，比用嘴描述“注意边界”管用得多。还有个野路子是把任务拆成“生成查询骨架”和“填充权限规则”两步，中间用结构化JSON做桥接，能明显减少它自由发挥的空间。不过说实话，逻辑密度到一定程度后，人的review还是省不掉，模型顶多帮你把样板代码写快一点。

我之前也踩过这个坑，复杂逻辑确实不能指望它一把梭。后来我改成让GPT先输出伪代码或者决策树描述，确认逻辑分支没问题了再让它翻译成Python，边缘case漏掉的情况少了很多。另外权限拼接SQL这种场景，最好在Prompt里直接把所有边界条件列成检查清单让它逐条对照，比单纯说“注意边界”管用。你试过让它先写单元测试再写实现吗？

我最近也踩过类似的坑，后来发现关键不是把需求描述得多细，而是让模型先输出伪代码或逻辑分支树，确认无误再让它翻译成Python。另外动态SQL拼接这种场景，我会强制它先列出所有边缘case的断言，再生成带单元测试的代码，跑不通就让它根据报错自己修。单纯靠prompt优化确实有上限，配合测试驱动的方式会稳很多。

我感觉问题不在Prompt技巧上，而是这类逻辑密集型代码本身就难一次生成对。我现在的做法是先让模型把函数签名和边界条件列出来，确认没问题再让它填实现，最后自己补单元测试跑一遍。动态SQL拼接这种场景，最好把权限规则写成显式的数据结构喂给它，别让它自己脑补逻辑。另外GPT-4对None和空集合的处理确实容易翻车，测试用例比Prompt管用多了。

这个思路不错，收藏了。