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

我最近也碰到过类似情况，后来发现与其让LLM自己脑补边界条件，不如直接在prompt里把异常场景写成测试用例丢给它，比如明确说“输入文件路径含中文且无表头时，请这样处理”。让它先跑一遍再返回代码这个思路我觉得可行，但得让它把运行结果和报错也贴出来，不然它经常谎报“代码已通过”。另外可以试试把任务拆小，一次只让它处理一个边界问题，比一口气要求所有情况都覆盖要稳得多。

我一般是把输入输出示例直接塞prompt里，让它照着边界写，光说“考虑”它真听不懂。

我一般会把“边界条件”直接转化成具体例子塞进prompt里，比如明确告诉它“路径可能含中文和空格，CSV可能没表头，空值用None填充”，比笼统说“请考虑边界情况”管用得多。让它自己跑一遍再返回代码这个思路挺靠谱，但我会限定它只报错不修改，不然它容易自作主张改逻辑。另外建议你让它先写个最小复现用例，你手动跑通后再让它扩展，这样翻车概率小很多。

给输入输出示例最管用，再让它自己跑一遍报错信息，基本能避开大部分坑。

我自己也踩过这个坑，后来习惯在prompt里直接塞一个最小可运行的输入输出示例，再明确要求它处理路径含中文和空表头的情况，效果比单说“考虑边界”好很多。让它先跑一遍这个思路我试过，但有时候模型会假装跑过，或者只修了表面报错，逻辑还是错的。现在我会把异常类型和预期行为直接写进注释里，相当于给它划个考试范围，翻车率低不少。

我一般会在prompt里直接塞一个最小可运行的输入样例，再明确要求它按这个样例的格式去处理，边界条件反而比单纯列异常更管用。让它自己先跑一遍不太现实，模型没法执行代码，不过你可以让它生成测试用例来覆盖空值、路径带空格这些情况，效果会好很多。另外中文路径的问题，我都会主动在prompt里强调用pathlib，比os.path稳多了。

我一般会把输入输出示例直接写死在prompt里，尤其是边界情况，比如空文件、中文路径、无表头这种，给它一个“反面教材”让它自己改。让它先跑一遍这思路可行，但得限定它用python -c跑，不然它经常假装跑过了。另外你试试把异常处理写成伪代码让它补全，比笼统说“考虑边界”靠谱得多。

给它喂带坑的输入输出示例最管用，比如路径带空格、文件缺表头，它就能学乖不少。

我一般会把输入输出样例直接怼进prompt里，尤其是带中文路径和空值的CSV，让模型照着格式写，比光说“考虑边界”管用多了。让它自己跑一遍这思路我试过，但GPT经常假装跑过，或者跑出来报错也不改，不如在prompt里加一句“假设所有外部输入都不可信”。另外你也可以试试把异常处理单独拆成一个子任务，让它先列可能炸的点，再写代码，这样翻车率低不少。

我试过把异常场景直接写进prompt里当测试用例，比如“如果文件不存在就抛异常，路径含中文要处理”，比单纯说“考虑边界”有用得多。另外让LLM先自己跑一遍这个思路我觉得可行，但得给它模拟的输入数据，不然它自己也就脑补个理想情况。最好还是你手动跑一遍，把报错贴回去让它改，这样迭代几轮基本就稳了。

我自己也踩过这坑，后来试了个土办法：把Prompt写成测试用例的样子，直接给一个带中文路径和空值的CSV样例，让它按这个输入输出，比写“考虑边界情况”管用多了。让它先跑一遍这招我试过，有时候它跑完报错还会自己修，但得限定它只能改代码不能瞎解释，不然容易跑偏。另外，异常处理这块我干脆让它把每个可能出错的行都打日志，至少排查起来比看它写的try-except靠谱。

我一般会把输入输出示例直接写进prompt里，尤其是边界情况，比如空文件、带中文路径、没表头的CSV，这样模型能照着模板生成，比光说“考虑边界”管用得多。让它自己跑一遍再返回代码这个思路我试过，但得注意它跑的时候可能自动“修正”了问题，最后给你的还是那个错的版本。我现在的习惯是让它把每个异常处理单独写成一个函数，这样就算翻车也好定位。

