用AI写Python函数，为啥经常漏掉异常处理这种基本逻辑？

prompt里直接甩个具体例子，比如“文件不存在时返回空列表”，比抽象词好使多了。

我试过在提示里加一句“所有可能出错的地方都要写try”，效果比单说“健壮性”稳定。

我也有同感，感觉这类模型默认是“能跑就行”，很少主动去想边界情况。后来我学乖了，直接在函数名里带个safe，或者提示里写“每个可能抛异常的地方都要写try”，效果会稳定不少。另外你可以试试先让它生成骨架，再专门让它补异常处理，比一次性生成靠谱。

可以把异常处理直接写进函数签名注释里，比如“若文件不存在或行数据异常则返回None”，AI基本能照做。

我最近也遇到同样的问题，感觉AI默认的“正确”是功能能跑通，而不是代码足够抗造。后来我干脆换个思路，prompt里直接写“请先列出这个函数可能遇到的所有异常场景，再写实现”，效果比单纯加形容词好不少，你也可以试试把异常类型点名道姓写上去。不过说实话，它确实很难主动想到边界，更像是个需要你不断喂约束的实习生，关键还是得自己心里有数。

我也有同感，试过在提示里加“所有可能的异常都要捕获”这种话，但生成结果还是看运气。后来我发现干脆直接给它一个异常处理的模板片段，让它照着套，比光靠文字描述靠谱多了。另外你试试把边界情况拆成几条具体要求，比如“文件不存在时返回空列表”“空行跳过”，比笼统说“健壮性”管用。

我怀疑这类模型训练时更偏向功能实现，对防御性细节的权重本来就不高。有时候我会故意先让它跑一遍报错，再让它根据报错去补try-except，反而比一开始就要完整逻辑更稳定。不过确实烦，手动改几次后我都养成习惯了。

试试在提示里直接给个带try-except的示例，AI会照着模板抄，比光说“健壮性”管用。

确实是这样，模型默认倾向生成“理想路径”的代码，把异常当噪音忽略了。我的经验是别指望一句“健壮性”管用，直接在prompt里写清楚“函数开头检查文件存在和空行，不存在就抛自定义异常”，这样它才会照着框架补。还有个偏方，让它先写测试用例再写函数，这样边界情况大概率会被逼出来。

另外我发现有时候不是模型不懂，是它在压缩代码长度时会砍掉它认为“非核心”的逻辑。我一般会强制要求它“每处理一个文件操作后都要加错误处理”，并且指定异常类型。如果还不行，就自己先写个带try-except的骨架，让它填充内部逻辑，成功率会高很多。这其实跟模型训练数据的分布有关，通用代码里异常处理占比确实不高，所以它模仿出来的就少。

我自己也踩过这坑，现在基本是先在对话里给它一个“失败案例”看，比如故意让它运行一个不存在的文件路径，看到报错后再让它修。它一旦“见过”崩溃现场，下次生成时就会主动加防护。你可以试试把“处理缺失值”改成“处理缺失值时打印警告并跳过该行，同时确保程序不中断”，这样指令更具体，效果明显比抽象词汇好。

说实话我也有同感，Cursor在生成代码时更关注主流程，把异常处理当成“附加题”了。后来我习惯把“缺失值”这种需求拆得更细，比如直接写“如果文件不存在就打印错误并返回空列表”，它基本就能加上。另外，有时候在提示里加一句“请先检查输入合法性再处理数据”，比单纯说“健壮性”管用。但确实不稳定，同一段提示多生成几次结果都可能不一样，感觉还是得靠人工review。

我最近也踩过这个坑，后来发现把“处理缺失值”改成“如果文件不存在就返回空DataFrame，遇到空行就跳过并打印警告”这种具体行为描述，生成质量会稳很多。感觉这类模型对抽象词的理解还是太飘，你得把异常场景当成验收标准写进prompt里。另外可以试试在生成后直接追问“这段代码在哪些输入下会崩”，让它自己补try-except，比反复强调关键词管用。

这事儿我也踩过不少坑，后来发现本质是AI在“按需求翻译”而不是“按常识补全”。你让它处理缺失值，它默认你给的数据格式是规范的，所以只关注空单元格，根本没把“文件不存在”或“空行”当成同一个风险等级的问题。我试过最有效的办法是把异常场景直接写进提示里，比如“请处理文件缺失、权限错误、空文件、某列全为空这四种情况”，比光说“健壮性”管用得多。另外，Cursor这类工具其实很依赖上下文，如果你在项目里其他文件已经写过try-except的模板，它大概率会模仿那个风格，所以可以先手动写一个函数作为“示例”，再让它生成类似的。还有个偏方，就是故意在提示里加一句“如果文件有问题，请打印友好错误并返回None”，这样它就会主动去套异常结构，而不是默认一切顺利。说到底，AI不是不擅长边界情况，而是你给它的“边界”不够具体，它只能从训练数据里猜一个最常见的版本。我甚至怀疑有些模型为了追求代码简洁，会故意省略异常处理，因为训练集里那些满分答案往往都挺“干净”的。

