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

说实话你这情况我太懂了，GPT写那种看着逻辑绕的代码，本质上是它把“看起来对”当成了“验证过对”，所以我会把需求拆成更细的函数，每个函数只干一件小事，然后让它在注释里把边界条件先写清楚，再生成代码。另外你提的用单元测试反推这个思路很靠谱，我最近就这么干，先让模型写测试用例，再让它补实现，比直接让它写全量代码稳得多。还有个土办法，就是故意在prompt里塞几个极端例子，比如传None和空列表，让它明确说该怎么处理，这比单纯说“注意边界”有效多了。

说实话我觉得问题出在“一步步思考”这种提示上，它反而会让模型在复杂路径里过度自信地补全细节。我现在的做法是只让它生成核心决策树的伪代码，然后我自己手动补边界条件，最后再丢给模型做单元测试生成，这样效率高很多。

另外你提到的代码补全模型配合测试反推，这条路我试过确实比纯prompt稳，尤其是用一些能执行测试的agent框架，让模型自己看报错信息迭代，比一次性生成完整逻辑靠谱。你可以试试把需求拆成“输入输出示例+异常预期”喂给它，比描述业务逻辑更直接。

这问题太真实了，GPT写复杂逻辑就像个记性不好的实习生，你给它步骤它倒是听，但一遇到边界条件就自己发挥了。我试过最管用的笨办法是让它把每个分支都写成独立的小函数，再手动拼起来，比让它一口气写完整个流程稳得多。至于动态SQL这种，干脆别让它生成完整逻辑，改成让它输出一个中间表示，你再用自己的模板去渲染，风险小很多。另外你说的用单测反推我试过，成本其实挺高，不如多写几个边界case喂给它当few-shot，效果比抽象指令直接。

说实话我觉得你方向有点偏了，GPT写这种复杂逻辑本来就不是靠prompt能解决的，它更擅长生成“看起来对”的代码。我试过最有效的方式是让它先写伪代码或状态机描述，你人工审核完逻辑再让它翻译成Python，这样等于把思考过程外包给它但决策权留给自己。另外你说的单测反推思路我很支持，但建议别用补全模型，直接用GPT生成测试用例来验证它自己的输出，失败就让它根据报错修，比单纯调prompt稳得多。

说实话你遇到的这个问题我太有共鸣了，GPT在简单任务上确实像个老手，一到逻辑嵌套深的地方就露怯。我个人感觉它其实不是在“思考”，而是在“预测最像样的代码片段”，所以一旦边界条件需要它自己做全局推演，就特别容易漏。你试过拆子任务和few-shot，这方向没错，但我发现更有效的办法是给它画“数据流图”——比如明确告诉它输入是什么类型、可能有哪些非法值、每一步输出应该长什么样，甚至直接让它先写伪代码再翻译成Python，这样能强制它模拟执行一遍逻辑。另外你说的单元测试反推我非常赞同，我现在基本是让GPT生成一个初始版本，然后我自己写几个关键边界case的测试，把报错信息原样丢回去让它修，来回两三次比单纯调prompt稳定得多。还有一个偏门但好用的技巧：让它用“防御式编程”风格写，就是每个函数开头先检查参数类型和空值，这样即使它逻辑想不周全，至少不会直接崩，你后续补漏洞也容易定位。最后我觉得，这类场景真没必要死磕单一提示词，结合代码补全模型（比如Copilot）做增量修改，反而比让GPT一口气生成整个函数靠谱，因为它能感知你项目里的既有风格和上下文。

这事儿我太有同感了，GPT写简单脚本是快，但一到那种层层if套着业务规则的逻辑，它就开始“一本正经地胡编”。我后来试了个笨办法，就是先把输出格式钉死，比如让它必须输出一个主函数加几个小工具函数，每个函数只干一件事，再在prompt里明确要求“所有参数默认None时直接返回空结果”，这样至少能少一半报错。还有个思路是别让它一次生成完整版，让它先写伪代码流程，你确认逻辑没问题再让它翻译成Python，相当于把复杂逻辑前置拆解了。你那个用单测反推的方法我觉得可行，但得先给它几个典型边界case的断言，不然它还是会自己发挥。

