1. 引言

在使用 AI 编程助手（如 GitHub Copilot、Cursor 等）的过程中，很多开发者都会发现一个有趣的现象：AI 似乎特别喜欢写“防御性代码”。它会在函数入口处检查参数是否为null，会在类型转换前加上try-catch，会在数组操作前判断长度是否大于 0。这些代码本身没有错，甚至可以说是好习惯，但有时也会显得冗余，甚至让人困惑：AI 为什么这么“怕出错”？

2. 什么是防御性编程？

防御性编程是一种编程风格，其核心思想是假设外部输入是不可靠的，并提前为各种可能的异常情况做好准备。常见的做法包括：

• 检查函数参数的有效性（如if (param == null) return;）
• 对可能抛出异常的代码块进行try-catch包裹
• 在访问对象属性前判断其是否存在（如if (obj && obj.prop)）
• 对数组或列表操作前检查其长度

下面是一个典型的防御性编程示例（Java）：

publicStringgetUserDisplayName(Useruser){// 防御性检查：参数可能为 nullif(user==null){return"Unknown User";}// 防御性检查：内部属性也可能为 nullif(user.getName()==null){return"Unnamed User";}returnuser.getName().trim();}

而如果调用方已经保证了user不为空，则可以简化为：

publicStringgetUserDisplayName(Useruser){// 假设调用方已保证 user 不为空returnuser.getName()!=null?user.getName().trim():"Unnamed User";}

对于经验丰富的开发者来说，这是一种成熟的工程实践。但对于 AI 来说，它生成这类代码的动机可能并不完全一样。

3. AI 生成防御性代码的深层原因

3.1 训练数据的“幸存者偏差”

AI 模型是在海量的开源代码上训练的。这些代码中，尤其是那些被长期维护、被广泛使用的项目（如知名的开源库），往往包含了大量的防御性检查。因为这些项目需要应对各种未知的调用环境和用户输入，健壮性是它们的生命线。

AI 在学习过程中，会将这些“优秀代码”中的模式视为一种“正确”的范式。它学到的是：一个可靠的函数，应该先检查输入是否合法。因此，当它生成代码时，会倾向于模仿这种它认为“更安全、更专业”的写法。

代码对比：AI 生成的版本 vs 精简版本

// AI 生成的版本（防御性满满）publicList<String>processItems(List<String>items){if(items==null){returnCollections.emptyList();}List<String>result=newArrayList<>();for(Stringitem:items){if(item!=null){result.add(item.trim().toLowerCase());}}returnresult;}// 如果调用方已保证 items 不为空且元素不为 nullpublicList<String>processItems(List<String>items){returnitems.stream().map(String::trim).map(String::toLowerCase).collect(Collectors.toList());}

AI 之所以选择第一种写法，是因为它在训练数据中看到，优秀的开源库（如 Apache Commons、Guava）几乎都会做null检查。它不知道当前项目的调用约定，只能选择最安全的写法。

3.2 损失函数与“最小化风险”

AI 模型（特别是大语言模型）的优化目标，是生成在统计上最“合理”的后续 token。从模型的角度看，生成一个没有防御性检查的代码，其“风险”远高于生成一个有防御性检查的代码。

• 如果没写防御性代码：当用户运行代码并因为NullPointerException而报错时，用户会认为 AI 生成的代码质量很差。这是一个非常明确的负面反馈。
• 如果写了防御性代码：即使代码在某些场景下显得多余，它通常也不会导致程序崩溃。用户最多觉得它“有点啰嗦”，但不会认为它是“错误的”。

代码对比：AI 的“安全选择”

// AI 生成的版本（过度防御）publicintcalculateLength(Stringinput){try{returninput.length();}catch(NullPointerExceptione){return0;}}// 更合理的版本（明确约定非空）publicintcalculateLength(Stringinput){// 约定：调用方保证 input 不为 nullreturninput.length();}// 或者：明确处理 null 的版本publicintcalculateLength(Stringinput){returninput==null?0:input.length();}

AI 选择第一种try-catch写法，是因为它在统计上认为“捕获异常”比“不处理”更安全。但实际上，用try-catch处理NullPointerException是一种反模式——它掩盖了真正的 bug，而且性能开销远高于简单的null判断。

因此，从“避免犯错”的角度来看，AI 的策略是宁可多做，不可少做。写防御性代码，是它在当前知识体系下，为了最大化代码“可用性”而做出的保守选择。

3.3 缺乏对“上下文”的深度理解

一个资深开发者知道，在某个内部工具类的私有方法中，调用方已经保证了参数不为空，因此不需要再写if (param == null)。但 AI 缺乏这种对项目全局架构和调用链的深度理解。

它看到的只是一个孤立的函数签名。它不知道这个函数会被谁调用、在什么场景下调用。为了确保这个函数在任何情况下都能“安全”运行，它只能基于函数本身的信息，做出最保守的假设——即所有外部输入都可能是危险的。

代码对比：AI 的“孤立视角” vs 开发者的“全局视角”

// 场景：一个内部工具类，调用方已保证参数有效publicclassUserService{// 调用方已保证 user 不为 nullpublicvoidactivateUser(Useruser){// AI 生成的版本（防御性）if(user==null){thrownewIllegalArgumentException("User must not be null");}if(user.getId()==null){thrownewIllegalArgumentException("User ID must not be null");}user.setActive(true);userRepository.save(user);}// 开发者手写的版本（信任调用链）publicvoidactivateUser(Useruser){user.setActive(true);userRepository.save(user);}}

在大型项目中，这种冗余检查会大量堆积，导致代码可读性下降。AI 无法理解“这个私有方法只被同一个类中的另一个方法调用，而那个方法已经做了参数校验”这样的上下文信息。

3.4 对“异常处理”的模板化学习

在训练数据中，try-catch是处理异常的标准模板。AI 学会了这个模板，但有时会过度使用。例如，它可能会为一个几乎不可能失败的简单类型转换（如String.valueOf()）也加上try-catch。这是因为它在数据中看到，处理“不确定性”的最佳实践就是使用异常捕获机制，而它无法精确判断哪些操作是“绝对安全”的。

代码对比：AI 的过度防御 vs 合理写法

// AI 生成的版本（过度使用 try-catch）publicintparseIntSafely(Stringvalue){try{returnInteger.parseInt(value);}catch(NumberFormatExceptione){return0;}}// 这个 try-catch 是合理的，因为 parseInt 确实可能抛异常// 但 AI 有时会写出这样的代码（过度防御）publicStringconvertToString(Objectobj){try{returnString.valueOf(obj);}catch(Exceptione){return"";}}// 实际上 String.valueOf() 几乎不会抛异常，正确的写法是：publicStringconvertToString(Objectobj){returnobj==null?"":obj.toString();}

AI 之所以会为String.valueOf()也加上try-catch，是因为它在训练数据中看到“处理异常”是一个通用模式。它无法像人类开发者一样判断：String.valueOf()内部已经处理了null情况，且toString()方法虽然可能抛异常，但用try-catch捕获所有Exception会掩盖真正的程序错误。

4. 这对开发者意味着什么？

理解 AI 的“防御性”倾向，能帮助我们更好地与 AI 协作：

1. 接受其优点：对于面向外部用户、处理不可信数据的代码，AI 生成的防御性检查非常有用，可以帮我们避免很多低级错误。
2. 批判性接受：对于内部逻辑、私有方法或性能敏感的代码路径，我们需要手动审查并精简 AI 生成的冗余检查。
3. 提供更多上下文：在给 AI 的提示词中，可以明确说明“这是一个内部方法，调用方已保证参数有效”，这能显著减少不必要的防御性代码。
4. 善用重构：将 AI 生成的代码作为“初稿”，然后利用 IDE 的重构功能或自己的经验，去除那些确实多余的检查。

5. 总结

AI 喜欢写防御性代码，并非因为它“胆小”，而是因为它基于海量数据学习到了一种最小化风险、最大化通用性的策略。它缺乏对特定项目上下文的感知，因此倾向于做出最保守、最安全的选择。

作为开发者，我们不应将其视为 AI 的缺陷，而应将其视为一种可预测的行为模式。理解这个模式，我们就能更好地驾驭 AI，让它成为我们高效的编码伙伴，而不是一个只会生成冗余代码的机器。