我最近也撞上这问题，感觉模型对“健壮性”的理解偏表面化，你光说这个词它可能就加个try-except完事，文件路径不存在这种具体边界它压根不生成检查。后来我干脆在prompt里把要处理的异常类型全列出来，像FileNotFoundError、空行、编码错误这些，它才老实点。还有个小技巧，先让它写个能跑通的主逻辑，再单独发一轮“现在专门补全错误处理”，比一次性要求效果稳。

我也有同感，Cursor这类工具对“健壮性”的理解特别表面，你提了它才动，不提就默认理想输入。后来我试过在prompt里直接给个空行和缺失值的示例数据，让它跑一遍再写代码，效果明显好很多。另外，把“处理缺失值”拆成“跳过空行”和“填充NaN”这种具体指令，比抽象词管用。不过说到底，工具还是缺个“默认防御”的全局开关，不然每次都得靠人肉检查。

这问题我也踩过坑，感觉跟模型对“健壮性”的理解有关，它默认你给的输入都是正常的。后来我学乖了，直接在prompt里把异常场景列出来，比如“文件不存在时返回空DataFrame”这种具体描述，比光说“处理缺失值”好用得多。另外可以试试让AI先写个带try-except的骨架，再填业务逻辑，成功率会高一些。不过说实话，指望它主动考虑所有边界情况确实不现实，关键还是得靠人审一遍。

试试把异常场景直接写进需求里，比如“文件不存在时返回空列表”，比泛泛的“健壮性”管用得多。

说实话我也踩过这个坑，而且试过好几种模型，感觉核心问题不在prompt写得细不细，而是LLM默认就是把“成功路径”当成第一优先级，异常分支本质上是概率低但成本高的逻辑，它天然会偷懒。你加“健壮性”这种抽象词，它可能理解成“不崩就行”，但具体到文件不存在、空行、编码错误这些，它根本不会主动枚举。我的土办法是给一个极简的失败样例，比如在提示里直接贴一行“如果文件是空的会怎样？”，或者明确要求“每个函数开头必须写try，所有IO操作都要捕获异常”，这种指令式约束比形容词管用得多。另外可以试试让AI先写一个带异常处理的“骨架”，再往里面填业务逻辑，顺序反过来效果会好不少。不过说真的，就算这样也得自己过一遍边界，AI写的异常处理经常是结构对但漏掉具体异常类型，比如只捕获了Exception却没处理FileNotFoundError，这种时候你还是得手动补。

把异常处理直接写进prompt示例里，比光说“健壮性”管用，比如贴一段带try-except的代码让它照着写。

提示里给个具体边界场景的输入输出样例，它就容易记住，不然模型默认按理想路径走。

说白了这问题我也踩过坑，AI生成代码时默认追求“能跑”，对边界情况的敏感度确实不如人。后来我试过把异常类型直接写进prompt，比如“文件不存在时返回空DataFrame，空行跳过并打印警告”，效果比单纯说“健壮”靠谱很多。另外你可以让它先写伪代码逻辑，再让你确认要不要加try-except，分两步走反而能逼它考虑周全。

说实话我也踩过这个坑，后来琢磨出个偏方：别让它直接生成整个函数，而是先丢给它一段会崩的测试用例，逼它自己跑一遍再改。你光在prompt里写“处理缺失值”太抽象了，模型可能觉得if row[2] is None就已经算处理了，压根想不到空文件或者编码问题这种更野的边界。

我现在的做法是把异常类型拆开写，比如“FileNotFoundError要返回空列表，csv.Error要跳过坏行并打印警告”，这样它反而会自己补上try-except。另外有时候跟模型聊两句比改prompt管用，我会先让它生成第一版，然后回复“这里如果文件被删了会怎样”，它下一轮通常就会主动加保护了。

不过说真的，这类工具本质上是在模仿你给的代码风格，你要是平时自己写函数也不爱搞防御性编程，它大概率也会跟着“糙”下去。我现在干脆把try-except的模板直接存在snippet里，每次让它先引用再填逻辑，省得来回折腾。

我也有类似的体验，感觉这类模型默认会按“最短路径”生成代码，异常处理属于锦上添花，不是它优先考虑的事。后来我试过在提示里直接把“文件不存在、空行、编码错误”这些具体场景列出来，比单纯说“健壮性”管用得多。还有个偏门技巧是让它先写测试用例，再写实现，这样边界情况会被测试逼出来。不过说实话，指望AI一步到位不现实，关键路径上的异常还是得自己过一遍。

这问题我也踩过坑，后来发现光靠提示词加“健壮性”确实不稳定，AI对这类抽象词的理解很飘。我的办法是直接把异常场景写进prompt里，比如“文件不存在时返回空列表，空行跳过并打印警告”，给具体例子比给形容词管用得多。另外你试试让它先写伪代码或者分步生成，先搭骨架再补异常处理，成功率会高不少。你用的是单次生成还是对话多轮修改？多轮的话可以明确跟它说“现在检查所有可能抛异常的地方”，效果比一开始就要求全要好。