现在很多人用 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，你更常让它检查哪一类问题？边界条件、测试、性能，还是可维护性？欢迎分享一个你觉得好用的提问方式。
