现在很多人用 AI 代码助手第一反应是“让它帮我把功能写出来”。但我这段时间越来越觉得AI 最值得用的场景之一不是替你写代码而是帮你做第一轮 Code Review。原因很简单写代码时我们容易带着自己的假设往前冲AI 虽然不一定总是对但很适合扮演一个“不懂业务、但会追问细节的实习生”。你给它足够上下文它就能帮你把一些低级坑提前暴露出来。这篇文章不讲玄学提示词也不承诺“用了就零 bug”。我只分享一套我自己会反复使用的检查清单适合前端、后端、脚本工具、小型开源项目都拿来改一改。一、先别让 AI 直接评价代码先让它复述需求很多 AI Review 失败不是模型能力不行而是我们一上来就把一大段代码丢过去问“有没有问题”更稳的做法是先让它复述需求你先不要评价代码。 请根据下面的需求和代码用 5 条以内的要点复述 1. 这段代码想解决什么问题 2. 输入和输出分别是什么 3. 你认为最关键的业务约束是什么 4. 哪些信息不明确需要向我确认。这一步的价值在于如果 AI 连需求都理解偏了后面的建议大概率也会跑偏。先校准再 Review。二、我的第一轮检查需求边界是否被写进代码很多线上问题并不是算法错而是边界条件没写清楚。可以让 AI 专门检查这些问题空值、空数组、空字符串是否处理超长输入、非法输入、重复请求是否处理分页、排序、过滤条件是否有默认值时间、时区、金额、精度是否容易出错权限判断是否出现在真正执行动作之前。我常用的提问是请只从“边界条件”角度 Review 这段代码。 不要泛泛而谈请按表格输出 边界场景 / 当前代码表现 / 潜在风险 / 建议修改方式。 如果某项无法判断请明确写“上下文不足”。注意最后一句“上下文不足”。这能减少 AI 强行脑补业务规则。三、第二轮检查数据流有没有被说清楚代码越复杂越应该让 AI 画出数据流而不是只盯着某一行语法。可以这样问请按步骤描述这段代码的数据流 输入从哪里来经过哪些转换最终写到哪里或返回给谁。 请标出每一步可能失败的位置以及失败时当前代码如何处理。这类问题特别适合检查接口层、任务脚本、ETL、消息消费、文件处理等逻辑。很多隐藏问题会在“数据从 A 到 B 的过程中”暴露比如字段名在中间被改了但后面还用旧字段异常被捕获后只打印日志没有返回错误状态数据库写入成功了但缓存没有同步循环中某一步失败导致后续数据部分成功、部分失败。四、第三轮检查异常处理是不是“看起来有实际上没用”不少代码表面有 try/catch实际上只是把错误吞掉。AI 很适合帮你找这种“伪健壮”。请检查异常处理是否可靠 1. 哪些异常会被吞掉 2. 哪些异常会导致调用方误以为成功 3. 日志是否足够定位问题 4. 是否需要重试、回滚或告警 5. 请给出最小修改建议不要重写整个模块。我会特别加上“最小修改建议”。因为 AI 很喜欢顺手重构半个项目但实际工作中我们更需要低风险改动。五、第四轮检查测试用例是否覆盖了真实风险让 AI 生成测试很常见但我更建议先让它评估测试缺口下面是功能代码和现有测试。 请不要直接新增测试代码先告诉我 1. 哪些关键路径已经覆盖 2. 哪些边界条件没有覆盖 3. 哪些测试只是验证实现细节价值不高 4. 如果只能补 3 个测试优先补哪 3 个为什么这样做的好处是测试不再是“为了覆盖率而覆盖”而是围绕风险排序。六、第五轮检查可维护性而不是炫技有些代码能跑但三个月后没人敢改。AI Review 可以专门从可维护性角度看函数是否承担了太多职责命名是否能解释业务含义重复逻辑是否会导致以后改漏配置、常量、魔法数字是否散落是否存在“为了聪明而聪明”的写法。对应提示词请从“后续维护者是否容易理解和修改”的角度 Review。 只指出最值得改的 5 个问题。 每个问题请包含为什么影响维护、建议怎么改、是否必须现在改。“是否必须现在改”很重要。不是所有问题都值得立刻处理Review 也要区分优先级。七、一个完整可复用的 AI Review 模板如果懒得分多轮可以直接用下面这个模板你是一个谨慎的代码评审助手。 请基于我提供的需求、代码和上下文做 Review。 要求 1. 先用简短要点复述你理解的需求 2. 只指出有实际风险的问题不要为了凑数量而提建议 3. 按“高 / 中 / 低”标注风险等级 4. 每个问题都要说明触发场景 5. 优先给最小修改建议 6. 不确定的地方明确写“需要确认”不要脑补 7. 最后列出建议补充的测试用例。 上下文 【这里写业务背景】 代码 【这里粘贴代码或关键 diff】八、使用 AI Review 时要避免的三个坑1. 不要把敏感信息直接贴进去密钥、Token、真实用户数据、内部地址、未公开业务信息都不应该随手丢给在线工具。必要时先脱敏或者使用公司允许的工具和环境。2. 不要把 AI 建议当结论AI 的建议是“候选意见”不是最终裁判。尤其涉及性能、安全、并发、财务计算、权限控制时一定要自己复核。3. 不要一次塞太多上下文代码太多时建议按模块、按 diff、按调用链分批审。上下文越杂AI 越容易给出看似全面但不够落地的建议。结语我觉得 AI 代码助手最舒服的用法是把它当成一个“勤快但需要你把关的同事”它帮你查漏补缺、整理风险、提出测试方向你负责判断业务取舍、最终方案和上线责任。如果你已经在用 AI 做 Code Review你更常让它检查哪一类问题边界条件、测试、性能还是可维护性欢迎分享一个你觉得好用的提问方式。