用Prompt让GPT写Python代码，总在边界情况翻车怎么办？

与其反复调prompt，不如直接让GPT先输出测试用例，把边界情况列全了再让它写代码。

把“不递归”写进函数名里，比如rename_files_no_recursive，比在描述里强调管用。

与其死磕prompt，不如直接给GPT喂几个带坑的测试用例，让它对着改代码更高效。

说实话这情况太常见了，GPT写代码属于“理想丰满现实骨感”，边界情况全靠你喂例子。建议别光改Prompt，直接把“不递归”这种硬性要求写进函数签名里，比如加个参数默认False，比让它自己理解强多了。另外特殊字符报错，大概率是没做编码处理，你可以在Prompt里给个具体的异常类型清单，比如UnicodeDecodeError，它就能更聚焦。我一般会让GPT先输出伪代码或者步骤列表，确认逻辑没漏再让它生成完整实现，能省不少改bug的功夫。

说实话我觉得这事儿吧，prompt写得再细也挡不住GPT对“文件”和“目录”的抽象理解有偏差，它本质是在做概率预测，不是真的懂文件系统。你越强调“不递归”，它反而可能觉得你在暗示有递归风险，然后自作主张加个保护逻辑，结果又引入新问题。我现在遇到这种边界情况，干脆让它先写一版能跑通的，然后我自己把边界条件列成测试用例往里面砸，砸一个修一个，比反复改prompt快多了。另外你可以试试让它输出伪代码或者分步骤的函数骨架，不直接给完整实现，这样你控制逻辑结构，它只填具体操作，翻车率会低不少。还有个小技巧，让它把特殊字符处理写成独立函数，明确告诉它调用这个函数而不是自己发挥，效果会稳一些。说到底，这类工具适合搭框架，细节还得自己兜底，别指望一次生成就完美。

说实话我也踩过类似的坑，后来学乖了：与其反复强调“不递归”，不如直接在prompt里给它一个反面示例，比如“如果当前目录里有子文件夹，请跳过它而不是进入”。另外像特殊字符这种，我一般会明确要求“用os.path.basename处理”或者“先做一次合法性替换”，比让GPT自己发挥稳得多。

其实你发现问题没，GPT写代码更像“按关键词猜需求”，它默认你提了路径就想到递归，提了冲突就想到覆盖，所以不如把边界情况全写成if判断直接塞给它。我现在的做法是，让它先输出伪代码逻辑，我确认没问题再让它生成完整函数，虽然多一步但省得来回改。

还有个笨办法，就是让它给每个操作加assert，比如“确保目标文件不存在再重命名”，这样就算它漏了，跑起来也会立刻报错而不是静默改坏。你试试把需求拆成“输入→处理→输出”三个显式步骤，每个步骤给一个具体例子，比写十行描述管用。

说实话你这情况太典型了，GPT写代码最怕的就是“默认脑补”你没提的需求，比如递归。我后来学乖了，直接让它“显式列出所有假设条件”，甚至让它先写个伪代码确认逻辑再输出正式版，比反复改prompt省事多了。

另外边界情况这玩意，其实你可以在prompt里加一句“请用防御性编程，对所有未知输入做异常处理”，再让它把每个分支都配上注释，这样至少报错时你能快速定位是哪儿崩的。不过说真的，指望它一次性完美不太现实，我现在基本把它当高级自动补全用，复杂逻辑还是自己搭框架，它填肉，这样反而效率最高。

说实话你遇到的这个情况太典型了，GPT写代码最怕的就是“你以为说清楚了，但它理解成另一套”。我一般会让它先输出伪代码或者处理逻辑，确认无误后再让它生成完整函数，这样能提前拦住递归这种坑。另外你可以试试把边界情况直接写进测试用例里，比如让GPT先跑一个包含特殊文件名和子目录的模拟列表，再让它根据测试结果改代码，比反复改Prompt省心多了。

说实话这问题我太有同感了，GPT写代码就像个听话但没常识的实习生，你越强调“不递归”它反而越容易在判断条件上犯轴。我现在的做法是直接把目录结构样例和预期输出贴进prompt，让它照着具体例子写，比抽象描述稳很多。另外特殊字符报错建议你干脆让它用pathlib代替os.path，能省掉一大半坑。

直接让它输出完整代码再跑测试用例，边界情况自己补个try就完事了。

别指望GPT一次写对，直接把边界条件写进测试用例喂给它，让它跑完再改。

试试让GPT先列测试用例再写代码，边界情况自己补全比靠prompt硬约束靠谱。

与其反复调prompt，不如把特殊字符和子目录这些case直接写进函数docstring里，模型抓重点会准很多。

