1. 引言

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

2. 什么是防御性编程？

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

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

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

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

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

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

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

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

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

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

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

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

// AI 生成的版本（防御性满满）
public List<String> processItems(List<String> items) {
    if (items == null) {
        return Collections.emptyList();
    }
    List<String> result = new ArrayList<>();
    for (String item : items) {
        if (item != null) {
            result.add(item.trim().toLowerCase());
        }
    }
    return result;
}

// 如果调用方已保证 items 不为空且元素不为 null
public List<String> processItems(List<String> items) {
    return items.stream()
        .map(String::trim)
        .map(String::toLowerCase)
        .collect(Collectors.toList());
}

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

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

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

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

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

// AI 生成的版本（过度防御）
public int calculateLength(String input) {
    try {
        return input.length();
    } catch (NullPointerException e) {
        return 0;
    }
}

// 更合理的版本（明确约定非空）
public int calculateLength(String input) {
    // 约定：调用方保证 input 不为 null
    return input.length();
}

// 或者：明确处理 null 的版本
public int calculateLength(String input) {
    return input == null ? 0 : input.length();
}

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

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

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

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

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

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

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

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

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

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

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

// AI 生成的版本（过度使用 try-catch）
public int parseIntSafely(String value) {
    try {
        return Integer.parseInt(value);
    } catch (NumberFormatException e) {
        return 0;
    }
}

// 这个 try-catch 是合理的，因为 parseInt 确实可能抛异常

// 但 AI 有时会写出这样的代码（过度防御）
public String convertToString(Object obj) {
    try {
        return String.valueOf(obj);
    } catch (Exception e) {
        return "";
    }
}

// 实际上 String.valueOf() 几乎不会抛异常，正确的写法是：
public String convertToString(Object obj) {
    return obj == 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，让它成为我们高效的编码伙伴，而不是一个只会生成冗余代码的机器。