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

别指望GPT一次写对，把边界情况全写进测试用例里喂给它，比改prompt管用多了。

说实话这情况太常见了，GPT写代码就是“看着对但经不起细看”，尤其边界条件它默认按“最理想情况”处理。我现在的做法是让它先输出伪代码或步骤清单，确认逻辑后再让它写具体实现，这样至少能提前发现它理解偏差在哪。另外你那个递归问题，与其反复强调“不递归”，不如直接给它一个反例输入，比如带子目录的测试路径，让它跑一遍看输出，比文字描述管用得多。特殊字符报错的话，建议你直接在Prompt里让它用pathlib代替os.path，这个库天然处理了很多坑。

别指望一次生成，把边界情况拆成小函数让GPT逐个写，最后再组装，容错率高很多。

说实话这问题太典型了，我甚至怀疑咱俩用的是同一个GPT。你Prompt写得再细，它本质上还是在做模式匹配，不是真的理解“递归”和“非递归”的语义边界。我后来学乖了，凡是这类文件操作，干脆把os.listdir和os.scandir的选择直接写死在Prompt里，甚至让它生成代码后必须附带一个测试用例，专门跑一遍带子目录的文件夹，不然就默认代码不合格。另外特殊字符报错那个，你得在Prompt里点名道姓说“用pathlib的Path对象处理，别用字符串拼接”，这家伙对字符串操作有迷之自信，你越抽象它越自由发挥。还有一个偏方，就是让它先写一个伪代码框架，你审核通过再让它填实现，相当于把思考过程拆出来，比直接要成品稳定得多。当然，真遇到特别复杂的边界，我最后都自己动手改了，毕竟指望它全对不如指望自己review快。

别指望一次生成完美代码，把边界情况直接写进测试用例喂给它，比加prompt管用。

说实话我觉得这事儿不能全怪prompt，GPT写代码本质是在做模式匹配，边缘情况它根本“看不见”，你描述得再细它也只是在猜。我的经验是让它先输出伪代码或者让它在关键分支上自己列测试用例，比反复强调“不递归”有用得多。另外特殊字符报错这种，你不如直接让它用pathlib的glob配合显式过滤，代码逻辑比语言描述更可靠。

说实话这种问题我碰到过太多次了，GPT写代码确实容易在边界条件上“想当然”，尤其是递归这种它默认觉得你可能需要的东西。我现在的做法是，prompt里直接给它一个完整的测试用例清单，包括空文件夹、特殊字符、子目录这些，让它先跑一遍再交付代码，比自己反复描述规则管用得多。另外你也可以试试把需求拆成更小的函数，比如先让它写一个单文件重命名函数，再单独处理遍历逻辑，这样出错时定位也快，改起来不心疼。

与其反复调prompt，不如直接让它先写伪代码再转实现，边界情况自己兜底更快。

说实话这问题我太有共鸣了，GPT写代码最大的坑就是“你以为是需求没写清，其实是它压根没有边界感”。我现在的做法是直接给它喂一个具体的失败用例，比如“如果文件夹里有个叫test(1).txt的文件，你要怎么跳过”，让它基于这个反例去改代码，比单纯加“不递归”这种描述有效得多。另外你提到的特殊字符报错，我怀疑是编码问题，建议你在Prompt里明确加上“用pathlib处理路径”和“open时指定encoding”，这俩能干掉一大半玄学bug。还有个偏方，就是让它先写一个只处理单层目录的最小版本，跑通了再让它加异常处理，别一上来就求全。说到底，GPT写脚本适合搭骨架，边界情况还是得靠咱们自己拿测试数据去砸，毕竟它没见过你真实的文件系统长啥样。

这题我太有同感了，GPT写脚本就是那种“看着对，跑起来漏”的状态。我后来基本放弃在prompt里反复强调边界，改成让它输出代码前先自己列一遍可能的异常场景，再对应写处理逻辑，效果比单纯加“不递归”要好。另外你那个特殊字符报错，建议直接让它用pathlib替代os.path，很多坑能自动避开，你可以试试。

说实话这情况太典型了，GPT写代码就是“看起来对，边界就翻车”。我现在的习惯是让它只生成核心逻辑，文件遍历和异常处理全自己写，或者用pytest把边界情况列成测试用例直接怼给它，让它按测试来改。另外你可以试试在prompt里明确禁止使用os.walk这种递归API，直接指定用os.listdir，效果立竿见影。

这问题太真实了，GPT写代码最大的坑就是“你以为它懂了，其实它只记住了你最后那句强调”。我的经验是别指望它一次性生成完整逻辑，不如把边界情况拆成单独的小函数让它逐个写，比如先写“判断是否文件”再写“处理特殊字符”，最后你手动拼装，反而比无限改Prompt省心。

