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

我也有同感，复杂逻辑翻车太频繁了。后来我尝试先写伪代码再让AI填充细节，效果稍微好点。

说实话你遇到的这个问题太典型了，我也有过类似的翻车经历。GPT在处理多层嵌套和边界条件时，本质上是在“猜”你隐含的意图，而不是真正理解逻辑链的闭环。我觉得一个比较系统的思路是：把“逻辑校验”拆成显式的约束写在Prompt里，比如直接要求“必须处理None值和空列表，并在注释里写明每个分支的触发条件”，让它没法偷懒。另外我试过让GPT先生成伪代码框架，把条件分支画成树状结构描述出来，再让它填充具体实现——这样它不太容易跳步骤。你提到的代码补全模型配合单元测试其实挺靠谱的，我自己就经常让GPT先写测试用例，再反向生成函数体，这样边界情况会被测试先定义好，代码质量高很多。不过话说回来，像动态SQL拼接这种敏感逻辑，我最后还是自己手写了核心模块，只用AI辅助写测试和文档——毕竟安全校验漏了可不是小事。你试过用“角色扮演”的方式吗？比如让它扮演一个安全审计专家，先检查你给出的伪代码有没有漏洞，再生成最终版本？

我最近也碰到了类似的问题，感觉深层原因不是prompt不够细，而是GPT在理解“状态流转”和“边界条件”时容易产生幻觉。我试过把逻辑画成伪代码流程图喂给它，效果会比纯文字描述好一些。另外针对你提到的动态SQL场景，我个人经验是先把所有可能的输入情况（包括None和空列表）写成测试用例，让GPT先生成通过测试的代码，而不是直接写逻辑。这样至少能保证覆盖主要坑点，虽然框架感强了点，但翻车率确实降了。

单元测试反推这思路靠谱，让报错教你补逻辑，比干调prompt省心多了。

别硬磕prompt了，复杂逻辑直接拆成函数让模型单测驱动改，比堆描述稳得多。

说实话你这情况我太懂了，GPT写简单脚本确实快，但一碰复杂逻辑就原形毕露。我后来干脆换个思路，让它只输出核心算法骨架，我自己补齐边界检查和异常处理，反而比逼它一步到位靠谱。另外你可以试试把权限校验、None值这些“隐藏约束”单独列出来，当成硬性要求写进prompt，效果比笼统说“注意边缘case”好得多。单元测试反推那招我也试过，成本有点高，除非是核心模块，不然性价比一般。

我也踩过这个坑，后来发现关键在于别让它“设计”，而是让它“翻译”——你把伪代码或流程图写清楚，它照着实现基本不会跑偏。复杂逻辑里那些分支条件，人类自己都容易绕晕，指望LLM一次想全确实不现实。你可以把函数拆成几个纯函数，每个只干一件简单事，再让它负责组合，最后用几个刁钻的测试样例去怼它，比加多少prompt技巧都管用。

你这问题问到点子上了，我试过最有效的办法是给GPT“画地为牢”：明确告诉它哪些分支必须显式处理，比如“如果权限列表为空，直接返回空查询”，这种硬性规则比让它自己发挥稳定得多。另外你可以考虑用类型注解和docstring把输入输出约束写死，它能少很多“自由发挥”的空间。至于代码

说实话你遇到的这个情况我也踩过坑，GPT-4在复杂逻辑上更像是个“熟练的实习生”，不是“严谨的工程师”。我自己试下来，最有效的不是继续堆prompt技巧，而是把“让它写代码”改成“让它做代码评审”——你先给它一个你手写的带bug的版本，让它挑错和补边界条件，这样反而比让它从零生成更稳。另外你提到的单元测试反推，我觉得是正解，尤其对动态字段映射这种场景，先写五六个测试用例（空列表、None、权限缺失、重叠权限）然后让模型对着测试改代码，比纯粹描述需求靠谱得多。还有个土办法，就是让模型把每一步决策用print打出来，比如在拼接SQL前打印“当前用户角色”和“已过滤的字段”，这样就算出错也能快速定位是哪个环节漏了逻辑。至于“一步步思考”这招，我怀疑它只是让模型把推理过程写出来，但推理本身还是概率性的，所以效果时好时坏。如果你愿意折腾，可以试试用Claude或者本地跑的DeepSeek做交叉验证，两个模型的盲区往往不一样，互相查漏挺有效。最后提醒一下，动态SQL这种高风险代码，哪怕GPT生成得再顺，也得强制套一层白名单校验，别完全信任输出。

别死磕prompt了，这种逻辑活直接让模型写单测驱动，拿测试报错反哺生成代码，比加几个示例稳得多。

实不相瞒，我跟你一模一样，GPT-4在复杂逻辑上就是个“嘴强王者”，描述得头头是道，跑起来全是坑。后来我干脆放弃让它一步到位，改成让它输出带断言的中间步骤，然后我拿真实数据集去跑，报错就丢回给它修，来回两三轮才稳。你这情况我建议别死磕prompt，试试让模型先画个状态机或者决策树，写清楚每个分支的输入输出，再让它转成代码，比它自己脑补强太多了。

另外你提到代码补全模型加单测，这招我试过确实靠谱，但得先把测试用例写全，特别是空值和权限边界，不然模型照样给你糊弄过去。我个人现在的习惯是，复杂函数先让它生成“伪代码+注释”的骨架，我手动补逻辑，再让它优化细节，反而比全权委托省心。

