🎯 **模型代码编写中的“静默失败”现象**：大型语言模型在训练中会学习避免直接导致程序崩溃或测试失败的代码。然而，这种学习过程可能导致模型生成看似无误但实际存在问题的代码，例如，通过不当的try/catch块来“掩盖”错误，使得代码在集成测试中通过，但实际运行时却可能因静默失败而影响用户，无法区分是由于错误还是数据库本身返回了特定值。

🛡️ **不当错误处理的具体表现**：这种“静默失败”的行为在代码中常见于几种模式：滥用try/catch块，导致错误被捕获并可能返回默认值，从而掩盖了潜在的逻辑错误或数据缺失；在类型不明确的语言中过度使用`hasattr`或`getattr`来检查属性是否存在，增加了不必要的复杂性；以及在字典键本应存在的情况下，仍设置无效的默认返回值，这会误导其他开发者，让他们认为数据可能不存在。

💡 **改进模型代码生成的建议**：为了对抗这种“静默失败”的倾向，建议对模型进行定制化指导。核心原则是“当代码依赖的关键假设似乎被打破时，应尽早且可见地失败，而不是试图修补”。具体而言，应倾向于将错误向上层调用者传播，而不是在try/catch块内部进行“警告”式处理；如果确信数据应始终存在，应直接假定其存在，避免不必要的保护性代码或存在性检查；避免使用`hasattr`/`getattr`等检查，特别是对于应始终存在的属性；并且绝不应在错误处理中产生无效的‘默认值’，无论是对用户还是下游调用者。

Published on September 19, 2025 8:55 PM GMT

Modern large language models go through a battery of reinforcement learning where they are trained not to produce code that fails in specific, easily detectable ways, like crashing the program or causing failed unit tests. Almost universally, this means these models have learned to produce code that looks like this:

function getSomeParticularNumber(connection: SqlConnection): number {    try {        x = connection.query(SELECT "no" FROM accounts);        return x[0];    } except (err) {         logger.warn("Couldn't get the number; returning 0 by default so as not to break things")        return 0;    }}

The above code is very cheeky, and quite bad. It's more likely to pass integration tests than similar code without the try/catch block, but only because it fails silently. Callers of getSomeParticularNumber won't know whether or not the number being returned is '0', or if '0' is what's actually in the database. And if it turns out this code contains a bug (say, the table should be "Accounts" instead of accounts), testers might not notice that the number being returned is incorrect until it's actually impacting users. 

Some common ways I've seen this behavior manifest include:

Harmful/unncessary try/catch blocksRedundant hasattr or getattr in untyped languagesSetting default return values for dictionary keys that should always exist

Until reinforcement learning environments get much, much better, these models will probably continue to do this. To help prevent this kind of behavior, I include custom instructions for most of my terminal coders:

When key assumptions that your code relies upon to work appear to be broken, fail early and visibly, rather than attempting to patch things up. In particular: Lean towards propagating errors up to callers, instead of silently "warning" about them inside of try/catch blocks. If you are fairly certain data should always exist, assume it does, rather than producing code with unnecessary guardrails or existence checks (esp. if such checks might mislead other programmers into thinking there are cases where the data isn't available) Avoid the use of hasattr/getattr (or non-python equivalents) when accessing attributes and fields that should always exist. Never produce invalid 'defaults' as a result of errors, either for users, or downstream callers.