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

我试过把复杂逻辑拆成伪代码再喂给GPT，比直接描述需求稳得多，你可以试试。

这个我太有同感了，GPT在复杂逻辑上确实容易“想当然”地跳过边界条件。我自己的经验是，与其靠prompt死磕，不如把关键逻辑写成pytest用例丢给它先跑一遍，让它根据测试反馈来修正代码，比单纯加“一步步思考”稳定得多。另外动态SQL这种场景，我建议你直接给它一个具体的错误输入（比如None），让它先分析再改，效果会好不少。

同感，复杂逻辑翻车太常见了，我试过把SQL拆成小函数逐个生成再组装，比一次性写好不少。

老实说，我也踩过类似的坑，尤其是涉及权限或边界条件时，GPT经常假装懂了但写出来的逻辑是断的。我的经验是把“动态SQL拼接”这类需求拆成“先写纯校验函数”+“再写拼接模板”，每个子任务单独测一下，最后让GPT组装，比一次扔过去稳定不少。另外，你提到的用单元测试反推挺靠谱，我试过先写几个pytest用例让模型补全实现，出错率直接降一半。

试试把动态拼接拆成纯函数+测试用例喂给模型，比堆prompt更稳。

你的情况我也遇到过，感觉GPT在处理复杂逻辑时更像在“猜”而不是真的理解，尤其是权限校验和边界条件这些细节，它容易忽略。我试过把需求拆成更小的函数，每个函数单独让GPT写，最后自己手工组装，效果比一次性让它生成完整逻辑好不少。另外用单元测试反向约束其实是个好思路，先写测试让它跑，再修代码，我最近这么搞，翻车率降了很多。

你这情况我太熟了，复杂逻辑翻车基本是模型把“局部正确”当成了“全局正确”。我试过把每个边界条件写成独立prompt让GPT逐个生成，最后再人工拼装，虽然麻烦但比一次输出靠谱。另外可以试试让它在代码里直接加断言和单元测试模板，跑一遍报错再反馈给它修正，比自己硬拆需求省心很多。

说实话你这经历我太熟了，之前做个多租户权限过滤的逻辑，GPT给的代码跑了三次崩了两次，后来发现它特别喜欢假设输入都是完美合法的。我觉得核心问题在于LLM对“边界条件”的敏感度天生弱——你拆解任务、加few-shot确实有用，但本质上它还是在模仿训练数据里的常见模式，而复杂逻辑恰恰是那些少见但致命的组合。我现在的做法是反过来：先让GPT生成最“天真”的版本，然后用我自己写的单元测试脚本去跑，把报错信息再喂回给它让它自己修，反复迭代个三四次效果比一次性prompt强很多。另外可以试试在prompt里明确要求它输出“异常处理版本”和“乐观版本”两个选项，对比着看逻辑漏洞会更明显。不过话说回来，对于动态SQL拼接这种安全敏感场景，我最后其实还是自己手写了核心校验部分，只让GPT负责模板生成和注释补充——人机协作的边界得划清楚，不能全甩锅给它。

这种复杂逻辑翻车太正常了，GPT本质上是在做模式匹配，多层嵌套和边界条件恰恰是它最薄弱的环节。我自己的经验是别指望它一步到位，先让它生成一个能跑的骨架，然后专门针对边缘case写单元测试喂给它修bug，效果比堆prompt稳定得多。另外动态SQL这种敏感操作，我最后都改成手动写模板+参数化查询了，毕竟安全性和正确性不能完全交给模型赌运气。

同感，复杂逻辑上翻车太常见了，尤其是边界条件，感觉GPT对“动态”和“组合”场景的理解还是偏弱。我自己试过把few-shot示例改成反例（故意给个有bug的版本让它修），效果比直接给正确代码好一些。另外，如果你愿意多花点时间，把需求写成伪代码或者画出逻辑流程图再喂给它，准确率会明显提升。

同感，复杂逻辑翻车太常见了。我觉得问题可能出在GPT对“动态字段映射”这类隐含业务规则的理解上，它容易忽略边界情况。我试过把权限校验写成独立函数，然后在主prompt里明确说“先调用check_permission再组装SQL”，效果稍微好点。不过最稳的还是配合单元测试，让模型先写测试用例再写代码，起码能提前筛掉空列表报错这类低级问题。

试试先把复杂逻辑拆成小函数单独让GPT写，再手动组合，比让它一口气生成靠谱得多。

把复杂逻辑拆成小函数再让GPT逐段写，配合单元测试反推比全靠prompt靠谱多了。

同感，复杂逻辑上GPT确实容易“想当然”，尤其是动态SQL这种涉及安全性的场景，它经常忽略边界条件。我试过把需求拆成更细的伪代码步骤，再让GPT逐段生成，比一次性给完整prompt稳一些。另外，你也可以试试先让它写单元测试用例，再根据测试补代码，这样逻辑漏洞会少很多。

你说的这个情况我太有同感了，复杂逻辑翻车基本是常态。我自己试下来，觉得问题核心在于GPT对“状态”和“边界”的理解特别容易断片，比如多层嵌套时的变量作用域、空值传播这些，它经常按直觉写但忽略实际执行路径。我最近实验了一个方法：不在prompt里写完整需求，而是先给它一个极简的骨架代码，然后逐行用注释写“规则约束”，比如“这里必须检查list是否为None，否则跳过”，它生成的代码准确率明显高一些。另外，你提到用单元测试反推我觉得很靠谱，我现在会先生成一个带占位符的测试文件，让GPT根据测试用例来补全函数体，相当于用测试驱动它思考边界条件。不过遇到特别复杂的动态映射，我最终还是得手写核心逻辑，把GPT当补全工具用。你试过给GPT提供具体的错误日志或异常堆栈吗？我觉得这比纯语言描述效果更好。

老实说我最近也卡在这个点上，感觉GPT对“边界情况”的理解特别飘忽，尤其在动态逻辑组合时容易漏掉防御性代码。你提到的拆任务和few-shot我都试过，不过我发现把“预期输出样例”写成表格形式反而更稳，比如直接给它几个输入输出对，让它反推逻辑框架。另外就是配合pytest跑一轮边界测试，把报错信息喂回去迭代修正，比单靠prompt调教省心不少。

深有同感，复杂逻辑翻车太常见了。我试过把prompt写成伪代码级别的逻辑链路，比如明确标出每个分支的输入输出和边界处理，效果比纯文字描述好一丢丢，但遇上动态字段映射还是容易崩。你提的单元测试反推思路挺有意思，我最近在试先让模型写测试用例再补实现，虽然慢但至少能卡住低级错误。有没有试过用结构化输出格式，比如强制它返回JSON定义好每个条件分支的优先级，这样逻辑漏掉时一眼能看出来？

确实，复杂逻辑光靠prompt硬调容易翻车，我后来是让GPT先生成伪代码框架，再手动补细节。

确实，复杂逻辑还是得靠人拆解，我试过把边界条件写成测试用例喂给它，效果比单纯加prompt稳多了。

这种情况我也经常遇到，特别是涉及动态逻辑的时候，GPT容易把上下文里隐含的边界条件忽略掉。我的经验是别指望它一次写对，不如把核心逻辑写成伪代码或者注释，让它按步骤填充，同时明确告诉它“处理None和空列表时要做什么”。另外可以试试先让它生成单元测试用例，再根据测试来反推代码，这样翻车概率会低不少。