说实话你碰到的问题太典型了，我自己也反复踩过这个坑。我的体感是，对GPT这种模型来说，“一步步思考”其实帮不了太多，它更像是个概率游戏，复杂逻辑的搜索空间太大，你越给自由发挥的空间越容易跑偏。我现在遇到这种场景基本不指望它一步到位，反而是把函数签名、输入输出的类型约束、甚至把异常处理的骨架先写死，让它只负责填充中间那几行纯逻辑，这样稳定性会高不少。另外你说的用单元测试反推真是个很好的方向，我最近就在试，先让它生成一个能跑通的简单版本，哪怕丑一点，然后我自己补测试用例，把失败的case喂回去让它修，这个迭代过程比一开始就要求完美要高效多了。还有个小技巧是别用自然语言描述太复杂的规则，试着用表格或者伪代码把分支条件列出来，它反而更不容易漏。你那个动态拼接SQL的场景，我建议直接给它看两三个不同的权限组合对应的期望输出，比写一万字规则都管用。你有试过把每个权限分支单独拆成独立函数再去组合吗？我感觉这样它出错的概率会小很多。

单一prompt很难兜住复杂逻辑，不如把关键分支写成伪代码让它填空，再配单测跑几轮迭代修。

说实话你这情况我也踩过不少坑，GPT-4写简单脚本确实利索，但一到逻辑密集的地方就感觉它在“假装聪明”。我后来试下来，最管用的不是继续堆prompt技巧，而是把“系统提示词”当成一个“需求规格说明书”来写，明确要求它先输出伪代码、再写实现，并且每一步都要标注对应的测试用例。另外你提到用单元测试反推，这个思路我觉得靠谱，但别指望模型自己写全测试，你可以自己先列出五六个关键边界条件（比如None、空列表、权限空集），然后让模型按这些条件生成代码，最后用pytest去跑，失败就把它报错信息直接丢回给模型让它修，这样比让它“一步到位”稳得多。还有个小经验，就是明确告诉它“不要用简短写法，优先可读性和防御性编程”，比如所有字典访问都用get、所有SQL都用参数化拼接，这样能减少很多隐性bug。你那个动态SQL的场景，我怀疑它漏掉权限校验是因为你给的上下文里权限规则和SQL逻辑混在一起了，试试把权限规则单独抽出来作为常量或者配置表，让模型只负责“根据配置生成条件”，这样职责分离后效果会好不少。说到底，这玩意儿更像结对编程，你才是那个盯逻辑的人，它只是帮你省打字时间。

我最近也踩过这个坑，后来发现把“权限校验”和“SQL拼接”拆成两个函数分别生成，再自己手动粘一下，比让GPT一步到位靠谱得多。另外你提到的单元测试反推法我试过，确实能逼出不少隐藏bug，但得自己先写清楚测试用例，等于把逻辑难点又踢回给人类了。还有个土办法是让它先输出伪代码，确认逻辑分支没问题再让它翻译成Python，翻车率低不少。

说实话你这个情况我太懂了，GPT-4在复杂逻辑上就是典型的“局部合理、全局失控”，它特别容易把注意力放在最近几行代码的语义上，然后忽略掉整个函数的状态流转。我自己的经验是，与其费劲调Prompt，不如把“逻辑密集型”任务拆成“数据形状”来约束它——比如你那个动态SQL，先让它写一个纯函数处理权限过滤条件，再写一个纯函数处理字段映射，最后再让它们组合，每一步都喂给它具体的输入输出样例，而不是描述需求。另外你提到用单元测试反推，这个方法我试过真的有效，但建议别用补全模型，直接用GPT-4配合一个简单的测试框架，让它自己跑测试看报错再修，比单纯靠Prompt稳定得多。还有个坑是少用“一步步思考”，这招对推理题有用，但写代码时反而容易让它陷入过度解释然后写出冗余分支，我一般会加一句“不要解释，直接输出完整代码，并标注每个参数的边界条件”。最后想问你一下，你有没有试过在Prompt里显式要求它“先列出所有可能的边缘输入，再写代码”？我感觉这个方法对防止漏校验挺有帮助，但不确定是不是普适。

