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

说实话我也有同感，GPT-4写那种“看起来对但一跑就炸”的代码太常见了。我现在的做法是让它先输出伪代码或逻辑流程图，确认分支覆盖没问题后再让它翻译成具体实现，效果比直接要代码稳不少。另外你提的“单元测试反推”我觉得挺靠谱，哪怕先手动写几个关键case喂给它，让它自己跑一遍再修，比干调prompt省心多了。

说实话我觉得这思路得换一下，LLM写复杂逻辑本来就不是强项，你拆任务加示例其实是在跟它的弱点硬刚。我自己试过，与其费劲调prompt，不如把边界条件直接写进函数签名或者用类型注解把输入约束死，让它没法自由发挥。另外你说的用单元测试反推挺靠谱，我一般让模型先出个初版，然后我写测试用例把报错喂回去，两三轮下来正确率能提不少。不过动态SQL这种最好还是手写个模板，让模型只填参数，别让它碰拼接逻辑。

说实话你这情况我太懂了，GPT写简单逻辑像开挂，一碰复杂分支就跟你玩“薛定谔的正确”。我后来干脆把关键函数拆成纯函数，让模型只填中间那段逻辑，测试用例先写好逼它照着补全，比给一堆prompt管用多了。

另外你试过让它先写伪代码再转实现不？我最近发现这个对嵌套条件和动态映射特别有效，相当于先逼它理清思路，再填细节，出错率能降一半。还有个小技巧，把边界情况直接写进prompt里，比如明确说“空列表返回None，None字段跳过”，它就不太会漏了。

不过说实话，真到了很复杂的场景，我建议直接上单元测试驱动，让模型跑循环修bug，比自己调prompt省心。你那个权限校验的问题，不如直接把不通过的情况列成几条规则喂给它，比说“要校验”具体多了。

说实话你这情况我太熟了，GPT写那种流水账代码确实顺手，一到状态机或者多层条件分支就露怯。我后来发现一个相对好用的路子，是让它在生成代码前先输出一段伪代码或者决策表，把每个权限组合对应的SQL分支列清楚，再让它照着翻译成Python，等于把逻辑推理压力从代码生成阶段提前转移了。另外你说的单元测试反推我也试过，但得自己先把测试用例写明白，等于逻辑还是你在兜底，对复杂场景帮助有限。真要稳定，我现在的做法是干脆把大模型当补全工具，自己画好框架和关键边界条件，只让它填空实现，这样至少不会漏校验。还有个细节，就是明确告诉它“不要省略对None和空列表的处理”，这种显式约束比“一步步思考”有用得多。不过说到底，这类多层动态映射的活儿，我越来越倾向于直接用SQLAlchemy之类的ORM手写，大模型反而更适合当个快速原型生成器。想知道你试过让它先输出所有可能输入的枚举组合再写代码吗？那个方法对有些场景挺灵的。

我最近也踩过类似的坑，后来发现把复杂逻辑拆成“输入-处理-输出”的管道式描述，比单纯堆few-shot管用。另外你提的用单元测试反推挺靠谱，我试过让模型先写测试用例再生成代码，bug率明显低了。不过动态SQL这种，感觉还是得靠约束模板，让模型只填参数映射部分，别让它自由发挥整个逻辑。

单元测试反推那思路靠谱，我试过让GPT先写测试用例再补实现，逻辑漏洞明显少多了。

说实话我跟你遇到的情况很像，GPT写简单逻辑行，一上复杂度就露馅。后来我干脆把权限校验和边界条件写成单独的函数模块，让GPT只负责拼SQL主体，再用pytest把空列表、None这种用例直接喂给它跑，跑挂了就把报错贴回去让它修，比单纯堆prompt靠谱得多。其实你可以试试给它一个“最小可用版本”的骨架，然后让它只填空，别让它自由发挥，成功率会高不少。

试试让GPT先写测试用例再写代码，拿测试当约束条件，比干调prompt稳多了。

试试让它先写测试用例再写实现，把边界条件当验收标准，比干调prompt靠谱多了。

试试让它先写测试用例再补实现，用红绿循环逼着逻辑闭环，比单纯堆prompt稳多了。

我最近也是这情况，后来改成把复杂逻辑拆成纯函数一个个喂，配点边界值例子，效果能好点。

试试让GPT先写测试用例再写实现，拿测试当约束条件，比堆提示词靠谱多了。

说实话你这个问题我太有同感了，GPT-4在那种“看似明确但隐含大量分支”的需求上，确实容易给你写出一个“跑通主路径但崩在角落”的版本。我自己试下来，感觉单纯堆prompt技巧边际效益很低，尤其是“一步步思考”这类，对代码生成反而容易让它更啰嗦地犯错。我现在的做法是干脆把函数签名、输入输出类型、错误处理规则直接写死在prompt里，比如明确告诉它“入参可能为None，必须提前返回空列表”，这样比让它自己推理边界条件靠谱得多。另外你提到用单元测试反推，这个思路我很支持，实测让模型先写测试用例再写实现，比直接写代码的准确率高不少，因为测试本身就是对行为的约束。不过我也遇到过测试写得太弱、模型正好绕过漏洞的情况，所以最好是测试里显式覆盖空值、异常分支这些关键case。还有个土办法，就是把复杂逻辑拆成两层，外层只做参数校验和调度，内层让模型写纯函数，这样就算内层翻车，外层也能兜底。说到底，这种场景可能真不是prompt能完全解决的，配合静态类型检查和代码走查会稳很多，不知道你有没有试过让模型先输出伪代码再加注释逐行翻译？

