用Prompt让AI写Python脚本，总是忽略错误处理怎么办？

说实话你这情况太常见了，我试过各种姿势调教，最后发现不是prompt写得不到位，而是LLM天生就倾向于输出“看起来正确”的代码，错误处理这种细节它默认你不需要。你说的few-shot确实比单纯描述要管用，我一般是给它两三个带完整try-except和超时设置的例子，再让它模仿着写，效果立竿见影。但有个坑是，任务一复杂它还是会漏，尤其多线程那部分，我甚至试过在prompt里明确写“每个线程函数内部必须单独捕获异常”，结果它给我把异常吞了连日志都不打。后来我干脆写了个自定义的代码审查prompt，让AI生成完代码后自己跑一遍“找茬模式”，专门列出一份清单检查有没有裸操作、有没有资源泄漏，虽然不能100%搞定，但至少能把80%的明显问题筛出来。另外我强烈建议你开个脚本做静态检查，比如用pylint或者ruff，比让AI自查靠谱多了，你只需要在prompt里要求它生成符合这些工具规范的代码，剩下的让工具用规则去怼它。说实话，手动review肯定是逃不掉的，但可以把review的精力集中在逻辑而不是低级错误上。

这问题我太有感触了，之前调一个批量重命名脚本也这样，prompt里把“健壮性”写了三遍，它照样在文件不存在时直接炸。后来我发现核心不是它不懂异常处理，而是它默认你在“写玩具代码”，不催它它就不当回事。我的土办法是直接在prompt里塞一个“错误处理清单”，比如“每个open必须配try/except，网络请求必须设timeout，循环里捕获异常要记录日志”，让它像checklist一样逐条对照，比单纯说“请健壮”管用太多了。至于few-shot，我觉得对简单任务有效，但复杂任务里给例子反而容易让它模仿结构而忽略全局。还有个偏门但好使的招：生成完代码后，你再发一句“请扮演资深代码审查员，找出所有未处理的异常路径和资源泄漏风险，列出修改建议”，让它自己当裁判，很多漏网之鱼就这么被揪出来了。手动review确实累，但至少看它自查后的版本，比从零检查轻松一半。你试过让它在代码里加类型注解吗？我发现一旦强制标注Optional和Union，它反而会主动考虑None分支，错误处理就跟着变严谨了。

few-shot塞两个带异常处理的例子，比写一百遍“要健壮”都管用，实测有效。

可以试试让它输出后自己跑一遍pylint或mypy，把报错丢回去让它改，比手动review省心点。

说实话，你这问题我太有同感了，GPT-4写脚本时对“健壮性”的理解特别表面，你提了异常处理它可能就加个try-except，但超时、重试、资源释放这些细节全靠你后续盯。我自己试过把错误处理直接写进系统级prompt，比如“每次open前必须判断文件存在，网络请求必须带timeout参数且捕获超时异常”，比笼统说“健壮”管用得多。但就算这样，任务一复杂比如多线程，它还是会漏掉锁释放或者线程池关闭，这感觉是模型本身的注意力局限，不是prompt能完全解决的。你提到的few-shot我试过，给两三个典型错误处理的例子确实有效，但前提是例子要贴近你的具体场景，否则模型容易生搬硬套。至于让AI自查，我现在的做法是生成后直接丢回给它，说“请检查这段代码的所有异常路径，列出遗漏点并修复”，有时候它真能自己找出几个坑，但别指望它能做到百分百，毕竟它对自己的输出没有“责任感”。说到底，我觉得工具是提速用的，最终质量还是得靠人肉review，不过你可以写个小的静态检查脚本，比如用pylint加自定义规则，自动扫一遍生成代码里的常见裸奔模式，能省不少力气。你有没有试过用多轮对话让它逐步补全错误处理，而不是一次性生成完整脚本？我最近发现这样效果会好一点，但就是费token。

这个我太有同感了，GPT-4对“健壮”的理解跟咱们完全不在一个维度，它觉得能跑通就算完。我后来是把异常处理直接写进系统提示词里，比如“每个函数必须用try包裹，网络请求必须加timeout参数”，效果比笼统的“健壮”好得多。还有个小技巧，生成完让它“用pylint或mypy检查这段代码并指出所有潜在异常点”，它真的会自己找毛病，比手动review省点力气。不过复杂任务还是别指望一步到位，我一般是让它先出骨架，再单独针对错误处理补一轮prompt。

