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

给输入输出例子最管用，再让它把异常路径写进注释里，基本能避开八成坑。

我个人是把“考虑边界情况”这种抽象指令直接换成具体例子，比如在prompt里塞一个带中文路径和空值的CSV片段，让它按这个输入写代码，效果比笼统描述好很多。让它自己跑一遍再返回这个思路我觉得可行，就是得提醒它别光看能跑通，还得主动打印几个关键变量的类型和值，不然它自己也会被假象骗过去。另外有个小技巧，让它先写处理主流程的伪代码，再单独列一个“可能出错点”清单，最后合起来生成，翻车概率会低不少。你试过给模型提供那种带陷阱的最小复现文件吗？

我一般会把约束条件写成类似接口文档那种，比如“函数接收str路径，可能含中文，返回DataFrame，空值填0”，再给一两个输入输出例子，比单纯说“考虑边界”稳很多。让模型自己跑一遍不现实，它没法真执行，但你可以让它先输出测试用例，你再拿这些用例去验。还有个偷懒办法，把容易翻车的路径、编码、异常处理写成固定模板塞进prompt，让它填逻辑而不是自由发挥。

这个问题我太有同感了，让模型写业务代码最怕的就是它一本正经地胡说八道。我的经验是光在prompt里写“考虑边界情况”基本没用，得把边界条件具体化成它不得不处理的约束。比如读CSV那个例子，我会直接告诉它“文件可能没有表头，路径可能包含中文和空格，空值用空字符串或NaN表示”，相当于把踩过的坑提前写进需求里。另一个挺管用的做法是给一个最小输入输出示例，让它先按这个例子对齐格式，再让它泛化，这样它跑偏的概率会低不少。至于“让它自己先跑一遍”，思路是对的，但得看工具链，像ChatGPT的代码解释器确实能执行，可它执行成功不代表在你本地环境能跑通，依赖版本和文件系统差异它根本感知不到。我现在更倾向于让它写代码的同时附带pytest测试用例，把异常路径也覆盖进去，这样它自己就得先想清楚各种失败场景。还有个细节是别让它一次写太长，拆成小函数逐个确认，比一口气生成两百行再debug高效多了。

我一般不会指望它一次写对，更像是让它先给我一个能跑的骨架，然后我自己把那些容易翻车的点一个个补进去。你提到的路径和编码问题，其实最好在prompt里直接给约束，比如“假设输入路径可能包含中文，用pathlib而不是字符串拼接”“读取CSV时不要假设有表头，显式传header=None或让用户指定”。这种具体规则比“考虑边界情况”有用得多，因为后者太抽象，模型根本不知道你关心哪一类边界。另外给它一两个输入输出示例确实能稳住不少，尤其是异常处理那块，你可以直接说“如果文件不存在就抛FileNotFoundError并打印友好提示，不要静默返回None”。至于让它自己跑一遍再返回代码，想法挺好但实际不太行，除非你给它配了执行环境，否则它只是“假装跑过”，反而更容易编出看似合理的错误。我自己的做法是把常见坑写成一个小checklist塞进系统提示里，每次生成后自己再扫一眼路径、编码、空值、异常这四样，时间久了就形成条件反射了。

我一般会先让它列异常再写代码，或者直接给两三个输入输出例子，比干说“考虑边界”管用。

我一般是把边界条件直接写进Prompt里，比如“路径可能含中文、文件可能没表头、空值可能出现在任意列”，比笼统说“考虑边界情况”管用多了。另外给一两个输入输出示例特别有效，模型能照着格式走。让它自己跑一遍不太现实，它没法真正执行，但你可以让它先输出测试用例，你再手动跑一遍验证。

我一般会先给个极简的输入输出样例，再让它把异常分支单独列出来，比直接说“考虑边界”管用多了。中文路径、空表头这种坑，最好在prompt里写成明确的约束条件，比如“必须用utf-8-sig，且用try包住文件读取”。至于让它自己跑一遍，我试过用code interpreter，确实能筛掉不少低级错误，但别指望它主动想到你没提的边界。

这个坑我踩过太多次了，本质上是模型在“语法正确”和“语义正确”之间有个巨大的鸿沟，它默认你给的场景是最理想的情况。你提到的CSV表头和中文路径，其实都是典型的隐式上下文缺失，光靠“请考虑边界情况”这种泛泛的指令，模型根本不知道边界在哪。我后来学乖了，与其列异常清单，不如直接给它一个具体的输入输出示例，比如“输入是路径含中文、首行无表头、有空字符串的CSV，输出是清洗后的DataFrame”，这样它反而能推演出其他类似情况。至于让它自己跑一遍再返回，思路可行但别指望它真跑，它只是在脑子里模拟，遇到需要实际文件系统的操作照样抓瞎。我现在会在Prompt里把异常处理拆成框架步骤，比如“先检查路径是否存在，再尝试用utf-8和gbk两种编码读，最后dropna前先判断列类型”，这样它至少不会瞎编。不过说实话，最稳的办法还是自己写测试用例，然后拿报错信息去追问它，比一次性生成靠谱多了。

我也踩过这个坑，后来发现光加一句“考虑边界情况”基本没用，模型不知道你具体怕什么。我的做法是把IO示例和已知坑直接塞进prompt，比如“路径可能含中文，用pathlib并显式指定encoding=utf-8”，命中率会高不少。至于让它自己跑一遍，思路可行但得给它执行环境，不然它只是“脑补”运行结果，反而更自信地胡说。

给几个典型输入输出示例比说“考虑边界”管用多了，模型照着例子补逻辑稳不少。

这个问题我太有共鸣了，之前让模型写个批量重命名脚本，它连os.path.join都懒得用，直接字符串拼接路径，Windows上跑直接爆炸。后来我发现关键不在于“提醒它考虑边界”，而是把边界变成它必须满足的硬约束。比如我会在prompt里直接写“输入路径可能包含中文和空格，必须用pathlib处理；CSV可能没有表头，用csv.reader加手动判断；空值统一替换为None”，这样它就不太容易自由发挥。另外给一两个具体的输入输出示例确实有用，尤其是异常情况下的期望行为，比单纯说“考虑异常”强得多。至于让它自己跑一遍再返回，思路可行但别指望太多，它没法真正执行环境里的代码，所谓的“自检”经常是假装跑通了。我现在的习惯是让它生成代码的同时附带一个pytest风格的测试用例，哪怕测试本身也需要我改，但至少能逼它把边界条件显式写出来。还有个小技巧，把大脚本拆成几个小函数分别生成，每个函数单独指定异常处理策略，比一次性要一个完整脚本稳定得多。