说实话这场景我太熟了，GPT在简单逻辑上像学霸，一碰复杂分支就露馅。我的经验是别让它直接写完整函数，而是把权限校验、边界处理这些“坑”拆成独立小函数，逐个生成再拼装，最后用assert写死几个边界case让它跑，不通过就继续反馈迭代。

另外你提到的单元测试反推思路我试过，确实比纯prompt更稳，尤其是配合pytest这种能自动跑的工具，等于让AI自己当裁判，比人眼review靠谱多了。但前提是测试你得自己先写清楚，不然它只会修到“测试通过”为止，逻辑漏洞可能还在。

还有个土办法：把动态SQL改成参数化查询，从根源上让GPT少发挥，毕竟它一自由发挥就容易在字符串拼接上放飞自我。系统性的策略我也没有，但感觉越是逻辑密集，越要逼它“小步快跑”，别指望一步到位。

说实话我更建议你换思路，用代码补全模型加单测来反推，毕竟GPT这类模型对“长链条逻辑”的跟踪能力确实很有限，prompt再怎么调也容易在中间某一步偷偷简化掉关键条件。我之前遇到过类似情况，把需求拆成小函数逐个生成，再手动粘起来，比让它一口气写完整逻辑靠谱很多。而且你那个动态SQL的例子，与其让它写全，不如让它只生成安全的where子句片段，权限校验自己写死，这样出错的概率会小很多。你也可以试试在prompt里明确要求它列出每个edge case的处理方式，但说实话，最后还是得靠测试兜底，别指望一次生成完美。

说实话你这情况我太懂了，GPT写简单逻辑像模像样，一上复杂度就原形毕露。我后来试了个土办法，把每个边界条件直接写成断言塞进prompt里，让它必须输出能通过断言的代码，比单纯说“注意空值”管用得多。另外你提的代码补全模型配单测思路我觉得靠谱，相当于让测试来当裁判，逼着模型迭代修bug，比指望它一次写对省心。

说实话你这情况我太熟了，GPT写简单脚本确实跟玩似的，一到复杂逻辑就原形毕露。我后来发现关键问题不是prompt写得不够细，而是它本质上在“猜”你的意图，不是真的在“推理”代码路径。你试的那些方法我都用过，拆子任务和few-shot有时候反而让它更混乱，因为上下文一长它就开始自己脑补规则。我现在比较有效的做法是让它先输出伪代码或者状态机描述，明确每一步的输入输出和异常分支，你再审一遍逻辑骨架，最后才让它填具体实现。另外你说的单元测试反推思路我觉得非常靠谱，我甚至试过故意在prompt里写“这段代码会被以下测试用例覆盖”，它生成的严谨度明显高一些，因为它在模拟执行过程。还有个小技巧，遇到None和空列表这类边界情况，我干脆在需求里直接指定“所有可能为空的参数都要先做guard clause”，比让它自由发挥稳定得多。不过说实话，逻辑密度特别高的场景，我最后还是自己手写了，AI生成的代码当参考或者补丁还行，当主力太耗时，你排查它逻辑漏洞的时间都够自己写两遍了。

说实话我也踩过这坑，GPT-4写那种纯逻辑链长的代码确实容易在边界条件上偷懒。我的经验是别指望它一次性给对，干脆把权限校验和空值处理单独拎出来写成固定模板，让模型只填核心逻辑，这样翻车率会低不少。另外你提到的用单元测试反推挺靠谱，我最近都是让它先生成测试用例再写实现，效果比单纯堆prompt稳定多了。不过动态SQL这种还是建议自己包一层白名单映射，模型根本搞不定哪些字段能查不能查。

别光靠prompt硬刚了，把生成的代码直接丢给单测跑一遍，报错再喂回去，比加提示词管用多了。

说实话我最近也踩过类似的坑，后来发现与其死磕prompt，不如把复杂逻辑拆成多个小函数，每个函数单独让GPT生成再自己拼装，这样出错率低很多。另外建议你直接在prompt里要求它输出时附带对边界条件的处理说明，能逼着它多想一步。至于单元测试反推这个思路，我觉得挺靠谱的，尤其对动态映射这种，先写测试用例再让它补全实现，比纯靠描述要稳。

我之前试过把权限校验规则直接写进few-shot示例里，效果比单纯说“要检查权限”好不少，但确实不稳定。后来我改用了一种办法：让GPT先画数据流或伪代码，确认逻辑没问题后再让它转成Python，相当于多了一层“审稿”。不过说实话，复杂逻辑还是建议你直接用静态类型+类型标注，配合mypy跑一遍，比靠prompt硬扛实在。

遇到过一样的问题，尤其是动态SQL拼接这种，GPT经常把参数化查询和字符串拼接搞混，挺头疼的。我现在的做法是给它一个“反例清单”，把空列表、None、权限缺失这些具体场景全列在prompt里，让它逐条说明怎么处理，效果比泛泛而谈好很多。另外你提到的单元测试反推，我试过一次，至少能保证输出可验证，但得自己写测试框架，成本不小。

单元测试反推这思路靠谱，让报错信息当你的调试器，比干调prompt省心多了。