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

这问题太真实了，边界条件就是LLM的盲区。我现在的做法是直接在prompt里把函数签名、输入输出示例和几个关键异常场景写死，比如“文件不存在怎么办”和“编码用utf-8”，比单纯说“考虑边界情况”管用得多。让它自己跑一遍这个思路我觉得可行，但最好在prompt里明确要求“先模拟执行并给出可能报错行”，不然它经常只做静态检查。另外，我试过让它写测试用例来反推代码，效果比直接要代码稳定，你可以试试。

我试过把异常情况直接写进prompt里当checklist，比如“文件可能不存在、路径可能含中文、CSV可能没表头、空值可能出现在任意列”，但说实话效果还是看运气，模型有时候会漏掉其中一两项。后来我改成给两三个具体的输入输出示例，包括一个带编码问题的路径和一份没有表头的CSV，它反而会自己推理出该处理哪些边界，比单纯列条件靠谱。你说的让它自己跑一遍再返回代码，我试过用“先执行并修正错误再输出最终版本”这样的指令，确实能减少低级错误，但代价是耗时变长，而且遇到环境依赖问题它照样懵。我觉得根本原因是LLM在生成代码时并没有真正“执行”的能力，它只是在模拟语法和常见模式，所以复杂场景下不如把任务拆小，比如让它只负责核心逻辑，文件读写和异常处理你自己写个包装函数。另外我会在prompt里加一句“假设用户在Windows系统，且文件路径包含空格”，这种具体环境约束比泛泛的“考虑边界”管用得多。

给它喂个带边界条件的输入输出示例比列一堆要求管用，我试过效果立竿见影。让它自己跑一遍不太靠谱，跑错了它也不知道咋改。

我一般是把边界条件直接写进prompt里当测试用例，比如明确告诉它“文件可能没表头，路径带中文，空值要保留”，再让它按这些case输出代码。让它自己跑一遍这个思路我试过，能抓掉一部分低级错误，但有时候它跑出来的结果本身就有问题，还得自己检查。最靠谱的还是多给几个输入输出示例，比单纯说“考虑边界情况”管用多了。

我最近也是被这个坑得不轻，后来干脆在prompt里直接塞一段“坏例子”，比如故意给它一个带中文路径和空值的CSV，让它按这个去写，效果比光说“注意边界”靠谱多了。让它自己跑一遍这个思路我觉得可行，但得提醒它用虚拟数据测试，不然真读到你硬盘上的文件，反而容易出幺蛾子。不过说实话，指望LLM一次写对不如自己留个心眼，把异常处理当模板背下来，我现在都是让它生成主干逻辑，细节自己补。

我一般会把异常场景直接写进prompt里的示例里，比如给一段带中文路径和空值的CSV，让它照着这个输入输出格式写，比单纯说“考虑边界”管用得多。让它自己跑一遍再返回代码这个思路我试过，但有时候它跑的是自己编的假数据，反而更迷惑，不如你本地给它一个最小复现用例。另外我习惯在最后加一句“如果输入不符合预期，请返回错误提示而不是猜测处理”，能减少不少瞎编逻辑。

我也有同感，边界条件这块儿真的是LLM的重灾区。我觉得光靠“请考虑边界情况”这种模糊指令没用，它压根不知道你指的“边界”是哪种。我现在会直接把那些最容易翻车的点写进Prompt里，比如“假设文件路径可能包含空格和中文”、“CSV可能没有表头，也可能有空行”，把异常当成正常输入来定义，效果比让它自己“思考”要稳得多。

另外你说的让它自己跑一遍再返回代码，我试过，思路可行但得加个限定——让它用虚拟数据跑，而不是真的去读你磁盘上的文件，不然它为了“跑通”可能会瞎造路径或者硬编码。还有个小技巧，我会在Prompt末尾加一句“如果某个步骤存在不确定性，请显式返回错误提示而不是猜测”，这样至少它能告诉你哪里没把握，而不是装懂。

不过话说回来，就算这样，碰到涉及编码格式（比如GBK和UTF-8混用）或者跨平台路径分隔符的问题，它照样会懵。所以我现在更倾向于让它生成“带防御性检查”的代码，比如开头就检查文件是否存在、编码能不能解码，而不是指望它一次写对。你试过给输入输出示例吗？我觉得给两个极端例子（一个最正常，一个最变态）比列所有异常情况管用，它模仿那个变态例子的处理逻辑时，反而更接近真实需求。

我一般是把输入输出示例直接写死在prompt里，包括边界情况，比如给个带中文路径和空值的CSV样本，这样模型能照着格式来而不是自己脑补。让它自己跑一遍这思路可行，但GPT-4经常假装跑过，所以我都是本地用脚本验证后再让它改，不然它还会嘴硬说代码没问题。你试试把“请考虑边界情况”换成“请先列出你假设的所有前置条件”，有时候能逼它暴露隐藏的默认值。

我一般会直接在prompt里把边界条件当成“需求”写进去，比如明确告诉它“路径可能含中文，文件可能没表头，空值用None填充”，然后给一个具体的输入输出示例，它基本就能老实执行。让它自己跑一遍这思路我试过，但LLM没法真执行代码，除非你接个解释器插件，不然它只会“假装”跑过，还是得靠你手动测试反馈给它错误信息再迭代。

我之前也踩过这坑，后来发现光喊“考虑边界”没用，得把具体场景喂给它。比如直接给一段带中文路径的CSV样例，再附上你期望的输出格式，它准确率明显高不少。让模型自己跑代码这思路我觉得可行，但别指望它真执行，让它“在脑子里跑一遍”然后输出修正版，比单纯生成靠谱点。另外你试试让它先列测试用例再写代码，等于逼它自己找漏洞，效果比事后补救强。

我自己的经验是，别指望它在prompt里一次想全所有边界，而是把“让它自己跑”当必选项而不是加分项——我现在写复杂点的脚本，都会在prompt里直接写“请生成代码后，用以下三组测试数据自己执行一遍，并把输出和可能报错贴出来”，这样它至少会暴露问题，而不是给你一个“看起来很对”的版本。另外你提到路径中文的情况，我习惯在prompt里给一个具体的反例，比如“假设路径是C:\用户\测试\文件.csv”，同时要求它用pathlib而不是字符串拼接，这比单纯说“考虑边界情况”有效得多。还有个小技巧，就是让它先写伪代码或分步骤列出所有假设（比如“假设有表头”“假设无空行”），再让它对着这些假设逐条写防御逻辑，这样比直接让它生成完整代码要稳。你试过让GPT先自己解释“这段代码可能在什么环境或数据下崩溃”吗？我觉得这比让它直接写更能逼它思考边界。至于输入输出示例，我一般给两个，一个正常带表头的CSV，一个完全空文件或者乱码文件，它往往能自己调整方案。反正别太信任它的“自觉”，多设计几个“坑”给它跳，反而比泛泛地要求“考虑全面”更有用。

给输入输出示例比列异常列表好用得多，我一般会直接塞一段带坑的测试数据进去，比如路径里带空格和中文，再让它按这个样例写。让它自己跑一遍这个思路可行，但别依赖它自检，它经常跑完说没问题，实际换个环境就崩，我都是拿个最小用例手动验一下。另外可以把边界条件写进函数docstring里，比在prompt里说“考虑边界”要稳定很多。