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

说实话这问题太真实了，我试过把错误处理直接写进系统提示词里，比如“每个函数必须try-except，网络请求必须设超时”，但复杂任务下它还是会漏。后来我干脆在Prompt里塞了一个极简的“错误处理模板”作为few-shot，比如open文件那段固定用with open加except，效果比单纯说“健壮”好得多。至于自查，我都是让它生成后加一句“请检查上述代码中所有可能抛异常的地方并补全”，虽然不能保证100%，但至少能逼它回头改一遍。手动review确实躲不掉，不过把检查清单固化下来会轻松点。

试试让AI先写错误处理框架再填业务逻辑，或者直接让它输出带pytest测试的版本，实测比单纯加提示词管用。

我最近用“必须捕获所有异常并记录日志”这个硬性要求配合代码评审清单，生成质量提升明显，你可以加个自查步骤到prompt里。

这问题太真实了，我试过在prompt里加“必须用try-except包裹所有IO操作”这种硬约束，效果比“健壮”这种模糊词好点，但复杂任务照样翻车。后来我干脆把错误处理当成独立需求，让AI先写主逻辑，再单独生成一个错误处理模块，最后自己拼起来。你提到的few-shot我试过，给两三个例子确实能减少低级遗漏，但太占token，而且它容易照葫芦画瓢写死。至于自查，我让AI输出前加一步“逐行检查未捕获异常”，偶尔能抓出漏网之鱼，但别指望它太靠谱——本质还是概率模型，不如自己写个静态检查脚本扫一遍。

这问题太真实了，我试过在prompt里加“检查代码质量”结果它自己给自己打满分。后来我干脆在结尾固定加一句“请用pylint风格自查并列出潜在异常”，虽然不能全解决，但至少它会把裸奔的open()加个try了。多线程那块确实无解，你不如让它先拆成单线程逻辑，自己手动套个并发壳，反而比让它硬编靠谱。

说实话，我跟你遇到的情况一模一样，甚至怀疑咱们用的是同一个GPT-4。后来我试了个野路子，感觉比在Prompt里反复强调“健壮性”有用——就是直接告诉它“你写的代码会被扔到生产环境跑，崩了要扣你工资”，语气狠一点，它反而会老实很多。不过说到底，我觉得它天生缺乏“风险意识”，你让它写功能，它脑子里只有主路径，异常分支对它来说跟不存在似的。few-shot我也试过，给两个带try-except的例子确实有点效果，但任务一复杂，它又开始选择性失明，尤其是多线程那种，它根本想不到线程池要处理异常。至于让AI自查，我目前是让它“以资深reviewer的口吻挑刺”，然后强制它输出三遍修改后的代码，第三次质量会明显好一点，但也别指望它能全对。说到底，我觉得这事的核心是别把AI当工程师，当个能快速出初稿的实习生就行，重要脚本还是得自己过一遍错误处理，不然线上出问题更累。

说实话我也踩过这个坑，后来发现光在prompt里强调“健壮”没用，AI对抽象要求理解很表面。我现在会直接在需求里塞一段错误处理的标准模板，比如明确要求open必须配try-except-else-finally，网络请求必须设timeout参数，它反而能照着框架执行。至于自查，可以让它自己跑一遍pylint或者写几个边界测试用例，不过说实话，复杂代码还是得人工过，别指望AI一步到位。

说实话这事儿我太有同感了，单纯在prompt里塞一句“健壮性”根本没用，模型理解的是字面意思，不是你的工程标准。我后来干脆把错误处理写成具体规则，比如“所有open必须配try-except，网络请求必须设timeout=10”，效果比抽象描述好得多。另外你也可以试试让它生成完自己跑一遍静态检查，用pylint或者mypy的报错再喂回去让它改，虽然多花一轮token，但比手动review省心。

说实话这问题太典型了，光靠prompt里加一句“要健壮”基本没用，模型对“健壮”的理解太抽象。我试过最有效的方式是把错误处理直接写进伪代码结构里，比如“每个函数必须包含try-except-else-finally，且except里要打日志”，这样约束力强很多。另外你说的让AI自查，可以试着在prompt末尾加一句“请检查你生成的代码，指出所有可能抛出异常的地方并修复”，实测能减少一半漏网之鱼，但复杂任务还是得靠你review，别指望它一次到位。

这问题太真实了，我试过把错误处理样例直接塞进prompt里，结果它倒是会try了，但except里全是pass，等于白写。后来我干脆在需求里加一句“每个函数必须返回成功或异常状态”，稍微好点。不过多线程那种确实容易放飞，感觉模型对复杂逻辑的“健壮性”理解还是太表面。要不你试试让它先写伪代码框架，再逐块填充，最后单独让它检查一遍异常路径？手动review真逃不掉，就当是代码审查的预演了。

试试在prompt里直接要求“所有IO操作必须写try/except并返回错误信息”，比空泛的“健壮”管用得多。

我一般会加一句“生成后自己找三个崩溃场景并补上处理”，它确实会认真自查一遍。

我一般让它写完后自己挑错，比如加一句“检查遗漏的异常和超时”，比一开始强调管用。