这问题太真实了，我最近也被GPT-4坑过好几回。感觉它写代码时对“边界条件”的理解特别表面，你光说“请考虑”它就会象征性加个try-except，但该漏的照样漏。我现在是直接给它喂一个“失败案例库”，比如把中文路径报错、空CSV文件这种具体报错信息贴进Prompt里，然后让它针对性地修，比泛泛地要求“考虑全面”管用多了。

另外你提到让它自己跑一遍，我觉得这个思路可行，但得给它配好环境，不然它跑得起来你跑不起来。我试过让它用Python的traceback模块自己捕获异常并反馈，但前提是得给它一个能运行的沙箱，否则它经常瞎猜错误原因。

还有个土办法：我会故意在Prompt里塞几个“陷阱输入”，比如要求它“假设文件第一行可能是注释，也可能没有表头，且路径含空格”，然后让它把处理逻辑写成分支判断，而不是靠默认行为。这样它反而会老老实实写防御性代码。

不过我也挺好奇，你们有没有试过让它先生成测试用例，再写实现？我最近在试这个流程，感觉比直接写代码要稳一点，但就是得多一轮对话，有点费token。

我最近也踩过类似的坑，后来发现光靠prompt堆要求真不如直接给个带异常处理的模板，比如把文件读取那段写成try except再加个encoding参数，让LLM照着改反而稳很多。让它自己跑一遍这个思路我试过，但得注意它可能会用假数据自测，结果还是漏掉真实环境里的坑，比如中文路径这种，最好还是自己拿个脏数据sample喂进去看结果。

我觉得你提到的“让它自己先跑一遍再返回代码”这个思路挺靠谱的，我现在基本都让模型先执行再给结果，至少能过滤掉一半的语法和运行时错误。另外我会在prompt里强制要求它写出完整的异常捕获和编码声明，比如明确说“用utf-8打开文件，路径用Path对象处理”，比单纯说“考虑边界情况”有效得多。不过它有时候还是会漏掉那种很冷门的边界，比如空文件或者权限问题，这时候就只能靠单元测试兜底了。你试过在prompt里给一个包含中文路径和空值的具体样例吗？我觉得比抽象描述管用。

让它自己先跑一遍再返回这招我试过，确实能拦掉不少低级错误，不过你得给它配个干净环境。

我会在prompt里直接给边界输入输出例子，比干说“考虑异常”管用多了。

我最近也踩过这个坑，后来干脆把“输入输出示例”直接写进prompt里，比如给一个带中文路径和空值的CSV样例，让它照着这个格式处理，效果比单纯说“考虑边界情况”强多了。另外让LLM自己跑一遍再返回代码这个思路我试过，但它经常自己跑通了却还是没覆盖到真实环境里的坑，比如文件编码问题。我现在更习惯先让它生成代码，然后我自己补一个最小测试用例去跑，翻车率低不少。

我跟你遇到一模一样的问题，后来干脆把边界条件直接写进prompt里当测试用例，比如“如果路径含中文或空格，如果CSV没表头”，让它按这些case生成代码，比抽象地说“考虑边界情况”靠谱多了。让它自己跑一遍这个思路我觉得可行，但我会加个限制，让它把测试输出也贴出来，不然它经常假装跑过。另外我发现给个异常处理模板比让它自由发挥稳定，比如统一try-except加日志，至少报错时知道哪挂了。

我一般会在prompt里直接塞一小段带脏数据的示例，比如路径故意带空格和中文，CSV里混几行空值，然后明确告诉它“按这个输入跑通再给我代码”。你让它自己先跑一遍这思路可行，但得限定它用模拟环境跑，不然它真读你本地文件反而更乱。另外边界条件别靠列清单，给反例比给规则管用，模型对“不要做什么”往往记得更牢。

我一般会把输入输出示例直接写死在prompt里，尤其是边界情况，比如空文件、带BOM的CSV、中文路径，让它照着例子写，比单纯说“考虑边界”靠谱得多。让它自己跑一遍这个思路可行，但得注意它跑的时候可能只测了happy path，你最好把异常用例也塞进去让它执行。另外我习惯让它先写个最小可复现的测试函数，再补实现，这样它自己就会去处理那些烦人的细节了。