试试把关键边界条件直接写进prompt里当硬性要求，比让它自己琢磨靠谱得多。

说实话你这痛点我太懂了，GPT写简单逻辑像模像样，一上复杂嵌套就爱自作主张。我后来发现，与其费力调prompt，不如把关键决策点直接写死成伪代码或状态机描述，让它照着填实现，而不是自由发挥。另外你提的用单测反推思路很对，我实践下来效率高不少，尤其是拿测试用例当约束条件，比加一万句“注意边界”都好使。

说实话你这情况我太熟了，GPT写那种“看起来对但一跑就炸”的代码简直是日常。我觉得核心问题不是prompt技巧，而是它压根没在“执行”你的逻辑，只是在做模式匹配——你给的需求越接近它训练集里的常见写法，输出就越靠谱，一旦涉及业务特有的边界条件，它就全靠编。我之前试过把权限规则直接写成表格塞进prompt里，让它照着表逐行翻译成if语句，效果比描述需求好很多，但前提是表得足够具体。至于单元测试反推那个思路，我觉得方向是对的，不过用GPT-4写测试用例本身也会引入同样的问题，不如自己手写几个核心断言，然后让模型根据报错信息迭代修代码，实测比一次性生成完整函数靠谱。还有个野路子，把复杂逻辑拆成多个小函数，每个函数单独对话生成，最后再让模型做胶水拼接，虽然麻烦，但每一步的出错范围都被缩小了。不过说实话，真要搞生产级工具，还是得靠人肉review加静态分析工具兜底，大模型当个快速原型还行，指望它直接交付逻辑密集型代码，目前还是有点赌运气。

确实，逻辑密集场景不如直接上单元测试驱动，让GPT先写测试再补实现，比堆prompt稳多了。

试试让GPT先写测试用例再写实现，能逼它把边界条件想清楚，比单纯加prompt管用。

我之前也踩过这个坑，尤其是动态SQL这种，prompt再细也扛不住隐式边界条件。后来我干脆把“权限校验”和“字段映射”拆成两个独立函数，让GPT分别生成，再手动粘合，逻辑漏洞明显少了。另外你可以试试在prompt里直接给几个具体的异常输入样例，比如空列表、None值，让它先写防御代码，再填业务逻辑。至于单元测试反推这个思路，我试过用测试用例当few-shot，比单纯描述需求靠谱多了，但得接受有时候要来回调好几轮。

别指望一步到位，把复杂逻辑拆成小函数逐个让GPT写，再配测试用例卡它，比啥prompt都稳。

说实话你这个问题我太有共鸣了，GPT在复杂逻辑上确实像“半瓶水”，表面看着能写，一深挖就露馅。我试过把需求拆成子任务，甚至给它画伪代码流程图，但结果还是得自己逐行review，反而比直接写还累。后来我换了个思路，与其纠结prompt，不如把“验证”环节交给测试用例——先让它生成一个粗糙版本，然后用边界值（比如空列表、None、嵌套权限组合）去跑单测，报错再喂回给它，让它自己修，这样比一次性要求“完美输出”靠谱得多。另外我发现，动态字段映射这类问题，让它输出时附带一个“前置条件检查清单”会比单纯让它写函数有效，比如强制它先打印处理逻辑的假设。你试过用代码补全模型（比如Copilot那种）配合TDD吗？我觉得那个路径可能更适合逻辑密集型场景，至少反馈循环快。但说实话，核心痛点还是模型对“业务约束”的建模太弱，有时候你明确写了“必须校验权限”，它还是会在某个分支里漏掉，这真不是prompt能彻底解决的，得靠人机协作。

你这需求已经超出提示词能兜住的范畴了，不如直接上类型注解加单元测试，让报错逼着它改。