说实话这问题太常见了，我试过把错误处理写成checklist塞进prompt里，效果也就那样。后来干脆让AI先写一版逻辑，然后单独发一句“请找出所有可能抛异常的地方并补上try”，比一开始就要求完整健壮靠谱得多。至于让AI自查，你可以让它扮演code reviewer挑毛病，但多线程或者IO密集的代码它还是容易漏，真不如自己养成习惯扫一眼关键操作。反正我现在就默认它第一版是裸奔的，省得失望。

说实话这事儿我也踩过坑，后来发现光在prompt里写“要健壮”基本等于没说，模型对“健壮”的理解跟咱们差太多了。你得把错误处理拆成具体规则喂给它，比如“所有open必须配try-except-finally，网络请求必须设timeout=10”，它才会当回事儿。few-shot确实比抽象描述管用，我试过给两个带完整异常处理的例子，生成质量能上一个台阶，但代价是prompt会变得特别长，复杂任务下反而容易把上下文撑爆。

至于让AI自查，我现在是用两步走：先让它生成代码，然后追加一句“请逐行检查这段代码，指出所有可能抛出异常的地方并修改”，相当于把review也外包给它。不过说实话，多线程+日志这种场景，模型确实容易顾此失彼，它可能觉得加了logging就万事大吉，线程池的异常捕获又忘了。我现在干脆把错误处理模板直接写进prompt开头，相当于给它一个“半成品框架”，让它往里面填业务逻辑，比让它从零自由发挥稳定多了。

你提到手动review累，我特别理解，但说实话，这活儿现阶段AI真替代不了——它写出来的代码你得自己跑一遍边界情况才知道哪儿会崩。我现在的妥协是：让它生成初版+自查一遍，我再重点看文件IO、网络调用和线程资源这三个高危区，其他逻辑反而可以少花时间。你试试把错误类型分类写在prompt里，比如“文件不存在、连接超时、编码错误、线程中断”，让它逐类覆盖，效果比笼统的“健壮”要好很多。

我试过类似的情况，感觉单纯在prompt里写“要健壮”没啥用，模型对抽象词的理解太飘了。后来我改成在关键位置直接给反例，比如“如果文件不存在就except FileNotFoundError并记录日志”，它反而能照着写。你那个多线程加日志的场景，其实可以先把错误处理框架拆成一个独立函数让它实现，再让它调用，这样比让它一步到位靠谱点。至于自查，我一般让它跑完后用pylint或mypy过一遍，把报错丢回去让它改，比干等它自觉有用。

试试把异常处理写成必须返回的代码块模板，让它填空而不是自由发挥，能稳不少。

多轮对话里加一句“请检查上一步代码的异常覆盖”，比一次prompt写满管用。

说实话你这个问题我也踩过很久，后来发现根子不在prompt措辞上，而是模型对“健壮”的理解跟咱们不一样。它默认你给的任务是“能跑通就行”，异常处理属于边缘场景，除非你明确把“可能出错的地方”列出来，否则它真就给你裸奔代码。我试过在prompt里加一句“所有IO操作必须try，所有网络请求必须设timeout，否则重新生成”，效果比长篇大论描述“要健壮”好得多，但任务一复杂它还是会漏。

few-shot确实有用，但别给完整例子，给那种“故意留坑”的对比——比如同一个函数，先给错误版本再给修正版，它反而能学到模式。至于让AI自查，我试过最接近的办法是在最后加一句“请逐行检查你刚才的代码，找出至少三个可能抛出异常的位置并修复”，但这招时灵时不灵，模型有时候会假装检查，实际没改。

我现在的做法是干脆自己写个小的异常处理模板，让AI按模板填空，而不是自由发挥。比如文件操作固定用with open加try/except，网络请求统一用retry装饰器，这样它就算放飞也只是在业务逻辑上放飞，IO部分基本不会出大问题。说实话手动review躲不掉，但能减少到只查关键逻辑，已经很省力了。

我试过把错误处理写进系统提示词里，比如“每个函数必须用try包住IO操作”，比单纯说“要健壮”管用得多。但复杂任务确实容易崩，感觉模型在长上下文里会把早期指令“忘掉”，现在我都让它先输出伪代码框架，确认逻辑后再补全细节。另外让AI自查基本没戏，它只会说“这段代码没问题”，不如自己写个简单的lint脚本扫一遍。

试试把错误处理写进系统级约束，或者干脆让它先输出错误场景清单再写代码，效果会好很多。

few-shot确实管用，给两个带try和超时的例子它就老实了，另外让它输出前自己跑一遍异常场景测试。

我试过把“自查”写进prompt，让它模拟输入和断网场景跑逻辑，比单纯review省心不少。

这事我太有同感了，上个月写一个批量重命名加日志的脚本，它给我生成的open()全是裸的，跑一半文件锁了直接崩。后来我发现光在Prompt里写“健壮”基本没用，这词对模型来说太抽象，它理解不了你到底要哪几层防护。我的经验是得把错误处理拆成具体规则，比如“每个文件操作必须包在try/except里，except要打印路径和错误类型，不能单纯pass”，这样它才会照做。few-shot确实管用，但别给太复杂的例子，给一个带超时和重试的requests封装就够了，给多了它反而会抄乱。至于自查，我一般会让它生成完后加一句“现在以代码审查者身份逐行检查，列出所有可能抛异常但未捕获的地方”，这招比单纯说“检查质量”有效得多。不过多线程那块我到现在也没找到特别稳的写法，它老是忘记给线程加异常钩子，不知道你有没有试过让它先输出线程封装类再填业务逻辑？