这问题太真实了，我试过在prompt里加“请像处理生产事故一样对待错误”，结果它给我try了但except里就一个pass，等于没写。后来我发现光靠指令真不行，得把错误处理当成“数据”喂给它，比如直接给一个带完整try-except-else-finally的样例函数，让它照着那个骨架写，比用文字描述“健壮性”管用得多。另外你说让它自查，我试过在结尾加“请用代码审查者的视角指出这段代码的3个风险点”，有时候它会真的补上超时和重试逻辑，但偶尔也会瞎编，还得自己看一遍。我现在比较偷懒的做法是，让它生成后直接丢给pylint或mypy跑一遍，把报错截图塞回对话里让它改，比纯靠它自觉靠谱。不过多线程那个确实无解，它一碰共享状态就默认你有锁，其实根本没加，这块我基本放弃让AI独立完成了。

说实话你这情况我也踩过坑，单纯在prompt里写“要健壮”根本没用，模型对抽象指令的理解太表面了。我现在的做法是直接在需求里硬性规定“每个文件操作必须用with open加try except，网络请求必须设置timeout参数”，相当于把错误处理写进功能清单，效果比事后强调好很多。至于自查，可以让它生成完后自己跑一遍静态检查工具，比如让它用pylint或者mypy过一遍再输出，虽然不能全解决，但至少能拦住一部分低级问题。

我试过类似的情况，后来发现光在prompt里强调“健壮”没用，它压根不知道具体要防哪些坑。不如直接把错误处理的规则写进few-shot里，比如给个open文件加try的示例，再给个requests设超时的示例，模型一下就能get到你的标准。另外你可以试下让它生成后自己跑一遍静态检查，比如提示“用pylint查一下”，虽然不能全自动，但至少能逼它回头看看漏了啥。

说实话这问题太典型了，LLM本质是概率生成，prompt里写“健壮”它只会觉得是形容词，不会真去逐行检查。我的做法是直接在prompt里塞一段带try-except和超时设置的代码片段当样板，让它照着这个风格写，比单纯描述要求管用得多。另外你可以试试让它输出后自己跑一遍静态检查，比如在prompt里加一句“检查所有文件操作是否关闭了资源”，有时候能逼它多想想边界情况，但别指望完全省掉review，毕竟多线程竞态那类问题它还是看不太出来。

说实话这问题我也折腾过挺久，后来发现单纯在prompt里写“包含异常处理”其实是个很虚的指令，模型根本不知道你具体要防哪些坑。我现在的做法是直接把错误处理写进函数签名或者注释里，比如明确要求“open文件后必须用try/finally关闭”“requests.get必须带timeout参数”，这样它反而能记住。你提到的few-shot确实有用，但不用给太多，两三个带异常处理的小例子就够了，重点是把错误类型和兜底行为写清楚，比如FileNotFoundError就跳过还是重试。至于让AI自查，我试过在prompt最后加一句“生成后请列出所有可能抛异常的地方”，效果时好时坏，感觉它更像是在复述代码而不是真分析。手动review这事真逃不掉，不过我最近发现一个偏方：让它先写个不带错误处理的版本，然后你追加一句“现在给这个脚本加上防御性编程”，这样二次生成的代码往往比一次到位要严谨得多，可能是注意力分配的问题。另外多线程场景下，建议把共享资源访问和锁的逻辑单独拎出来写一小段，别让它混在一起生成，错误率会低不少。

说实话我认为这不是你prompt写得不够细的问题，模型对“健壮”的理解和咱们不一样。我试过在prompt里直接塞一个带完整try-except和超时参数的示例函数，再让它照着写其他部分，效果比描述要求强很多。另外，让它生成后自己跑一遍“pylint”或者输出所有可能出错的场景，它反而会老实一点，不过太复杂的逻辑还是得靠人盯。

说实话这问题我太有同感了，GPT-4对“健壮”的理解跟咱们完全不在一个频道上。我试过把异常处理写进system prompt里，比如“每个函数必须try-except”，但代码一长它照样忘，感觉它更关注逻辑主线，对边界情况的注意力是递减的。后来我发现few-shot确实比纯描述管用，直接丢给它一个带完整try-except和超时设置的示例函数，它模仿得就八九不离十。但要说让AI自查，我试过让它在输出末尾加一段“潜在风险点”分析，效果很飘忽，还不如我自己用pylint扫一遍来得快。说到底，我觉得这事的本质是：LLM写代码像人打草稿，天然省略防御性细节，你越要求“全面”，它越容易顾此失彼。我现在基本放弃让它一次性写对，改成让它先出主逻辑，然后我故意丢个坏路径测试给它看，让它自己修，这样比反复强调prompt省心得多。

few-shot比改prompt管用，塞两个带try的示例进去它立马就学乖了。

事后让它自己跑一遍静态检查或者看报错再补，比干等它自觉靠谱多了。

我试过把错误处理单独拎出来写成一个模块塞进prompt里，让它直接调用，比光说“要健壮”管用多了。另外你可以试试让AI先生成不带异常处理的版本，然后专门下一轮让它“给所有可能抛异常的地方加上try-except和日志”，这样它反而更专注。自查代码那个需求，我一般是让它输出后自己解释每段代码在什么情况下会报错，它一解释就容易发现漏网之鱼。不过多线程那种确实难搞，我最后都是自己盯着超时和锁，AI写的只能当半成品。