另外可以试试在Prompt里直接塞一个“反例”：明确告诉它“如果遇到子目录，跳过并打印警告”，比只说“不递归”有效得多。特殊字符报错那个，多半是编码问题，你让它统一用pathlib处理路径，别用字符串拼接，能少一半bug。

说真的，让AI写代码就像带实习生，你给再细的文档它也会自由发挥，关键还是得留个单元测试的坑位，让每次生成后自动跑一遍边界用例，比事后手动修高效多了。

我最近也踩过类似的坑，后来发现光靠堆Prompt真的治标不治本。GPT对“不递归”这种否定指令的理解其实很飘，尤其是你给了它一大段上下文，它反而容易把注意力放在路径处理这类“显眼”需求上，自动脑补出递归逻辑。我的经验是干脆把边界情况直接写成测试用例塞进Prompt里，比如明确给一个含子目录和特殊字符的示例路径，让它先跑通再输出代码，比单纯说“不要递归”管用得多。

另外你提到的特殊字符报错，其实本质是代码里没做编码处理，这属于GPT的“知识盲区”——它知道要异常捕获，但不会主动防Windows路径里的非法字符。我现在的做法是让GPT只输出核心逻辑，我自己在外面套一层防御性代码，比如用os.scandir而不是os.listdir，或者把文件名先做一次unicodedata规范化。这样就算它漏了细节，我也不用每次从零改。

还有个土办法，就是让它先写一个只处理单个文件的版本，确认无误后，再让它用循环包裹，而不是一步到位写完整函数。分段生成虽然慢点，但翻车率明显下降，你可以试试。

老实说，这种边界情况光靠堆Prompt很难根治，我一般会让GPT先画个函数骨架，把参数和返回值定义死，然后再让它填逻辑，递归这种就明确写“os.scandir只取文件”或者直接传一个“is_recursive=False”的开关进去。其实更稳的办法是让它生成代码后，你自己把边界测试用例丢给它跑一遍，比如构造一个带中文、空格和特殊字符的文件夹，让它自己发现bug再修，比来回改Prompt效率高多了。

换个思路，别让GPT自己写递归逻辑，直接让它按你的伪代码翻译，边界情况你提前列好它就不会乱来。

建议把需求拆成小函数让GPT逐个写，再自己拼装，边界情况单独写测试用例喂给它。

这题我太懂了，GPT写脚本就是容易在边界条件上搞“自由发挥”。我现在的做法是让它先输出伪代码或者步骤清单，确认逻辑没问题再让它生成完整代码，比直接改prompt省事多了。

另外强烈建议你在Prompt里明确写“禁止使用os.walk”或者“只允许os.listdir”，这种负面约束比“不递归”管用得多。特殊字符报错大概率是编码问题，直接让它用pathlib处理路径，顺手加个errors='ignore'参数，能少踩好多坑。

说实话这问题我太有共鸣了，最近我也在跟GPT死磕类似的需求，最后发现光靠堆Prompt真的治标不治本。你那个递归重命名子目录的坑我也踩过，后来我干脆在Prompt里直接让它“用os.scandir()而不是os.walk()”，并且明确要求“用is_dir()判断后跳过”，这样反而比反复强调“不递归”管用得多。另外我自己的经验是，像特殊字符、路径空格这种边界情况，不如直接让它调用pathlib库，Path对象天然处理这些比字符串拼接稳太多。更关键的一步是，我会让GPT在生成代码的同时，必须写出一组包含空目录、隐藏文件、超长文件名在内的测试用例，逼着它自己先跑一遍逻辑。如果它还是漏，那就别硬改Prompt了，直接把报错信息丢回给它让它修，比从头写要高效。说到底，LLM写代码更像是结对编程，你得把它当成一个容易忘事的实习生，用具体约束和单元测试去兜底，而不是期待一次生成就完美。

写得挺好，建议补充一些性能数据。

说实话这问题我也踩过不少坑，后来发现核心不在于Prompt写得有多细，而是你得把“边界情况”本身变成可执行的规则，比如直接告诉它“用os.scandir()而不是os.walk()”，或者“对文件名做try-except编码检测”，这样它就没法自由发挥了。另外我习惯让GPT先输出一个“边界情况清单”，列全它认为可能出问题的场景，再让它写代码，相当于逼它提前想清楚，比事后补丁靠谱。还有个土办法，就是让它把每个文件操作包在独立的函数里，加个参数叫recursive=False，默认关掉，这样就算它想递归也没门。特殊字符那个，你可以直接告诉它用pathlib的Path对象，别用字符串拼接，能省掉一堆转义问题。最后，别指望一次生成完美代码，我都是让它先给个能跑的版本，然后我把测试用例丢给它，让它自己跑一遍再修，这比手动改bug省心多了。