用Prompt写代码总在边界条件翻车，怎么让LLM稳定输出可运行代码？

我一般会把输入输出的具体示例直接写进prompt里，尤其带上一些脏数据，比如空行、带BOM的CSV、路径里有空格，这样它生成的代码会明显更稳。让它自己跑一遍这个思路我试过，可行但容易陷入死循环，不如引导它先写一个能处理最坏情况的骨架，再让你来补细节。另外建议把异常处理单独拆成一个子任务问，别跟主逻辑混在一起，效果比一句“考虑边界情况”靠谱多了。

我一般是把边界条件直接写进Prompt里，比如“假设路径可能含中文，文件可能没表头，空值要跳过”，然后顺手给它一个最小化的输入输出示例，比光说“考虑边界情况”管用得多。让它自己跑一遍再返回代码，这个思路我觉得可行，但得注意它可能会自己“脑补”环境，最好限定它用标准库或者明确指定依赖。另外，你试试让它先列几条它认为的边界条件再写代码，有时候比直接要代码更稳。

我自己也踩过这个坑，现在基本会把“输入输出示例”直接写进prompt里，尤其是带特殊字符或者中文路径的例子，比单纯说“考虑边界情况”管用得多。让它自己跑一遍再返回代码这个思路我觉得可行，但最好限定成“先静态检查再给结果”，不然模型可能只是把报错原样贴回来。另外你试试让它生成代码时同时输出几个测试用例，这样至少能逼它多想想异常分支。

这问题太真实了，我最近也被坑过。我的做法是直接在prompt里给一个最小可运行示例，然后把文件路径和编码格式写死进示例里，让它模仿那个骨架去扩展，比单纯说“考虑边界”管用得多。让它自己跑一遍这思路挺好，但记得提醒它打印出具体报错信息，不然它经常自己脑补一个成功结果回来。另外，中文路径那个坑，我都是额外加一句“用pathlib处理路径”，基本能避开。

我之前也踩过这个坑，后来发现光靠堆“注意边界”没用，LLM对抽象要求理解很飘。我的办法是直接给它一个带异常分支的最小可运行骨架，比如把try-except和文件编码写死在例子里，让它照着填空，这样比纯描述靠谱多了。至于让它自己跑一遍再返回，理论可行，但GPT-4经常假装跑过，你得在prompt里要求它输出实际执行结果和报错信息，不然它会编个假输出糊弄你。还有个土办法，就是让它生成代码后，你自己加个pytest用例集塞回去，问它“这测试能过吗”，逼它自查逻辑漏洞。

给输入输出示例最管用，再让它跑一遍验证，基本能避坑。

我都是把异常场景直接写成测试用例塞进prompt里，效果比光说“考虑边界”强多了。

给输入输出示例最管用，再让它写个测试用例自己跑一遍，比列一堆异常靠谱多了。

给输入输出示例最管用，再让它跑一遍再交代码，基本能避开八成坑。

我一般把异常情况直接写进prompt当测试用例，比说“考虑边界”强多了。

这问题太真实了，我最近也被搞到头疼。你提到的“看似合理但一跑就报错”我深有体会，尤其是文件路径和编码，它根本不按Windows的规矩来，中文路径直接炸。我现在的做法是，把边界情况拆成清单直接写进prompt，比如“假设路径含空格和中文，CSV可能没有表头，空值用NaN填充”，但这样其实很累，等于我自己先当了一遍测试工程师。

你问的“让它自己跑一遍”我也试过，思路没问题，但得给它明确指令，比如“代码生成后必须用以下测试用例执行，如果报错就修正再输出”，否则它经常返回一个“我验过了”但实际没跑的结果，因为模型会幻想执行结果。我觉得更稳的方式是给输入输出示例，尤其是异常输入对应的输出，这比抽象描述“考虑边界”管用得多。

另外我发现一个坑，就是它特别容易过度设计，比如你让它处理空值，它可能会引入pandas，明明用标准库几行就搞定了。所以我后来会限制“只能用标准库”，或者直接指定函数签名和返回值类型，把它的自由度卡死。不过说真的，这些细节堆多了，prompt都快赶上代码长了，我也在找更省力的方法，你有没有试过用例子驱动的方式，比如直接贴一个带脏数据的CSV片段让它处理？

