用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让它补全。