我以为 AI 只会挑缩进和命名这种格式问题。结果它揪出我一个空指针隐患我脸有点挂不住。自己看自己的代码眼睛会自动跳过 bug这是真的。你刚写完一段逻辑脑子里还是我打算让它这样跑的预设review 的时候就容易顺着预设看跳过真正的问题。同事 review 也费眼——大家都忙很多时候扫一眼就过了看起来没问题就 approve 了。工具把 diff 贴给任意大模型就行不用接 CI/CD 流水线不用装任何插件不用配 GitHub App。最简方案只需要两步第一步导出 diff# 导出本次 MR/PR 相对于主分支的所有变更gitdifforigin/main...HEADmr.diff# 查看概况echo变更统计:wc-lmr.diff# 总行数grep^mr.diff|wc-l# 新增行数grep^-mr.diff|wc-l# 删除行数第二步贴给 AI 提示词打开千问 / 豆包 / ChatGPT / Claude先粘贴 diff 内容再贴这段提示词下面是本次改动的 git diff。 请只从逻辑、边界、异常处理的角度做 code review 列出具体风险点和修复建议。 ⚠️ 不要改代码风格不要挑缩进和命名。 那些留给 linter 和 formatter 去管。 重点关注这五类问题 1. 空指针NPE — Optional.get() 未判空 — Map.get() 返回值直接用 — 方法链式调用中间可能返回 null 2. 越界访问 — 数组/列表索引越界 — substring 截取范围未校验 3. 并发安全 — 共享变量无 synchronized / 无锁 — 非线程安全的集合在多线程环境使用 4. 资源泄漏 — Stream / Connection / InputStream 未 close — finally 块中缺少清理逻辑 5. 边界条件 — 空集合传入遍历 - null 入参未 guard — 极端值0, MAX_VALUE, 负数 输出格式 严重[文件:行号] [问题描述] → [建议修复方式] ⚠️ 建议[文件:行号] [问题描述] → [建议修复方式] ✅ OK [做得好的地方简要表扬]它真挑出了我忽略的空指针那段代码我读了三遍没发现问题。代码长这样// 旧代码有 bugpublicStringgetUserName(LonguserId){UseruuserRepo.findById(userId);// 返回 OptionalUserreturnu.getName();// ← 直接用如果 userId 不存在呢}问题在于findById()返回的是OptionalUser但代码直接.getName()没做任何判空处理。这个 key 在某种边界情况下压根没 put 进去——平时测试数据都覆盖了线上偶发就炸。AI 一句话点破“若 key 不存在getValue() 返回 null后续 .toString() 会 NPE。建议使用 orElseThrow() 或 ifPresent() 做防御性处理。”我愣了三秒。这确实是我的盲区——我自己写的代码脑子里它一定有值的预设太强了。那一刻有点羞耻但更多的是庆幸——这要是上线了又得半夜被报警叫醒别问我怎么知道的凌晨三点的钉钉电话谁接谁知道。修复后// 新代码安全publicStringgetUserName(LonguserId){returnuserRepo.findById(userId).map(User::getName).orElseThrow(()-newNotFoundException(用户不存在: userId));}踩坑它也会误报别全信公平说AI review 不是全对。我用了几十次后的经验情况频率怎么处理真 bug像上面的 NPE~60%直接修感谢 AI有道理但优先级不高~25%记到待办不阻塞合并误报它理解错了上下文~15%忽略不加评论典型误报场景它把防御性代码当成冗余建议你删掉 →别删防御性代码是你的安全网它对你们框架的自定义注解不熟悉瞎指一气 →忽略框架相关的误报它建议你用最新语法/API 但你们项目还在用老版本 →按项目规范来所以用法是它当第一道筛子你当最后一道关。它列的风险点你逐条判断真不真、修不修。我那次 NPE 是对的但十次里大概有两三次是误报得你自己兜底。完整工作流每个 MR 必走一遍本地开发完成 ↓ git push origin feature/xxx ↓ 创建 MR / PR ↓ ① git diff mr.diff ← 导出 diff ↓ ② 贴给 AI review 提示词 ← AI 初筛2 分钟 ↓ ③ 逐条判断 AI 的意见 ← 你当最后一道关5 分钟 ↓ ④ 自己再看一遍整体逻辑 ← 补 AI 看不到的架构视角3 分钟 ↓ ⑤ 修改确认的问题 ← 推送 fix commit ↓ ⑥ 合并 MR ← ✅ 完成总耗时约 10–15 分钟/MR纯人工 review 通常要 30–40 分钟量化效果指标纯人工 reviewAI 辅助 review每个 MR 耗时30–40 分钟10–15 分钟漏掉的 bug偶有遗漏人眼疲劳显著减少AI 不疲劳一年省下时间—约 80–100 小时最有价值的事—替你挡住线上事故我现在合 MR 前都先过一遍 AI review再自己看。一年几百个 MR省出来的时间够我多带小覃写两个模块。更重要的是它替我挡掉的几个隐患换成线上事故就是半夜救火 全群 你。 我把代码审查交给了 AI，结果反被它教育了
我以为 AI 只会挑缩进和命名这种格式问题。结果它揪出我一个空指针隐患我脸有点挂不住。自己看自己的代码眼睛会自动跳过 bug这是真的。你刚写完一段逻辑脑子里还是我打算让它这样跑的预设review 的时候就容易顺着预设看跳过真正的问题。同事 review 也费眼——大家都忙很多时候扫一眼就过了看起来没问题就 approve 了。工具把 diff 贴给任意大模型就行不用接 CI/CD 流水线不用装任何插件不用配 GitHub App。最简方案只需要两步第一步导出 diff# 导出本次 MR/PR 相对于主分支的所有变更gitdifforigin/main...HEADmr.diff# 查看概况echo变更统计:wc-lmr.diff# 总行数grep^mr.diff|wc-l# 新增行数grep^-mr.diff|wc-l# 删除行数第二步贴给 AI 提示词打开千问 / 豆包 / ChatGPT / Claude先粘贴 diff 内容再贴这段提示词下面是本次改动的 git diff。 请只从逻辑、边界、异常处理的角度做 code review 列出具体风险点和修复建议。 ⚠️ 不要改代码风格不要挑缩进和命名。 那些留给 linter 和 formatter 去管。 重点关注这五类问题 1. 空指针NPE — Optional.get() 未判空 — Map.get() 返回值直接用 — 方法链式调用中间可能返回 null 2. 越界访问 — 数组/列表索引越界 — substring 截取范围未校验 3. 并发安全 — 共享变量无 synchronized / 无锁 — 非线程安全的集合在多线程环境使用 4. 资源泄漏 — Stream / Connection / InputStream 未 close — finally 块中缺少清理逻辑 5. 边界条件 — 空集合传入遍历 - null 入参未 guard — 极端值0, MAX_VALUE, 负数 输出格式 严重[文件:行号] [问题描述] → [建议修复方式] ⚠️ 建议[文件:行号] [问题描述] → [建议修复方式] ✅ OK [做得好的地方简要表扬]它真挑出了我忽略的空指针那段代码我读了三遍没发现问题。代码长这样// 旧代码有 bugpublicStringgetUserName(LonguserId){UseruuserRepo.findById(userId);// 返回 OptionalUserreturnu.getName();// ← 直接用如果 userId 不存在呢}问题在于findById()返回的是OptionalUser但代码直接.getName()没做任何判空处理。这个 key 在某种边界情况下压根没 put 进去——平时测试数据都覆盖了线上偶发就炸。AI 一句话点破“若 key 不存在getValue() 返回 null后续 .toString() 会 NPE。建议使用 orElseThrow() 或 ifPresent() 做防御性处理。”我愣了三秒。这确实是我的盲区——我自己写的代码脑子里它一定有值的预设太强了。那一刻有点羞耻但更多的是庆幸——这要是上线了又得半夜被报警叫醒别问我怎么知道的凌晨三点的钉钉电话谁接谁知道。修复后// 新代码安全publicStringgetUserName(LonguserId){returnuserRepo.findById(userId).map(User::getName).orElseThrow(()-newNotFoundException(用户不存在: userId));}踩坑它也会误报别全信公平说AI review 不是全对。我用了几十次后的经验情况频率怎么处理真 bug像上面的 NPE~60%直接修感谢 AI有道理但优先级不高~25%记到待办不阻塞合并误报它理解错了上下文~15%忽略不加评论典型误报场景它把防御性代码当成冗余建议你删掉 →别删防御性代码是你的安全网它对你们框架的自定义注解不熟悉瞎指一气 →忽略框架相关的误报它建议你用最新语法/API 但你们项目还在用老版本 →按项目规范来所以用法是它当第一道筛子你当最后一道关。它列的风险点你逐条判断真不真、修不修。我那次 NPE 是对的但十次里大概有两三次是误报得你自己兜底。完整工作流每个 MR 必走一遍本地开发完成 ↓ git push origin feature/xxx ↓ 创建 MR / PR ↓ ① git diff mr.diff ← 导出 diff ↓ ② 贴给 AI review 提示词 ← AI 初筛2 分钟 ↓ ③ 逐条判断 AI 的意见 ← 你当最后一道关5 分钟 ↓ ④ 自己再看一遍整体逻辑 ← 补 AI 看不到的架构视角3 分钟 ↓ ⑤ 修改确认的问题 ← 推送 fix commit ↓ ⑥ 合并 MR ← ✅ 完成总耗时约 10–15 分钟/MR纯人工 review 通常要 30–40 分钟量化效果指标纯人工 reviewAI 辅助 review每个 MR 耗时30–40 分钟10–15 分钟漏掉的 bug偶有遗漏人眼疲劳显著减少AI 不疲劳一年省下时间—约 80–100 小时最有价值的事—替你挡住线上事故我现在合 MR 前都先过一遍 AI review再自己看。一年几百个 MR省出来的时间够我多带小覃写两个模块。更重要的是它替我挡掉的几个隐患换成线上事故就是半夜救火 全群 你。