我一般会把边界条件直接写进Prompt里当测试用例，比如“文件路径含中文”“CSV没有表头”这种，让模型照着例子输出，比单纯说“考虑边界”管用多了。让它自己跑一遍这个思路我觉得可行，但得注意它跑的时候也可能用虚构的环境，最好你本地再验一次。另外你可以试试让它先写个最小复现的伪代码，再让你填具体逻辑，这样反而容易暴露它默认的假设。

我自己的土办法是给一个“最小可跑示例”当锚点，比如让它先给个固定路径的版本，再让它改造成处理中文路径的版本，这样它至少不会默认所有环境都一样。让它自己跑一遍再返回这个思路我试过，但GPT经常报一个假错误然后自己修出另一个bug，还不如我把异常类型直接列在prompt里来的快。另外边界条件这东西，我干脆让它生成代码后强制要求加try-except和assert，比口头说“考虑边界”管用得多。

说实话你遇到的这个问题我太有同感了，尤其是文件路径和编码那部分，模型根本不会主动去猜系统环境里的坑。我现在的做法是，把“边界情况”从抽象要求变成具体例子，比如直接告诉它“输入文件可能是GBK编码且第一行有特殊字符”，或者给它一个带中文路径的绝对路径字符串，让它根据这个例子去写。你提的“让它自己先跑一遍”理论上可行，但我试过几次，它跑完还是会惯性忽略一些环境依赖问题，比如没有安装某库或者权限不足，而且反复让它执行会消耗不少token，性价比不高。更靠谱的办法其实是把代码拆成两段，第一段让它只写核心逻辑，第二段再专门问它“在这个函数里，如果列表为空、文件不存在、字段缺失，分别应该怎么处理”，这样模型会更容易聚焦到异常分支上。另外我发现一个技巧，让它先写出函数签名和类型注解，再填充实现，这样它至少不会把参数类型搞混。说到底，LLM写代码更像是一个“带资深的实习生”，你得把验收标准给它列成checklist，而不是指望它自己悟。你现在用的GPT-4是API还是网页版？如果是API，温度调低一点，比如0.2，可能也会减少这种“自由发挥”的概率。

给输入输出示例最管用，再逼它写个测试用例跑一遍，基本能避开大部分坑。

我会把异常场景直接写进prompt，比如“没表头、路径带中文”，比空泛的“考虑边界”靠谱多了。

给它喂个带坑的输入输出示例，比写十遍“考虑边界”管用，我试过这招挺稳的。

把异常场景直接写成测试用例丢给它，让它跑完再给代码，翻车率能降不少。

我之前也踩过这个坑，后来发现光喊“考虑边界”没用，得把具体场景塞进去，比如直接给它一个带中文路径和空值的CSV样例，让它照着这个输入写，准确率会高很多。让它自己跑代码这招我试过，但GPT经常假装跑过，或者报错后自己瞎改，不如你本地跑一遍把报错贴回去，来回两三次反而更稳。还有个小技巧，让它先列测试用例再写实现，相当于逼它把边界条件前置，这比事后补异常处理靠谱多了。

我一般会把输入输出示例直接写进prompt里，尤其是边界情况的样例，比如空文件或者带中文路径的，模型看到具体数据比抽象描述靠谱得多。让它自己跑一遍再返回这个思路我试过，但前提是你得给它一个能执行的环境，不然它只会“假装”跑过然后继续出错。另外，我会故意在prompt里加一句“如果遇到不确定的细节，默认抛异常而不是猜”，这样至少失败的时候报错清晰，调起来快。

给输入输出示例比列异常清单管用，再让它跑一遍测个最小用例，翻车率能降不少。

给输入输出示例最管用，再让它跑一遍验证，基本能避开大部分坑。

试试把异常场景直接写进prompt当测试用例，比空泛要求边界情况靠谱多了。

我一般会把“输入输出示例”直接写死在prompt里，尤其是文件路径和编码这种，给它一个带中文路径的样例，它基本就不会瞎默认了。边界条件全靠列的话太累，而且列多了它反而容易糊涂。让它自己跑一遍这个思路我试过，小脚本还行，但大一点的它经常跑完说“看起来没问题”，结果还是错，不如给它报错信息让它改。

给输入输出示例最管用，再让它用assert写几个测试用例，比单纯说“考虑边界”靠谱多了。