很多开发团队 Leader 都遇到过一个尴尬场景：需求催得急，代码合并得快，Review 却越来越像“走流程”。变量命名不统一、异常没处理、权限校验漏了一行，这些问题单看不大，但上线后可能就是一次故障复盘。最近我在做 AI 辅助 Code Review 测试时，为了方便对比不同模型的审查结果，也会借助一些在线工具快速切换模型，其中库拉AI镜像平台使用门槛较低，能直接体验多个主流 AI 模型，适合作为临时验证与效率辅助入口。
一、为什么要测试 AI 做 Code Review？
先说结论：AI 目前还不能完全替代资深工程师做代码审查，但它已经可以承担一部分“第一轮筛查”的工作。
传统 Code Review 里，Leader 或核心开发经常要关注三类问题：
问题在于，人会疲劳。尤其在一个 MR 里同时出现业务逻辑、SQL、接口权限和异常处理时，人工审查很容易只盯主流程，忽略边界分支。
这次测试的重点，是观察 Gemini 3.5 在以下场景中的表现：
- 能否识别明显漏洞
- 能否发现不规范写法
- 能否给出可落地修改建议
- 是否会出现“看似专业但不准确”的判断
二、测试样例：一段常见的接口代码
下面是一段简化后的 Java Spring Boot 接口代码，模拟后台管理系统中的用户查询接口。
java
@RestController
@RequestMapping("/api/user")
public class UserController {
@Autowired
private JdbcTemplate jdbcTemplate;
@GetMapping("/search")
public List<Map<String, Object>> searchUser(String keyword, String role) {
String sql = "select id, username, phone, role from users where username like '%"
+ keyword + "%'";
if (role != null && !"".equals(role)) {
sql += " and role = '" + role + "'";
}
return jdbcTemplate.queryForList(sql);
}
}
这段代码看起来很短，也能跑通。但如果让有经验的开发看，问题其实不少。
我把这段代码交给 Gemini 3.5，让它从安全性、规范性、可维护性三个角度做审查，并要求输出问题等级和修改建议。
三、Gemini 3.5 发现了哪些问题？
从结果看，它首先指出了 SQL 拼接风险，也就是典型的 SQL 注入问题。
例如 keyword 和 role 都来自用户输入，直接拼到 SQL 里。如果传入特殊字符，就可能改变查询逻辑。
它给出的建议是使用参数化查询：
java
@GetMapping("/search")
public List<Map<String, Object>> searchUser(String keyword, String role) {
StringBuilder sql = new StringBuilder(
"select id, username, phone, role from users where username like ?"
);
List<Object> params = new ArrayList<>();
params.add("%" + keyword + "%");
if (role != null && !role.isBlank()) {
sql.append(" and role = ?");
params.add(role);
}
return jdbcTemplate.queryForList(sql.toString(), params.toArray());
}
这个判断是准确的，也是 AI 在代码审查里比较擅长的部分：发现模式明确、训练样本丰富的问题。
比如 SQL 注入、空指针风险、硬编码密钥、资源未关闭、异常吞掉等，都属于比较容易被识别的类型。
四、规范性问题：AI 的提醒有参考价值
除了安全问题，Gemini 3.5 还指出了一些工程规范上的不足。
比如：
- Controller 层直接写 SQL，不利于分层
- 使用 Map<String, Object> 返回结果，可读性较差
- 缺少参数校验
- 没有分页，可能导致一次查询返回过多数据
- @Autowired 字段注入不如构造器注入清晰
这些建议不一定都必须修改，但很适合团队 Leader 用来做 Review Checklist。
例如将返回值改为 DTO：
java
public class UserSearchResponse {
private Long id;
private String username;
private String phone;
private String role;
// getter/setter
}
再比如补充分页参数：
java
@GetMapping("/search")
public Page<UserSearchResponse> searchUser(
@RequestParam String keyword,
@RequestParam(required = false) String role,
@RequestParam(defaultValue = "1") int page,
@RequestParam(defaultValue = "20") int size) {
// 查询逻辑
}
在真实团队中，这类问题经常不是“会不会写”，而是“忙起来会不会漏”。AI 的价值就在于，它可以稳定地提醒那些容易被忽略的细节。
五、潜在漏洞识别：表现不错，但不能盲信
我又加入了一段权限相关代码：
java
@GetMapping("/{id}")
public UserDetail getUser(@PathVariable Long id) {
return userService.getUserDetail(id);
}
如果这是后台系统接口，表面上看没有问题。但它缺少鉴权逻辑，也没有判断当前登录用户是否有权限查看该用户信息。
Gemini 3.5 给出的反馈是：需要确认接口是否经过统一认证拦截，如果没有，应补充权限校验。
这个回答比较谨慎，没有直接断定“存在漏洞”，而是提醒结合项目架构判断。我认为这是比较好的审查方式。
因为在很多项目中，权限可能放在：
- 网关层
- Filter 或 Interceptor
- AOP 注解
- Spring Security 配置
- 统一权限服务
如果 AI 在不了解上下文的情况下直接下结论，反而容易误导开发者。
所以，对团队 Leader 来说，更合理的用法是：让 AI 提供风险线索，再由人工结合系统设计做最终判断。
六、AI 容易漏掉什么？
测试中也发现，Gemini 3.5 对“业务语义类问题”的判断并不稳定。
例如下面的逻辑：
java
public BigDecimal calculateDiscount(BigDecimal amount, Integer level) {
if (level == 1) {
return amount.multiply(new BigDecimal("0.95"));
}
if (level == 2) {
return amount.multiply(new BigDecimal("0.90"));
}
return amount;
}
如果业务规则是“等级越高折扣越大”，那这段代码可能没问题。但如果公司真实规则是 level 1 享受 9 折、level 2 享受 95 折，AI 很难凭代码本身判断。
它可能会提醒：
- 缺少枚举
- 魔法值需要抽取
- 金额计算要注意精度
- 需要补充单元测试
这些建议都对，但它无法确认业务规则本身是否正确。
这说明 AI 更适合发现“代码层面的坏味道”，不适合单独判断“业务需求是否实现正确”。
七、建议的落地流程：别让 AI 直接拍板
如果团队想引入 AI 辅助 Code Review，我建议不要一上来就追求自动化拦截，而是先从“辅助审查”开始。
一个比较稳妥的流程是：
这样做的好处是，AI 负责“扫雷”，人负责“判断”。
尤其对 Leader 来说，真正有价值的不是让 AI 多说几句，而是把它的输出变成团队规范。
比如可以要求 AI 每次按固定格式输出：
text
【风险等级】高 / 中 / 低
【问题位置】类名、方法名、代码片段
【问题说明】为什么可能有风险
【修改建议】推荐修改方式
【是否必须修改】是 / 否 / 需人工判断
统一格式后，Review 结果更容易被团队吸收，也方便后续复盘。
八、最终评价：适合作为代码审查的“前置过滤器”
综合测试来看，Gemini 3.5 在 Code Review 中的表现可以概括为三点：
第一，对常见安全风险识别较好。
像 SQL 注入、空指针、异常处理、敏感信息暴露这类问题，它通常能给出有效提醒。
第二，对代码规范和可维护性建议比较实用。
它能帮助团队发现命名、分层、参数校验、返回结构等方面的细节问题。
第三，对业务正确性和复杂架构理解有限。
涉及上下文、权限体系、交易一致性、领域规则时，仍然需要资深开发做最终判断。
所以，AI 辅助代码审查的合理定位不是“替代 Reviewer”，而是“提升 Reviewer 的起点”。
对于开发团队 Leader 来说，它最适合用在三类场景：
- 新人代码提交前自查
- 大 MR 合并前预扫描
- 团队规范落地时生成检查清单
如果使用得当，它可以减少低级问题进入人工 Review 的概率，让团队把时间花在更关键的架构设计、业务边界和线上稳定性上。
一句话总结：AI 不能替你承担代码质量责任，但可以帮你更早发现那些本不该进入主分支的问题。
