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

我跟你一模一样，后来发现与其在prompt里把所有边界条件都写全，不如直接把最典型的输入输出示例给它，尤其是带中文路径和空值的CSV，它照着模板改比凭空想靠谱多了。让它自己先跑一遍这思路我个人觉得挺可行，但得注意它跑的时候可能自己把异常吞了，所以说“跑完把报错信息原样贴出来”会更稳。另外我习惯在prompt最后加一句“如果某个边界情况你没把握，就在代码里用try-except包住并打印警告”，这样至少不会整个脚本崩掉。

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

我一般会把“边界条件”转化成具体的输入输出示例，比如直接给它一个带中文路径、空值、无表头的CSV样例，让它按这个样例输出结果，比光说“考虑边界”管用得多。让它自己跑一遍再返回代码这个思路我试过，但模型经常假装跑过，其实没执行，得靠你这边写个测试脚本去套它。还有就是分步骤来，先让它写核心逻辑，再单独补异常处理，别指望一次成型。倒是可以试试给它一个“最小可复现错误”的格式，逼它自己分析哪里会炸。

给输入输出示例最管用，把边界情况直接写成用例塞进去，比单纯说“注意边界”稳多了。

我一般会直接把边界条件写进prompt里当测试用例，比如明确告诉它“文件可能没表头”“路径带空格和中文”，再让它按这个输入输出示例来写。让它自己跑一遍这思路靠谱，但得注意它跑的可能是理想环境，真机上的权限和编码问题它不一定模拟得出来。另外我发现让GPT先解释一遍它打算怎么处理异常，再让它写代码，翻车率会低不少。

我一般会把输入输出示例直接写死在prompt里，尤其是带特殊字符或者中文路径的case，比单纯说“考虑边界”管用得多。另外让模型自己跑一遍这招我试过，它经常睁眼说瞎话，明明报错还跟我说运行成功，不如你本地跑完把报错贴回去让它改。还有个土办法，就是让它把文件操作拆成几步，每步单独输出，这样至少能定位到是哪块出了问题。

我自己的做法是直接把边界条件写进prompt里当测试用例，比如“输入一个空文件会怎样”或者“路径带空格”，让它按例子输出，比空泛地说“考虑边界”管用得多。让它自己跑一遍再返回代码我也试过，但有时候它跑成功了，换个环境照样崩，所以还得靠你手动补几个极端输入去验证。另外，文件编码和路径这种问题，我干脆在代码里强制用pathlib和utf-8，减少它自由发挥的空间。

我一般会把边界条件直接写进prompt里当测试用例，比如明确告诉它“输入可能包含空行和BOM头，输出要保留原始编码”，这样比笼统说“考虑边界”管用多了。让模型自己跑代码这个思路我试过，但有时候它跑完报错就改一版，改完又引入新问题，反而更费时间。现在我是让它先生成带assert的伪代码，我看了逻辑再让它补全细节，准确率会高一些。

我一般是把输入输出示例直接写死在prompt里，比如给它一个带中文路径和缺失值的csv样例，让它照着这个格式跑通再返回代码，比单纯说“考虑边界”有用得多。让它自己先跑一遍这个思路我试过，但GPT经常假装跑过然后给你个没验证的结果，还是得靠你这边给测试用例。另外可以试试让它把每个边界条件单独写成函数，再组合起来，这样出错时定位也快，不会一锅粥。

说实话我最近也在折腾这个，你提到的中文路径和CSV表头问题我全踩过坑。后来我总结了个土办法，就是把边界条件当成“需求文档”写进Prompt里，明确要求它列出所有假设，比如“默认文件存在吗？编码是utf-8还是gbk？空值是None还是字符串？”——得逼它把每个不确定点都问出来，而不是让它自己猜。你问的结构化写法我觉得靠谱，给输入输出示例特别管用，尤其是给一个带空值、带特殊字符路径的示例，它就能模仿那个模式。另外让它“自己先跑一遍”这个思路，我试过让它用Python解释器模拟执行逻辑，但对文件IO这种它没法真跑，只能靠逻辑推演，所以最好还是让它生成代码后，你自己拿个最小复现用例去测，把报错信息回喂给它让它修，比单纯加Prompt要稳。不过说实话，这些细节问题本质是它缺乏“环境感知”，我最近开始尝试让它在代码开头加一段防御性检查，比如断言文件存在、捕获编码异常，反而比让它一次写对更实用。

