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

老实说你这情况太典型了，我也踩过同样的坑。后来发现与其把复杂逻辑全塞给GPT，不如让它只负责生成可测试的骨架代码，比如把动态SQL拆成参数校验、权限过滤、拼接三个独立函数，每个函数给明确的输入输出示例。配合单元测试确实管用，我试过先写测试用例再让模型补全实现，逻辑漏洞明显少很多。不过你提到的边缘情况，感觉还是得自己在prompt里显式列出所有异常场景，比如“当user_roles为空列表时返回空字符串”，模型对这类显式约束的遵循度会高不少。

深有同感，GPT在复杂逻辑上确实容易“想当然”地跳过边界条件。我最近的做法是把权限校验这类规则单独写成pytest用例，让模型先生成能通过测试的代码，而不是直接让它写完整逻辑。另外对于动态SQL拼接，我会在prompt里明确要求它把所有输入类型都显式判断一遍，比如空列表返回空字符串，None值抛自定义异常，这样翻车率能降不少。你试过先画个伪代码流程图再让GPT转成具体实现吗？

同感，复杂逻辑翻车真的太常见了，尤其是权限校验和边界条件这种，GPT经常想当然。我自己试过把“动态字段映射”拆成独立的函数定义，再让GPT分别写每个小函数，最后手动组装，成功率会高一些。另外，你提到的用单元测试反推其实挺靠谱，我最近在试先写测试用例再补代码的思路，虽然前期麻烦点，但至少逻辑漏洞能被卡住。要不要试试把关键错误场景直接塞进prompt里当约束条件？

同感，复杂逻辑还是得靠手动拆解加单元测试兜底，光靠prompt很难一次搞定。

老实说你这情况太典型了，我最近也在折腾类似的事。GPT写简单逻辑确实快，但一遇到多层嵌套或边界条件，就跟喝醉了似的。我的经验是：光靠prompt技巧其实有天花板，尤其是当逻辑依赖“上下文状态”时——比如动态字段映射，模型根本记不住你前面定义了哪些字段。不如换个组合拳：让GPT只生成核心逻辑的伪代码或骨架，然后你手动补边界判断，或者干脆把单元测试用例先写进prompt里，让它按测试过。另外我试过把复杂条件拆成独立的函数描述，每个函数只做一件事，再让GPT写串联逻辑，成功率能提不少。不过说实话，你提到的“换代码补全模型+单元测试”路子我最近也在试，Copilot配合pytest反向驱动，比纯对话靠谱，至少报错后能快速迭代。你那个动态SQL场景要不要试试先定义好输入输出的类型约束？比如用Pydantic写个schema，让它照着生成，逻辑漏洞会少很多。

这个问题太真实了，我发现把复杂逻辑拆成单元测试让GPT先通过，比直接写代码稳得多。