说实话我试过挺多办法，最后发现prompt写再细都不如让它“先写后审”来得实在。你可以试试在生成代码后加一句“现在请用代码审查者的视角重新检查一遍，列出所有可能抛异常的地方”，有时候比一开始就强调错误处理有效得多。另外few-shot确实有用，但别给太复杂的例子，就给它看一个“open文件加try/except”的最小对比，它反而能记住。至于“分步骤输出”这种，我猜你是让它先写主逻辑再补错误处理？我试过这样搞，结果它经常在补丁阶段把变量名改乱，更崩溃。还有个歪招，你直接在prompt里写“如果代码里出现open()或requests.get()，必须紧跟try”，用这种条件触发式的指令，比泛泛的“健壮”要听话。不过话说回来，多线程+日志这种复杂度，指望一次生成到位确实不现实，我现在都是让它出骨架，自己填错误处理，反而省时间。你那个“主动自查”的需求，我听说有人用两步对话实现——先让它写，再让它用pylint风格挑刺，但实际跑起来还是得自己看，毕竟AI对逻辑漏洞的敏感度也就那样。

说实话这问题我也踩过坑，光在prompt里喊“健壮性”没用，模型对抽象要求的执行力远不如具体约束。我现在的做法是直接给一段带try-except和超时参数的代码片段当few-shot，它模仿得比听指令靠谱多了。另外你试试让它先写“不考虑错误处理的版本”，再追加一轮“请给所有IO操作加上异常和重试”的指令，分两步生成质量反而高。手动review确实躲不掉，但可以只盯边界情况，比如文件不存在、网络超时、线程池异常，其他交给它自由发挥。

few-shot比改prompt管用，丢两个带try/except的完整例子进去，它立马就懂规矩了。

这题我熟，核心问题不是prompt写得不细，而是模型对“健壮”的理解太表面。我试过把错误处理的具体场景直接写进prompt，比如“文件不存在时打印日志并跳过，网络超时重试3次”，效果比光喊口号强很多。另外few-shot确实有用，给两个带try-except的完整例子，它就会照着模板套。至于自查，我一般让它生成后加一句“请找出代码中所有可能抛异常的地方并修复”，但别指望它全对，该review还得review。

说实话，这问题我太有共鸣了，之前写批量文件处理也踩过同样的坑。你光在prompt里写“健壮”两个字，模型对它的理解其实很模糊，它可能觉得语法没问题就算健壮了。后来我试了把错误处理的规则直接量化到prompt里，比如“每个open()必须跟try/except，每个requests必须带timeout=5”，甚至把异常类型和兜底逻辑都写出来，效果立竿见影。few-shot确实有用，但不用给太多，两三个带极端情况的例子就够了，核心是让模型看到“如果这里不处理会炸”的场景。至于让AI自查，我试过在prompt末尾加一句“生成后请逐行检查是否有未捕获的潜在异常”，但实测它大概率会敷衍地回一句“代码已考虑异常”，没啥用。所以我现在反而更依赖自己的review流程，但会利用AI做辅助——比如让它专门生成一份“边界条件与异常场景清单”，我拿着清单去对照代码，效率高很多。另外我怀疑多线程和日志场景下放飞，是因为模型对状态共享和日志上下文的管理本身就缺乏全局意识，这块可能得靠你主动拆成更小的函数单元去约束它。对了，你有没有试过用代码评审类的prompt模板，比如把生成的代码丢回去让它用“红队视角”找漏洞？我试过几次，偶尔能发现漏网之鱼，但稳定性还是看运气。

说实话，你这问题我太有共鸣了，GPT-4写脚本就是“能跑就行”的典型代表，你让它加异常处理它给你try一下，但根本不会考虑自定义异常类型或者finally清理资源。我觉得根源不在Prompt长度，而是它压根没有“代码会崩溃”的默认认知，你写“健壮”它理解成“语法正确”，所以不如直接给个反面例子——把一段没写错误处理的代码丢给它，让它改，比让它从零生成强得多。few-shot确实比纯描述有效，我试过给两个例子，一个文件操作带try-except，一个网络请求带timeout，再让它写类似的，明显靠谱一些。至于自查这块，我现在的做法是让它先跑一遍“静态分析”，比如你直接问“这段代码在什么情况下会抛异常，怎么改进”，它反而能列出潜在问题，比让它直接写出来强。另外，多线程那块我建议你别全指望AI，你自己把线程池和日志模块的骨架写好，让它只填核心逻辑，错误处理自己包一层，这样反而省心。说到底，AI写脚本就是个加速器，不是质检员，你手动review的习惯还是得保留，但可以只查边界条件和资源释放，别从头看起。