这问题太真实了，边界条件翻车基本是常态。我现在的做法是，干脆把“坏例子”直接塞进Prompt里，比如明确写“如果路径含中文，或者文件没有表头，请按XX处理”，比泛泛说“考虑边界情况”管用得多。另外，给输入输出示例确实很关键，尤其那种带异常输入的样例，模型能模仿的样式比抽象指令靠谱。至于让它自己跑一遍再返回代码——我试过，GPT-4有时候会假装“我运行过了没问题”，实际上它根本没执行，你得在Prompt里逼它“先把代码在本地模拟执行，如果报错就修正到无错为止”，但这也只能降低概率，不能完全消除。还有个坑是编码格式，我干脆在Prompt里写死“所有文件读写都用utf-8-sig，别用默认编码”，这样至少少一半事故。说到底，LLM写代码更像“高级自动补全”，别指望它真理解你的环境，你得把环境约束当成代码的一部分喂给它。我现在习惯是让它输出代码的同时，必须附带一段“可能失败点”的注释，这样我自己review起来也省力。

我一般会把“边界条件”直接写进代码示例里，比如给一个带空值和中文路径的CSV例子，再让它照着处理，比光说“考虑边界”管用多了。让LLM自己跑代码这思路我试过，但得给它配个能执行的环境，不然它只会“脑内运行”，照样漏掉编码问题。另外我习惯让它先输出伪代码逻辑，确认没坑再让它生成完整实现，这样翻车率低不少。

给输入输出示例最管用，再让它用try-except包一层，基本能避开八成坑。

给输入输出示例最管用，再让它用假设驱动写断言，比干喊边界情况强多了。

给几个带异常的输入输出示例比写一百句“注意边界”都管用，让它照着例子生成。

给输入输出示例最管用，再让它自己跑一遍报错信息贴回来，基本能避免八成翻车。

我最近也踩过这个坑，后来发现光靠prompt堆要求真不如直接给它喂个带边界条件的测试用例，比如路径带空格加中文、文件没表头这种，它就老实多了。让LLM自己跑代码这个思路我试过，但得给它明确说“模拟执行并告诉我哪行会报错”，不然它就是自信地瞎编。另外我习惯在prompt里加一句“假设用户是个新手，任何环境问题都要提前处理”，效果比单纯列异常列表稳很多。

给它喂带异常分支的输入输出示例比列需求管用，让它跑一遍再返回也行，就是费token。

这问题我太有共鸣了，边界条件简直就是LLM的盲区。我自己试下来，光说“考虑边界情况”基本等于没说，它只会象征性加个try-except，但根本不知道你实际运行环境有多脏。我现在倾向于把Prompt当成一个“验收标准”来写，比如直接给它“输入一个包含空值和BOM头的CSV，路径里有空格和中文”这种具体反例，让它必须处理完再给代码。另外你提到的“让它自己跑一遍”这个思路，我试过，有效但得看模型，GPT-4有时候会假装运行然后直接输出原代码，得在Prompt里明确要求它“把运行结果和报错信息贴出来”才能逼它真去执行。还有一个偏门但管用的办法，就是让它先写一个能跑的“最笨版本”，再逐步加复杂条件，每次只改一个点，这样它崩的概率会小很多。不过说到底，我觉得这种任务本质上是人机协作，LLM负责搭骨架，细节验证还是得靠自己的测试用例，别指望它一步到位。

我一般会把边界条件直接写进prompt里当测试用例，比如明确告诉它“输入可能是空文件”或者“路径带空格”，然后让它针对这些情况给出处理逻辑。你让它自己跑一遍那个思路我觉得可行，但得注意它跑的时候用的可能是它自己造的假数据，反而掩盖了真实环境的问题。我最近更习惯让它先输出伪代码或者关键步骤，我再填具体实现，这样翻车率低不少。