说实话这问题太典型了，我一开始也跟你一样，拼命在prompt里加各种限制词，结果发现GPT对“不递归”这种否定指令的理解其实挺飘的，它更擅长按正面描述来执行任务。后来我换了个思路，直接在prompt里给一个明确的文件列表作为输入示例，比如写上“假设目录下只有a.txt和b.txt两个文件”，再让它基于这个具体场景写逻辑，边界情况反而少了很多。另外，你提到的特殊字符报错，其实可以在prompt里让它“用pathlib替代os.path”，这招对Windows路径和特殊字符特别管用，基本能省掉一半手动修bug的时间。还有个土办法，就是让它先写一个只打印操作日志的dry-run版本，你跑一遍看它到底打算碰哪些文件，确认没问题了再让它加上实际重命名动作。说到底，GPT写代码更像是个快速原型工具，指望它一次完美不现实，但把“验证”步骤嵌进你的工作流里，比反复调prompt效率高多了。

同感，GPT写这种有明确边界的脚本时，最容易在隐式默认上翻车。我现在都会在Prompt里直接让它“把函数体写完整，任何未明确说明的情况都返回错误提示”，而不是靠自然语言去堵漏洞。另外，你试试把“不递归”改成“只使用os.listdir而不是os.walk”，这种具体到API层面的约束比形容词管用得多。特殊字符报错的话，干脆让它统一用utf-8加errors='ignore'，别指望它自己想到。

说实话我觉得这问题不在Prompt写得够不够细，而是GPT对“边界情况”的理解本质上是概率性的，它很难像人一样把“不递归”这种约束贯彻到每个分支逻辑里。我的做法是让它只生成核心函数骨架，然后我手动补上文件类型判断和异常处理，或者直接让它写单元测试用例来反推边界。另外你可以试试在Prompt里给一个具体的目录树示例，让它基于这个结构输出代码，比抽象描述要稳得多。

这题我太有同感了，GPT写脚本就是“表面稳如老狗，细节翻车小丑”。后来我学乖了，干脆在Prompt里直接要求它“输出完整代码，所有文件操作前必须打日志”，再配合自己写个临时目录做测试。特殊字符报错那个，多半是编码问题，你试试让它强制用pathlib而不是os.path，能少踩一半坑。

说实话我觉得这问题的根源不在prompt，而是GPT写代码时对边界情况的理解永远停留在“它见过的数据”上，你描述得再细它也只是在猜。我现在遇到这种场景就直接给它一个测试用例集，让它先跑一遍，看到报错再针对性改，比反复描述需求高效多了。另外文件名特殊字符这种坑，建议你干脆在prompt里把“用os.path.basename处理路径”和“用正则过滤非法字符”写成硬性要求，而不是让它自由发挥。你试试把需求拆成几个小函数让GPT分别写，最后自己拼装，稳定性会好很多。

说实话我跟你遇到过一模一样的问题，后来我干脆不跟它纠结边界情况了，直接让它输出代码框架和主逻辑，那些特殊字符、递归这些坑我自己写个if判断兜底。另一个思路是把所有约束写成一条条checklist塞进prompt结尾，比如“仅遍历当前目录、跳过隐藏文件、用os.path.basename处理特殊字符”，比上下文里长篇大论好用很多。不过说到底，LLM写脚本当个加速器行，真要处理生产数据还是得自己过一遍代码，尤其是文件操作这种毁起来没后悔药的场景。

我最近也遇到过类似情况，后来发现与其反复强调“不递归”，不如直接在prompt里让它“用os.scandir()且不进入子目录”，或者干脆给它一个明确的伪代码框架让它照着填。GPT对约束条件的理解其实挺飘忽的，尤其是那种否定性的指令，它容易在生成过程中“遗忘”。另外特殊字符报错那个，建议你在prompt里直接写“处理前用try包裹并跳过所有异常文件”，这样比让它自己判断靠谱得多。说到底它就是个高级补全工具，边界情况还是得靠你给它画好边界，别指望它自己悟出来。

说实话，这问题我也踩过不少坑，GPT写代码还是更适合当快速原型工具，边界情况得靠自己补。我的做法是让它把函数拆成几个小步骤，每步只干一件事，再加上类型注解和docstring，这样即使它漏了，我一眼也能看出来哪里该补。另外你试试在Prompt里直接给个“反例”，明确告诉它“如果目标是子目录就跳过”，比单纯说“不递归”管用得多。特殊字符报错那个，多半是编码问题，建议你直接要求它用pathlib而不是os.path，能省好多事。

换个思路让GPT先列测试用例再写代码，边界情况让它自己补全，比反复改prompt省心多了。