不如直接让它先写单测，再按测试补实现，比堆prompt稳多了。复杂逻辑靠嘴说真不如靠报错迭代。

试试把权限规则拆成数据驱动，先定义好状态表再让模型填逻辑，比纯描述场景好用。

我最近也踩过这个坑，感觉GPT在复杂逻辑上更像是“拼概率”而不是“推演状态”，尤其权限那种跨函数的前置约束，它经常顾头不顾尾。后来我干脆把边界条件直接写死在prompt里，比如“空列表返回[]，None跳过”，再让它针对每个分支输出测试用例，效果会好一点。但说实话，这类场景我最后都是人肉兜底，用单测去卡它生成的代码，比指望一次写对高效得多。

说实话你这个情况太典型了，GPT在简单逻辑上确实像模像样，一到复杂条件组合就原形毕露。我最近也试过让它写带状态机的解析器，结果它自己创造了两个不存在的分支，后来我干脆把每个分支的输入输出样例直接贴进prompt，让它照着模式写，比单纯描述逻辑靠谱不少。另外你提的用单测反推这思路我觉得可行，我试过让模型先写测试用例再写实现，虽然慢点但至少能暴露它自己漏掉的边界条件。

单元测试反推这个思路靠谱，我试过让GPT先写测试用例再补实现，正确率能高一截。

试试让它先写测试用例再写实现，用测试当约束条件，比prompt调教稳得多。

说实话我最近也卡在这个问题上，后来发现与其纠结prompt，不如把复杂逻辑拆成纯函数再加单元测试去跑，让GPT先生成骨架，测试挂了再把报错丢回去让它修，比一次性让它写完整版靠谱多了。另外你试过让模型先输出伪代码或者数据流图吗？有时候它逻辑漏洞是因为没想清楚状态变化，逼它先写注释再补代码会好很多。不过动态SQL这种我还是建议手动写权限白名单，别全交给模型，安全边界真不能赌。

说实话你遇到的这个情况我太懂了，GPT-4在复杂逻辑上就是会给你一种“好像会了但细看全是坑”的感觉，尤其是动态SQL这种涉及安全边界的场景，它经常默认你传进来的参数都是合法且非空的。我自己试下来，与其反复调prompt，不如把“函数签名+类型注解+明确的异常处理要求”直接写进指令里，比如明确告诉它“所有可能为None的参数必须显式判断，否则raise ValueError”，这样比“一步步思考”有用得多。但我觉得你提到的用单元测试反推思路其实更靠谱，因为LLM生成代码的最大问题不是语法，而是语义覆盖不全，你不如让它先生成几个核心用例，再逼它写实现去通过测试，这个闭环比单纯靠prompt稳定。另外对于权限拼接这种，你可能得考虑让模型输出一个纯函数，把用户角色和查询条件作为输入，而不是让它直接写一个“全自动”的完整逻辑，这样它犯错的概率会小很多。我也还在摸索，比如试过把复杂分支拆成多个小函数再合并，但有时候模型会自己“聪明”地合并掉一些你不想合并的判断，挺头疼的。

单元测试反推靠谱，让报错当你的提示词，比干调prompt快多了。

说实话你这情况我太熟了，GPT-4在简单逻辑上确实像模像样，一上复杂度就原形毕露，本质是它靠模式匹配生成代码，而不是真正在“推演”状态流。我自己试下来，最管用的不是堆prompt，而是把“不可变约束”单独拎出来写进系统提示词里，比如“所有输入参数必须显式判空，任何SQL拼接前必须经过白名单校验”，这种硬性规则比“一步步思考”有效得多。另外你提到的单元测试反推法我强烈支持，但别真指望让模型自己写测试再自己修，而是你先手写三五个边界case的测试，然后让模型看着失败输出迭代代码，这相当于把逻辑压力转移到了“验证”环节，而不是让模型一次性生成完美解。还有个偏方，把复杂逻辑拆成纯函数+组合，每个函数只干一件事且输入输出类型严格限定，这样模型就算中间某个环节翻车，你也能靠类型提示和局部测试快速定位。说到底，prompt只是降低出错概率，真到了权限拼接这种安全敏感场景，我建议还是人工review一遍最终生成的SQL模板，别全信模型。你试过让GPT先生成伪代码再翻译成Python吗？我最近发现这招对复杂分支条件的正确率提升挺明显。

说实话你提到的“动态字段映射”我太有同感了，GPT在这种地方特别容易自作聪明。我现在的做法是，把复杂逻辑拆成函数级粒度，每个函数只让它干一件小事，然后我自己写个薄薄的编排层去拼装，比让它一口气生成完整流程稳得多。另外，单元测试当prompt的一部分喂进去特别有效，比如把边界case直接写在注释里，让它照着实现，这样比口头强调“考虑None”好用十倍。

别死磕prompt了，直接上单测驱动，让报错信息帮你迭代，比啥提示词都靠谱。

我最近也踩过类似的坑，感觉GPT在复杂逻辑上不是“不会”，而是容易把隐含约束漏掉。后来我习惯把每个边界条件单独写成一条规则，比如“如果传入的权限列表为空，直接返回空查询”，这样喂给它，出错率明显低了。另外你提的用单元测试反推挺靠谱，我偶尔会先让模型生成函数骨架，再用几个极端case去测，让它根据报错自己修，比纯靠prompt稳定。不过说实话，真遇到特别绕的映射关系，我还是手动写逻辑+让模型补模板，效率反而更高。