1. 先搞清楚AI 写的代码到底“坑”在哪1.1 为什么“能跑”不等于“能上线”我先把结论摆在前面AI 生成的代码绝大多数情况下“能跑”但“能跑”和“能上生产”之间隔着一条很宽的河。很多人第一次用 AI 写代码本地一跑接口通了数据也出来了心里那个爽恨不得当场合并主干、打包上线。结果呢上线第二天线上报警日志刷屏回滚都来不及。问题出在哪出在 AI 写代码的逻辑和人类工程师写代码的逻辑压根不是一回事。AI 的目标是“生成一段看起来正确、能通过你描述的代码”它不负责“这段代码在并发 200 的情况下会不会把数据库连接池打满”也不负责“这个循环在数据量涨到十万条时会不会把内存吃光”。它更不会主动告诉你“兄弟这里我没做异常处理你上线前记得补。”我踩过最典型的一个坑让 AI 写一个批量更新用户状态的方法它给我生成了一个 for 循环里逐条 update 的写法。本地测试 10 条数据秒过。上线后运营批量操作 5000 个用户数据库直接被打出一堆慢查询接口超时整个用户中心卡了将近两分钟。这就是典型的“AI 代码能跑但不能上生产”——它缺的不是功能是工程意识。所以AI 生成的代码敢不敢直接上生产我的答案是敢用但必须过检查。下面这四道检查是我上线前雷打不动要走的流程缺一道我心里都不踏实。1.2 四道检查的整体设计思路这四道检查不是拍脑袋想出来的是我在多次“血泪回滚”之后总结出来的。它们的排列顺序有讲究从“静态”到“动态”从“单点”到“全局”层层递进第一道代码规范与静态扫描——先把明显的低级问题挡在门外比如命名混乱、魔法值、空指针风险、资源未关闭。第二道逻辑正确性与边界验证——AI 最容易在边界条件上翻车空集合、null 值、超大数、并发场景必须逐个验证。第三道性能与资源消耗评估——本地跑得快不代表线上扛得住SQL 执行计划、循环复杂度、内存占用都要过一遍。第四道安全与生产环境适配——SQL 注入、敏感信息硬编码、日志脱敏、配置项隔离这些是上线前的最后一道闸门。这四道检查走完基本能把 AI 代码 90% 以上的“生产事故隐患”筛出来。剩下的 10%靠的是灰度发布和监控兜底。下面我逐道拆开讲每一道都配上我实际用过的工具、命令和判断标准。2. 第一道检查代码规范与静态扫描2.1 为什么静态扫描必须放在第一位静态扫描是成本最低、收益最高的一道检查。它不需要你启动服务不需要造测试数据几秒钟就能跑完却能揪出一大批“AI 特有的低级错误”。AI 生成代码有几个高频毛病变量命名随意a、b、temp、data1、魔法值满天飞直接写if (status 3)、异常被吞掉catch (Exception e) {}空的、资源不关闭InputStream用完不关。这些问题在本地可能不暴露但到了生产环境任何一个都可能变成定时炸弹。我一般用SonarQube或者Alibaba Java Coding Guidelines插件做第一轮扫描。如果是 Java 项目阿里规约插件在 IDEA 里装好AI 生成的代码一贴进来满屏的黄色警告看着就安心——至少你知道问题在哪。2.2 静态扫描重点盯防的几类问题我把 AI 代码在静态扫描中最常暴露的问题整理成了一张表你可以对照着重点看问题类型典型表现生产风险处理建议命名不规范变量叫list1、map2、tempStr可维护性差后续接手的人看不懂重命名为业务含义明确的名称魔法值直接写if (type 5)业务含义丢失改一处漏一处提取为枚举或常量空指针风险直接调用可能为 null 的对象方法线上 NPE接口 500加判空或使用 Optional资源未关闭Connection、Stream未在 finally 关闭连接池耗尽服务不可用使用 try-with-resources异常吞没catch块为空或只打印不处理问题被掩盖排查困难至少记录日志并决定是否抛出重复代码同一段逻辑复制粘贴多份改一处漏一处维护成本高抽取公共方法这张表里的每一行我都在真实项目里遇到过。尤其是“异常吞没”和“资源未关闭”AI 生成的概率极高因为它倾向于让代码“看起来简洁”而简洁的代价往往是省略了必要的工程处理。2.3 实操用 SonarQube 跑一遍 AI 代码具体操作不复杂。本地起一个 SonarQube 容器或者直接用公司现成的扫描平台把 AI 生成的代码提交上去重点看几个指标代码异味Code Smell数量、Bug 数量、安全漏洞数量、重复率。我的经验阈值是AI 生成的单个类代码异味超过 5 个就必须逐条 review出现任何一条“阻断级”问题比如空指针、资源泄漏直接打回重写不要心存侥幸。提示静态扫描不要只看总数要看具体类型。AI 代码的“代码异味”往往集中在命名和魔法值上这类问题改起来快但如果出现“严重 Bug”级别的告警比如并发问题、空指针那就要认真对待了。这里有个小技巧把 AI 生成的代码和团队现有的代码规范配置文件一起跑这样扫描结果更贴近你的实际标准。很多团队用的是自定义规则集直接套用默认规则可能会漏掉一些团队特有的约束。3. 第二道检查逻辑正确性与边界验证3.1 AI 最爱的“边界盲区”静态扫描过了不代表逻辑就对。AI 写代码有一个非常明显的特征它擅长处理“正常路径”但对“异常路径”和“边界条件”几乎不设防。你让它写一个“根据用户 ID 查订单列表”的方法它会给你一个漂亮的查询但它不会主动考虑用户 ID 传了 null 怎么办查出来是空列表怎么办订单数量超过一万条怎么办分页参数传了负数怎么办这些边界条件才是生产环境真正的“事故高发区”。我见过最离谱的一次AI 写了一个“计算订单折扣”的方法逻辑看起来没问题但没处理“折扣率为 0”的情况结果线上一个促销活动把折扣率配成了 0直接导致所有订单金额计算为 0用户下单不要钱半小时后才被发现。这就是边界条件没验证的代价。3.2 边界验证的四个必查维度我总结了一个“边界四查”清单每次 AI 生成核心业务逻辑后必须逐个过一遍空值与空集合入参为 null、空字符串、空列表时代码是否还能正常执行会不会抛 NPE 或者返回错误结果数值边界最大值、最小值、零、负数、超大数比如Integer.MAX_VALUE传入时计算是否会溢出或逻辑错乱并发边界同一份数据被多个线程同时读写时会不会出现脏读、覆盖、死锁AI 生成的代码默认是单线程思维这点尤其要注意。状态边界对象处于“未初始化”“已关闭”“已过期”等特殊状态时方法调用是否安全这四个维度我建议你写成单元测试用例每个维度至少覆盖 2 到 3 个 case。AI 生成的代码单元测试覆盖率往往很低补上这些测试不仅能验证逻辑还能作为后续回归的保障。3.3 实操用单元测试“逼”出逻辑漏洞具体做法针对 AI 生成的每个 public 方法写一组参数化测试。以 Java 为例用 JUnit 5 的ParameterizedTest配合NullSource、EmptySource、ValueSource把 null、空值、边界值一次性喂进去。ParameterizedTest NullSource EmptySource ValueSource(strings {, , , a.repeat(10000)}) void testProcessInput(String input) { // 调用 AI 生成的方法观察是否抛异常或返回异常结果 assertDoesNotThrow(() - service.process(input)); }跑一遍如果 AI 代码在这些输入下抛异常或者返回了不符合预期的结果那就说明边界处理缺失必须补上。这个步骤花不了多少时间但能挡住大量线上问题。注意不要只测“正常值”。AI 代码在正常值下几乎不会出错测了也是白测。要把精力集中在“异常值”和“极端值”上这才是 AI 的软肋。4. 第三道检查性能与资源消耗评估4.1 本地快不等于线上稳性能问题是最隐蔽的。AI 生成的代码在本地跑数据量小响应飞快你根本感觉不到问题。但生产环境的数据量、并发量、网络延迟和本地完全不是一个量级。一个在本地 10ms 返回的接口到了线上可能因为一条没走索引的 SQL变成 3 秒超时。我印象很深的一次AI 帮我写了一个“查询用户最近 30 天订单”的方法逻辑没问题但生成的 SQL 是SELECT * FROM orders WHERE user_id ? AND create_time ?而create_time字段上没有索引。本地测试数据只有几百条查询飞快。上线后订单表几百万数据这个查询直接全表扫描数据库 CPU 飙到 90%拖垮了整个订单服务。后来加了一个联合索引才解决。4.2 性能评估的三个核心指标AI 代码上线前我重点关注三个指标SQL 执行计划所有涉及数据库查询的代码必须用EXPLAIN看一遍执行计划确认走了索引没有全表扫描没有临时表排序。循环与递归复杂度AI 生成的代码里嵌套循环和递归是性能杀手。看到双层以上循环就要警惕时间复杂度是不是 O(n²) 甚至更高。内存占用一次性把大量数据加载到内存比如SELECT不加LIMIT、List无限增长在生产环境极易引发 OOM。这三个指标不需要复杂的压测工具用EXPLAIN、代码 review 和简单的内存分析就能覆盖大部分场景。4.3 实操SQL 执行计划与循环复杂度检查SQL 这块直接把 AI 生成的 SQL 拿到数据库客户端里前面加EXPLAIN看type列。如果是ALL说明全表扫描必须优化如果是index或ref基本可以接受。另外看rows列预估扫描行数如果超过万级就要考虑加索引或改写查询。循环复杂度这块我一般用 IDEA 的插件或者 SonarQube 的“认知复杂度”指标。一个方法的认知复杂度超过 15就说明逻辑太绕AI 生成的代码尤其容易在这项上超标。超标的方法要么拆分要么重写。-- 检查 AI 生成的 SQL 是否走索引 EXPLAIN SELECT * FROM orders WHERE user_id 123 AND create_time 2024-01-01; -- 关注 type 列ALL 表示全表扫描需优化 -- 关注 rows 列预估扫描行数过大需加索引提示AI 生成的 SQL 经常忽略LIMIT查询列表时一定要手动加上分页否则数据量一大内存直接爆掉。5. 第四道检查安全与生产环境适配5.1 安全问题是“一票否决”前三道检查过了代码基本能跑了但能不能“安全地跑”还得看第四道。安全问题在生产环境是“一票否决”的——一个 SQL 注入漏洞可能让整个数据库被拖走一个硬编码的密钥可能让第三方服务被恶意调用。AI 生成的代码在安全方面往往“天真得可爱”它不会主动帮你做参数化查询也不会提醒你日志里别打印敏感信息。我遇到过 AI 生成的代码里直接把数据库密码写在了main方法里理由是“方便测试”。这要是上了生产代码一提交密码就进了版本库后果不堪设想。5.2 生产适配的四个必查项上线前我会重点检查这四个方面SQL 注入防护所有数据库操作必须使用参数化查询PreparedStatement或 ORM 框架严禁字符串拼接 SQL。敏感信息硬编码密码、密钥、Token 一律走配置中心或环境变量代码里不能出现明文。日志脱敏用户手机号、身份证号、银行卡号等敏感字段打印日志时必须脱敏。配置隔离开发、测试、生产的配置必须分离AI 生成的代码经常把测试环境的地址写死上线前必须改成可配置项。这四项里任何一项出问题都可能导致严重的安全事故。尤其是 SQL 注入和硬编码AI 生成的代码命中率相当高。5.3 实操安全扫描与配置检查安全扫描可以用OWASP Dependency-Check或者公司内部的 SAST 工具重点看有没有 SQL 注入、XSS、硬编码密钥等告警。配置检查更简单直接全局搜索代码里的password、secret、key、token等关键词看看有没有明文。# 全局搜索可能的硬编码敏感信息 grep -rn password\|secret\|token\|apiKey src/main/java/ # 检查是否有字符串拼接 SQL grep -rn SELECT.*.*FROM\|WHERE.*.* src/main/java/这两条命令跑一遍基本能把明显的安全隐患筛出来。剩下的靠代码 review 和上线前的安全评审兜底。注意AI 生成的代码里日志打印经常“过于详细”把整个对象都toString()出来。如果这个对象包含敏感字段日志里就会留下明文。上线前一定要检查日志打印语句该脱敏的脱敏该删的删。6. 四道检查走完AI 代码才敢上生产6.1 我的上线检查清单四道检查走完我会填一张上线检查清单每一项都打勾了才允许合并到发布分支。这张清单长这样检查项检查内容是否通过静态扫描SonarQube 无阻断级问题代码异味已处理□边界验证空值、边界值、并发场景单元测试通过□性能评估SQL 走索引无嵌套循环无内存泄漏风险□安全适配无 SQL 注入无硬编码日志已脱敏□配置隔离生产配置独立无测试地址硬编码□这张清单看起来简单但每一项背后都是实打实的检查动作。我坚持用这张清单是因为它帮我挡掉了至少三次可能的生产事故。有一次 AI 生成的代码在静态扫描时发现了一个空指针风险当时觉得“应该不会触发”但还是补了判空。结果上线后第三天真的有一个边界数据触发了那个空指针因为提前补了判空接口只是返回了默认值没有报错。那一刻我就知道这四道检查没白做。6.2 几个容易忽略的细节最后分享几个我在实操中总结的细节都是常规文档里不会写的AI 生成的代码注释往往是“废话”。比如// 设置名称这种看了等于没看。上线前把这类注释删掉换成真正有价值的说明比如“此处判空是因为上游接口可能返回 null”。AI 喜欢用System.out.println调试。上线前全局搜索一下把这些调试输出全部换成日志框架否则生产日志里全是乱七八糟的输出。AI 生成的异常处理经常只打印e.getMessage()。这会导致堆栈丢失排查问题时根本不知道异常从哪来。改成log.error(xxx, e)把完整堆栈打出来。AI 生成的代码方法参数经常超过 5 个。参数太多不仅难维护还容易传错顺序。上线前考虑封装成对象或者用 Builder 模式重构。这些细节单看都是小事但累积起来就是“AI 代码能不能上生产”的关键。AI 是个好帮手但它不是工程师。它能帮你写代码但不能替你负责。上线前这四道检查就是你把“AI 的代码”变成“你的代码”的过程。走完这四道你才敢说这段代码我敢让它上生产。
1. 先搞清楚AI 写的代码到底“坑”在哪1.1 为什么“能跑”不等于“能上线”我先把结论摆在前面AI 生成的代码绝大多数情况下“能跑”但“能跑”和“能上生产”之间隔着一条很宽的河。很多人第一次用 AI 写代码本地一跑接口通了数据也出来了心里那个爽恨不得当场合并主干、打包上线。结果呢上线第二天线上报警日志刷屏回滚都来不及。问题出在哪出在 AI 写代码的逻辑和人类工程师写代码的逻辑压根不是一回事。AI 的目标是“生成一段看起来正确、能通过你描述的代码”它不负责“这段代码在并发 200 的情况下会不会把数据库连接池打满”也不负责“这个循环在数据量涨到十万条时会不会把内存吃光”。它更不会主动告诉你“兄弟这里我没做异常处理你上线前记得补。”我踩过最典型的一个坑让 AI 写一个批量更新用户状态的方法它给我生成了一个 for 循环里逐条 update 的写法。本地测试 10 条数据秒过。上线后运营批量操作 5000 个用户数据库直接被打出一堆慢查询接口超时整个用户中心卡了将近两分钟。这就是典型的“AI 代码能跑但不能上生产”——它缺的不是功能是工程意识。所以AI 生成的代码敢不敢直接上生产我的答案是敢用但必须过检查。下面这四道检查是我上线前雷打不动要走的流程缺一道我心里都不踏实。1.2 四道检查的整体设计思路这四道检查不是拍脑袋想出来的是我在多次“血泪回滚”之后总结出来的。它们的排列顺序有讲究从“静态”到“动态”从“单点”到“全局”层层递进第一道代码规范与静态扫描——先把明显的低级问题挡在门外比如命名混乱、魔法值、空指针风险、资源未关闭。第二道逻辑正确性与边界验证——AI 最容易在边界条件上翻车空集合、null 值、超大数、并发场景必须逐个验证。第三道性能与资源消耗评估——本地跑得快不代表线上扛得住SQL 执行计划、循环复杂度、内存占用都要过一遍。第四道安全与生产环境适配——SQL 注入、敏感信息硬编码、日志脱敏、配置项隔离这些是上线前的最后一道闸门。这四道检查走完基本能把 AI 代码 90% 以上的“生产事故隐患”筛出来。剩下的 10%靠的是灰度发布和监控兜底。下面我逐道拆开讲每一道都配上我实际用过的工具、命令和判断标准。2. 第一道检查代码规范与静态扫描2.1 为什么静态扫描必须放在第一位静态扫描是成本最低、收益最高的一道检查。它不需要你启动服务不需要造测试数据几秒钟就能跑完却能揪出一大批“AI 特有的低级错误”。AI 生成代码有几个高频毛病变量命名随意a、b、temp、data1、魔法值满天飞直接写if (status 3)、异常被吞掉catch (Exception e) {}空的、资源不关闭InputStream用完不关。这些问题在本地可能不暴露但到了生产环境任何一个都可能变成定时炸弹。我一般用SonarQube或者Alibaba Java Coding Guidelines插件做第一轮扫描。如果是 Java 项目阿里规约插件在 IDEA 里装好AI 生成的代码一贴进来满屏的黄色警告看着就安心——至少你知道问题在哪。2.2 静态扫描重点盯防的几类问题我把 AI 代码在静态扫描中最常暴露的问题整理成了一张表你可以对照着重点看问题类型典型表现生产风险处理建议命名不规范变量叫list1、map2、tempStr可维护性差后续接手的人看不懂重命名为业务含义明确的名称魔法值直接写if (type 5)业务含义丢失改一处漏一处提取为枚举或常量空指针风险直接调用可能为 null 的对象方法线上 NPE接口 500加判空或使用 Optional资源未关闭Connection、Stream未在 finally 关闭连接池耗尽服务不可用使用 try-with-resources异常吞没catch块为空或只打印不处理问题被掩盖排查困难至少记录日志并决定是否抛出重复代码同一段逻辑复制粘贴多份改一处漏一处维护成本高抽取公共方法这张表里的每一行我都在真实项目里遇到过。尤其是“异常吞没”和“资源未关闭”AI 生成的概率极高因为它倾向于让代码“看起来简洁”而简洁的代价往往是省略了必要的工程处理。2.3 实操用 SonarQube 跑一遍 AI 代码具体操作不复杂。本地起一个 SonarQube 容器或者直接用公司现成的扫描平台把 AI 生成的代码提交上去重点看几个指标代码异味Code Smell数量、Bug 数量、安全漏洞数量、重复率。我的经验阈值是AI 生成的单个类代码异味超过 5 个就必须逐条 review出现任何一条“阻断级”问题比如空指针、资源泄漏直接打回重写不要心存侥幸。提示静态扫描不要只看总数要看具体类型。AI 代码的“代码异味”往往集中在命名和魔法值上这类问题改起来快但如果出现“严重 Bug”级别的告警比如并发问题、空指针那就要认真对待了。这里有个小技巧把 AI 生成的代码和团队现有的代码规范配置文件一起跑这样扫描结果更贴近你的实际标准。很多团队用的是自定义规则集直接套用默认规则可能会漏掉一些团队特有的约束。3. 第二道检查逻辑正确性与边界验证3.1 AI 最爱的“边界盲区”静态扫描过了不代表逻辑就对。AI 写代码有一个非常明显的特征它擅长处理“正常路径”但对“异常路径”和“边界条件”几乎不设防。你让它写一个“根据用户 ID 查订单列表”的方法它会给你一个漂亮的查询但它不会主动考虑用户 ID 传了 null 怎么办查出来是空列表怎么办订单数量超过一万条怎么办分页参数传了负数怎么办这些边界条件才是生产环境真正的“事故高发区”。我见过最离谱的一次AI 写了一个“计算订单折扣”的方法逻辑看起来没问题但没处理“折扣率为 0”的情况结果线上一个促销活动把折扣率配成了 0直接导致所有订单金额计算为 0用户下单不要钱半小时后才被发现。这就是边界条件没验证的代价。3.2 边界验证的四个必查维度我总结了一个“边界四查”清单每次 AI 生成核心业务逻辑后必须逐个过一遍空值与空集合入参为 null、空字符串、空列表时代码是否还能正常执行会不会抛 NPE 或者返回错误结果数值边界最大值、最小值、零、负数、超大数比如Integer.MAX_VALUE传入时计算是否会溢出或逻辑错乱并发边界同一份数据被多个线程同时读写时会不会出现脏读、覆盖、死锁AI 生成的代码默认是单线程思维这点尤其要注意。状态边界对象处于“未初始化”“已关闭”“已过期”等特殊状态时方法调用是否安全这四个维度我建议你写成单元测试用例每个维度至少覆盖 2 到 3 个 case。AI 生成的代码单元测试覆盖率往往很低补上这些测试不仅能验证逻辑还能作为后续回归的保障。3.3 实操用单元测试“逼”出逻辑漏洞具体做法针对 AI 生成的每个 public 方法写一组参数化测试。以 Java 为例用 JUnit 5 的ParameterizedTest配合NullSource、EmptySource、ValueSource把 null、空值、边界值一次性喂进去。ParameterizedTest NullSource EmptySource ValueSource(strings {, , , a.repeat(10000)}) void testProcessInput(String input) { // 调用 AI 生成的方法观察是否抛异常或返回异常结果 assertDoesNotThrow(() - service.process(input)); }跑一遍如果 AI 代码在这些输入下抛异常或者返回了不符合预期的结果那就说明边界处理缺失必须补上。这个步骤花不了多少时间但能挡住大量线上问题。注意不要只测“正常值”。AI 代码在正常值下几乎不会出错测了也是白测。要把精力集中在“异常值”和“极端值”上这才是 AI 的软肋。4. 第三道检查性能与资源消耗评估4.1 本地快不等于线上稳性能问题是最隐蔽的。AI 生成的代码在本地跑数据量小响应飞快你根本感觉不到问题。但生产环境的数据量、并发量、网络延迟和本地完全不是一个量级。一个在本地 10ms 返回的接口到了线上可能因为一条没走索引的 SQL变成 3 秒超时。我印象很深的一次AI 帮我写了一个“查询用户最近 30 天订单”的方法逻辑没问题但生成的 SQL 是SELECT * FROM orders WHERE user_id ? AND create_time ?而create_time字段上没有索引。本地测试数据只有几百条查询飞快。上线后订单表几百万数据这个查询直接全表扫描数据库 CPU 飙到 90%拖垮了整个订单服务。后来加了一个联合索引才解决。4.2 性能评估的三个核心指标AI 代码上线前我重点关注三个指标SQL 执行计划所有涉及数据库查询的代码必须用EXPLAIN看一遍执行计划确认走了索引没有全表扫描没有临时表排序。循环与递归复杂度AI 生成的代码里嵌套循环和递归是性能杀手。看到双层以上循环就要警惕时间复杂度是不是 O(n²) 甚至更高。内存占用一次性把大量数据加载到内存比如SELECT不加LIMIT、List无限增长在生产环境极易引发 OOM。这三个指标不需要复杂的压测工具用EXPLAIN、代码 review 和简单的内存分析就能覆盖大部分场景。4.3 实操SQL 执行计划与循环复杂度检查SQL 这块直接把 AI 生成的 SQL 拿到数据库客户端里前面加EXPLAIN看type列。如果是ALL说明全表扫描必须优化如果是index或ref基本可以接受。另外看rows列预估扫描行数如果超过万级就要考虑加索引或改写查询。循环复杂度这块我一般用 IDEA 的插件或者 SonarQube 的“认知复杂度”指标。一个方法的认知复杂度超过 15就说明逻辑太绕AI 生成的代码尤其容易在这项上超标。超标的方法要么拆分要么重写。-- 检查 AI 生成的 SQL 是否走索引 EXPLAIN SELECT * FROM orders WHERE user_id 123 AND create_time 2024-01-01; -- 关注 type 列ALL 表示全表扫描需优化 -- 关注 rows 列预估扫描行数过大需加索引提示AI 生成的 SQL 经常忽略LIMIT查询列表时一定要手动加上分页否则数据量一大内存直接爆掉。5. 第四道检查安全与生产环境适配5.1 安全问题是“一票否决”前三道检查过了代码基本能跑了但能不能“安全地跑”还得看第四道。安全问题在生产环境是“一票否决”的——一个 SQL 注入漏洞可能让整个数据库被拖走一个硬编码的密钥可能让第三方服务被恶意调用。AI 生成的代码在安全方面往往“天真得可爱”它不会主动帮你做参数化查询也不会提醒你日志里别打印敏感信息。我遇到过 AI 生成的代码里直接把数据库密码写在了main方法里理由是“方便测试”。这要是上了生产代码一提交密码就进了版本库后果不堪设想。5.2 生产适配的四个必查项上线前我会重点检查这四个方面SQL 注入防护所有数据库操作必须使用参数化查询PreparedStatement或 ORM 框架严禁字符串拼接 SQL。敏感信息硬编码密码、密钥、Token 一律走配置中心或环境变量代码里不能出现明文。日志脱敏用户手机号、身份证号、银行卡号等敏感字段打印日志时必须脱敏。配置隔离开发、测试、生产的配置必须分离AI 生成的代码经常把测试环境的地址写死上线前必须改成可配置项。这四项里任何一项出问题都可能导致严重的安全事故。尤其是 SQL 注入和硬编码AI 生成的代码命中率相当高。5.3 实操安全扫描与配置检查安全扫描可以用OWASP Dependency-Check或者公司内部的 SAST 工具重点看有没有 SQL 注入、XSS、硬编码密钥等告警。配置检查更简单直接全局搜索代码里的password、secret、key、token等关键词看看有没有明文。# 全局搜索可能的硬编码敏感信息 grep -rn password\|secret\|token\|apiKey src/main/java/ # 检查是否有字符串拼接 SQL grep -rn SELECT.*.*FROM\|WHERE.*.* src/main/java/这两条命令跑一遍基本能把明显的安全隐患筛出来。剩下的靠代码 review 和上线前的安全评审兜底。注意AI 生成的代码里日志打印经常“过于详细”把整个对象都toString()出来。如果这个对象包含敏感字段日志里就会留下明文。上线前一定要检查日志打印语句该脱敏的脱敏该删的删。6. 四道检查走完AI 代码才敢上生产6.1 我的上线检查清单四道检查走完我会填一张上线检查清单每一项都打勾了才允许合并到发布分支。这张清单长这样检查项检查内容是否通过静态扫描SonarQube 无阻断级问题代码异味已处理□边界验证空值、边界值、并发场景单元测试通过□性能评估SQL 走索引无嵌套循环无内存泄漏风险□安全适配无 SQL 注入无硬编码日志已脱敏□配置隔离生产配置独立无测试地址硬编码□这张清单看起来简单但每一项背后都是实打实的检查动作。我坚持用这张清单是因为它帮我挡掉了至少三次可能的生产事故。有一次 AI 生成的代码在静态扫描时发现了一个空指针风险当时觉得“应该不会触发”但还是补了判空。结果上线后第三天真的有一个边界数据触发了那个空指针因为提前补了判空接口只是返回了默认值没有报错。那一刻我就知道这四道检查没白做。6.2 几个容易忽略的细节最后分享几个我在实操中总结的细节都是常规文档里不会写的AI 生成的代码注释往往是“废话”。比如// 设置名称这种看了等于没看。上线前把这类注释删掉换成真正有价值的说明比如“此处判空是因为上游接口可能返回 null”。AI 喜欢用System.out.println调试。上线前全局搜索一下把这些调试输出全部换成日志框架否则生产日志里全是乱七八糟的输出。AI 生成的异常处理经常只打印e.getMessage()。这会导致堆栈丢失排查问题时根本不知道异常从哪来。改成log.error(xxx, e)把完整堆栈打出来。AI 生成的代码方法参数经常超过 5 个。参数太多不仅难维护还容易传错顺序。上线前考虑封装成对象或者用 Builder 模式重构。这些细节单看都是小事但累积起来就是“AI 代码能不能上生产”的关键。AI 是个好帮手但它不是工程师。它能帮你写代码但不能替你负责。上线前这四道检查就是你把“AI 的代码”变成“你的代码”的过程。走完这四道你才敢说这段代码我敢让它上生产。
