AI 辅助 Code Review：我用了这套提示词，每次能发现至少 3 个人工容易漏掉的隐患

上一篇我们聊了 AI 代码 Bug 怎么排查。但与其等出了 Bug 再修不如在合并代码之前就把它们找出来。这篇分享我用 AI 做 Code Review 的完整方法——一套提示词模板 真实案例对比 人工 Review 容易漏什么。一、为什么让 AI 参与 Code Review先说一个扎心的事实多数团队的 Code Review 是走形式。实际工作中 Code Review 的常见状态 场景 APR 太大Reviewer 花了 30 秒写了 LGTMLooks Good To Me 场景 BReviewer 只看代码风格——变量命名、缩进、注释 场景 CReviewer 认真看了但漏掉了边界条件、并发问题、安全漏洞 场景 DReviewer 自己也在赶需求根本没时间 Review这些问题不是 Reviewer 不负责而是人的注意力有限。一段 500 行的 PR人要逐行检查边界条件、错误处理、并发安全——这本身就是反人类的。AI 恰好擅长做这件事。它不会累、不会赶时间、不会因为和你是熟人而手下留情。但直接丢一句「帮我看这段代码有什么问题」AI 的回复通常是泛泛而谈的「这段代码看起来还不错可以考虑加一些注释」。关键不在「用不用 AI」在于「怎么问」。二、我实测了 5 套提示词选出效果最好的 3 套我拿同一个项目里 5 个真实的 PR 做测试每套提示词针对不同的 Review 维度。提示词 A安全检查 —— 排查安全漏洞和敏感信息这套提示词专门用来查安全问题——人工 Review 最容易漏的领域。请对以下代码进行安全审查重点检查 1. 硬编码的密钥/Token/密码 - 代码中是否有直接写死的 API Key、数据库密码、JWT Secret - 环境变量是否被正确引用而不是直接暴露值 2. 敏感信息泄露 - 日志中是否打印了用户密码、Token、手机号等敏感信息 - 错误信息返回给前端时是否暴露了数据库结构或堆栈信息 3. 注入风险 - SQL 查询是否使用了参数化查询而不是字符串拼接 - 用户输入是否经过了验证和转义 4. 权限与认证 - 接口是否都有正确的权限校验 - Token 过期处理是否完善 5. 依赖安全 - 是否引用了已弃用或有已知漏洞的库 代码 [粘贴代码]真实案例用这套提示词审查一个用户管理模块的代码AI 发现了 3 个安全问题发现问题 1日志中打印了明文密码 console.log(User login:, { username, password }) → 攻击者拿到日志文件就能获取所有用户的密码 发现问题 2数据库密码硬编码在代码里 const db new Sequelize(mysql://root:admin123localhost:3306/mydb) → 应该改成 process.env.DATABASE_URL 发现问题 3接口没有频率限制 POST /api/login 没有 rate limiting → 可以暴力破解用户密码这三个问题人工 Review 很可能只看业务逻辑不会注意到安全细节。提示词 B健壮性检查 —— 排查边界条件和异常处理这套提示词专门排查代码在「非正常情况」下的表现。请对以下代码进行健壮性审查假设一切可能出错的地方都会出错 1. 空值与边界 - 数组为空时map/filter/reduce 是否会出错 - 对象属性不存在时是否会导致 undefined 传播 - 数字计算是否会溢出、除零、NaN 2. 异步与并发 - Promise 是否都有 catch 或 try/catch - 是否存在竞态条件多个请求同时修改同一数据 - 定时器/setInterval 在组件销毁时是否清除 3. 接口失败处理 - 接口调用失败时用户看到的是什么白屏转圈 - 失败后是否有重试机制重试几次间隔多久 - 部分数据加载失败时已加载的数据是否正常显示 4. 内存与性能 - 是否存在闭包导致的内存泄漏 - 大列表是否使用了虚拟滚动或分页 - 是否有不必要的重复渲染 代码 [粘贴代码]真实案例审查一个文章列表组件// 原始代码constfetchArticlesasync(){constresawaitapi.getArticles()articles.valueres.data.map(item({...item,createdAt:formatDate(item.createdAt)}))}AI 发现了 4 个隐患隐患 1res.data 可能为 null/undefined → res.data.map() → Uncaught TypeError: Cannot read property map of null 修复const list res.data || []; articles.value list.map(...) 隐患 2item.createdAt 可能为 null → formatDate(null) 可能返回 Invalid Date 或报错 修复formatDate(item.createdAt || ) 隐患 3没有 try/catch → 接口失败时用户看到白屏没有任何提示 修复加 try/catch error 提示 隐患 4没有 loading 状态 → 页面初始状态是空列表用户不知道数据在加载中 修复加 loading.value true/false修复后的代码constfetchArticlesasync(){loading.valuetruetry{constresawaitapi.getArticles()constlistres?.data??[]articles.valuelist.map(item({...item,createdAt:formatDate(item.createdAt??)}))}catch(error){ElMessage.error(获取文章列表失败)}finally{loading.valuefalse}}提示词 C可维护性检查 —— 排查代码坏味道这套提示词关注代码的长期健康度。请对以下代码进行可维护性审查从「三个月后的自己还能看懂吗」的角度 1. 命名 - 变量、函数、组件的命名是否准确表达了它们的用途 - 是否有 data、info、temp 这类模糊命名 - 是否使用了行业通用命名惯例 2. 职责单一 - 每个函数是否只做一件事 - 是否存在超过 50 行的函数是否能拆分 - 组件是否承担了过多的职责 3. 重复代码 - 是否有相同的逻辑出现在多个地方 - 是否可以抽取为共用函数或 composable 4. 注释与文档 - 复杂的业务逻辑是否有注释解释「为什么这么做」 - 是否有注释在描述「做了什么」代码本身就能看出来 5. 硬编码 - 是否有写死的魔法数字 - 业务常量是否集中管理 代码 [粘贴代码]真实案例审查一段权限校验代码// 原始代码if(user.role1){router.push(/admin)}elseif(user.role2){router.push(/editor)}elseif(user.role3){router.push(/viewer)}AI 的建议问题魔法数字 无扩展性 三个问题 1. role 1 是什么意思三个月后你还会记得吗 2. 如果要加第 4 种角色需要修改这里的 else-if 链 3. 业务逻辑散落在各个文件里改一处漏一处 建议修改为 // constants/roles.ts export const ROLES { ADMIN: 1, EDITOR: 2, VIEWER: 3, } as const export const ROLE_ROUTES { [ROLES.ADMIN]: /admin, [ROLES.EDITOR]: /editor, [ROLES.VIEWER]: /viewer, } // 使用时 import { ROLES, ROLE_ROUTES } from /constants/roles const targetRoute ROLE_ROUTES[user.role] if (targetRoute) { router.push(targetRoute) }三、AI Review vs 人工 Review真实对比我拿同一个 PR约 450 行代码包含 3 个功能模块分别做了一次人工 Review我自己和 AI ReviewClaude 上面 3 套提示词对比结果维度人工 ReviewAI Review耗时约 25 分钟约 3 分钟发现 Bug 数2 个5 个发现安全问题0 个2 个发现边界条件问题1 个6 个发现代码坏味道3 个4 个发现可维护性问题2 个3 个AI 发现的、人工漏掉的典型问题问题 1竞态条件人工容易忽略// 原始代码用户快速切换标签页watch(tab,async(newTab){constdataawaitfetchTabData(newTab)tabData.valuedata})AI 指出如果用户快速切换标签页后发起的请求可能先返回导致显示的数据和当前标签页不对应。修复方案使用请求标记或 AbortController。问题 2JSON.parse 没有 try/catch人工容易忽略constconfigJSON.parse(localStorage.getItem(userConfig))AI 指出如果 localStorage 里的数据被手动修改导致格式错误整个页面会崩溃。修复方案letconfig{}try{configJSON.parse(localStorage.getItem(userConfig)||{})}catch{localStorage.removeItem(userConfig)}问题 3正则表达式 ReDoS 风险人工基本不会注意到AI 发现了某个表单验证的正则有灾难性回溯风险——输入特定字符串会导致 CPU 100%。四、我的 Code Review 工作流经过几个月的实践我总结出了这个流程第 0 步提交者自己AI 预审 ├── 提交 PR 之前先用 3 套提示词过一遍自己的代码 ├── 修掉 AI 找到的明显问题 └── 人工 Reviewer 的时间不要浪费在修低级错误上 第 1 步AI 自动审查PR 提交后 ├── 用提示词 A安全过一遍 ├── 用提示词 B健壮性过一遍 ├── 用提示词 C可维护性过一遍 └── 把 AI 的发现整理成评论贴在 PR 里 第 2 步人工审查AI 审完之后 ├── 确认 AI 的发现AI 也会有误报 ├── 关注 AI 不擅长的领域业务逻辑正确性、架构设计合理性 └── LGTM ✅关键原则AI 做初筛人做终审。AI 擅长找模式匹配的问题安全漏洞、空值检查、重复代码但在「这个业务逻辑是否符合需求」这个问题上完全是盲的。五、AI Code Review 的局限性必须说清楚知道 AI 会在哪里「翻车」比知道它哪里强更重要局限 1不懂业务逻辑AI 看到的if (status pending) { sendEmail() } AI 的评论代码看起来没问题 实际业务需求pending 状态下不应该发邮件要等 confirmed 状态局限 2过度保守的误报AI这个 SQL 没有加 LIMIT可能导致全表查询 实际这张表总共就 50 行加 LIMIT 反而增加了代码复杂度局限 3不了解团队约定AI建议用 async/await 替代 .then() 实际这个项目的历史代码都用 .then()保持风格一致更重要局限 4不看上下文只看代码片段AI这个函数可以抽取为公共工具函数 实际它依赖了当前模块的私有状态抽取出去反而增加耦合六、不同 AI 做 Code Review 的对比AI安全检查健壮性检查可维护性误报率Claude⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐低ChatGPT⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐中Copilot⭐⭐⭐⭐⭐⭐⭐⭐⭐中通义灵码⭐⭐⭐⭐⭐⭐⭐高建议日常用 Claude 或 ChatGPT 做 AI Review。Copilot 更适合写代码时的实时提示通义适合中文场景但误报偏多。七、三套提示词速查卡复制即用 安全检查对以下代码进行安全审查 1. 硬编码密钥/密码 2. 敏感信息泄露日志、错误信息 3. 注入风险SQL、XSS 4. 权限校验是否完整 5. 依赖是否有已知漏洞 代码[粘贴] 健壮性检查对以下代码进行健壮性审查 1. 空值与边界条件 2. 异步错误处理与竞态条件 3. 接口失败的用户体验 4. 内存泄漏与性能问题 代码[粘贴] 可维护性检查对以下代码进行可维护性审查 1. 命名是否准确表达意图 2. 是否有超过50行的函数需要拆分 3. 是否有重复代码可以抽取 4. 是否有硬编码的魔法数字 5. 复杂逻辑是否有注释 代码[粘贴]写在最后Code Review 这件事本质不是「找茬」是「减少线上事故」。AI 不能替代有经验的 Reviewer 对业务逻辑的判断但它能让 Reviewer 把精力集中在真正需要人类判断力的地方而不是瞪大眼睛找变量名拼写错误。建议从下一个 PR 就开始试提交前先用 AI 过一遍看看你会发现什么。如果这篇文章对你有帮助欢迎分享给团队里的同事。你试过用 AI 做 Code Review 吗欢迎留言交流你的体验。