AI 为什么总喜欢写防御性代码？-北京尧图网络

1. 引言在使用 AI 编程助手如 GitHub Copilot、Cursor 等的过程中很多开发者都会发现一个有趣的现象AI 似乎特别喜欢写“防御性代码”。它会在函数入口处检查参数是否为null会在类型转换前加上try-catch会在数组操作前判断长度是否大于 0。这些代码本身没有错甚至可以说是好习惯但有时也会显得冗余甚至让人困惑AI 为什么这么“怕出错”2. 什么是防御性编程防御性编程是一种编程风格其核心思想是假设外部输入是不可靠的并提前为各种可能的异常情况做好准备。常见的做法包括检查函数参数的有效性如if (param null) return;对可能抛出异常的代码块进行try-catch包裹在访问对象属性前判断其是否存在如if (obj obj.prop)对数组或列表操作前检查其长度下面是一个典型的防御性编程示例JavapublicStringgetUserDisplayName(Useruser){// 防御性检查参数可能为 nullif(usernull){returnUnknown User;}// 防御性检查内部属性也可能为 nullif(user.getName()null){returnUnnamed 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 生成的版本防御性满满publicListStringprocessItems(ListStringitems){if(itemsnull){returnCollections.emptyList();}ListStringresultnewArrayList();for(Stringitem:items){if(item!null){result.add(item.trim().toLowerCase());}}returnresult;}// 如果调用方已保证 items 不为空且元素不为 nullpublicListStringprocessItems(ListStringitems){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){returninputnull?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(usernull){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-catchpublicintparseIntSafely(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){returnobjnull?:obj.toString();}AI 之所以会为String.valueOf()也加上try-catch是因为它在训练数据中看到“处理异常”是一个通用模式。它无法像人类开发者一样判断String.valueOf()内部已经处理了null情况且toString()方法虽然可能抛异常但用try-catch捕获所有Exception会掩盖真正的程序错误。4. 这对开发者意味着什么理解 AI 的“防御性”倾向能帮助我们更好地与 AI 协作接受其优点对于面向外部用户、处理不可信数据的代码AI 生成的防御性检查非常有用可以帮我们避免很多低级错误。批判性接受对于内部逻辑、私有方法或性能敏感的代码路径我们需要手动审查并精简 AI 生成的冗余检查。提供更多上下文在给 AI 的提示词中可以明确说明“这是一个内部方法调用方已保证参数有效”这能显著减少不必要的防御性代码。善用重构将 AI 生成的代码作为“初稿”然后利用 IDE 的重构功能或自己的经验去除那些确实多余的检查。5. 总结AI 喜欢写防御性代码并非因为它“胆小”而是因为它基于海量数据学习到了一种最小化风险、最大化通用性的策略。它缺乏对特定项目上下文的感知因此倾向于做出最保守、最安全的选择。作为开发者我们不应将其视为 AI 的缺陷而应将其视为一种可预测的行为模式。理解这个模式我们就能更好地驾驭 AI让它成为我们高效的编码伙伴而不是一个只会生成冗余代码的机器。

AI 为什么总喜欢写防御性代码？

相关推荐

Figma中文汉化插件终极指南：3分钟实现全界面中文翻译

URP相机混合实战：基于Renderer Feature的多相机渲染合成方案

大模型时代NLP技术演进与实战指南

更多资讯

语音识别本地部署：大模型时代的企业数据主权保卫战与落地指南

SQL Server 1433端口弱口令引爆勒索病毒：从攻击链到应急防护全复盘

语音识别本地部署：企业级AI转写的破局之路与实战解析

储能项目地图可视化：Leaflet实战避坑指南

HTTP安全响应头配置实战：CSP与X-Frame-Options防攻击指南

【NebulaGraph】NebulaGraph 各个服务组件（Metad, Storaged, Graphd）的关键配置文件有哪些？核心参数如何调优？

今日更新

基于高阶循环谱的MPSK载波频率估计与MATLAB实现

MiniPdf方：.NET开源Office转PDF的高效解决方案

Solon AI v3.10：Java全栈智能体开发框架解析

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？