先给对上下文
只贴 diff 很容易误判。把改动 + 相关文件 + 项目约定一起给模型，并说明「这段代码要做什么、为什么这样改」，结论才靠谱。
限定输出格式
要求固定结构：严重级别 + 文件:行号 + 问题 + 建议。否则模型会写一大段正确的废话，淹没真正的问题。
评审维度清单
- 正确性：边界、空值、并发、时序；
- 安全：注入、越权、敏感信息、依赖；
- 性能：N+1 查询、不必要的循环、大对象拷贝；
- 可测性：是否有副作用、能否单测；
- 一致性：是否符合本仓库既有风格与约定。
区分事实与猜测
让模型标出「确定有问题」和「建议看看」。把猜测当线索去核对，别当结论直接改。
两个坑
- 泄露私有代码：把公司内部代码发给外部云端模型有合规风险，敏感仓库用本地模型或经批准的方案；
- 过度自信：模型会编出并不存在的 API 或行号，引用必须你亲自核对。
实战案例：三次 AI 代码评审放行的问题
- 边界校验被“顺手优化”掉：模型把空数组校验删了，评审只看 diff 没看上下文。评审时应主动追问“空值 / 极限 / 并发”三类输入。
- 错误处理被静默吞掉：生成的
try/catch只打日志不抛出，故障被掩盖。约定异常要么处理要么上抛，禁止空 catch。 - 依赖了不存在的 API：模型编造出看似合理的库函数，编译或运行才暴露。评审前先跑一次构建与关键路径用例，别只看代码“像不像”。
常见问题（FAQ）
AI 生成的代码要署名吗？按团队规范即可，关键是评审责任在人：谁合并谁负责。评审重点看什么？看行为语义、安全边界与测试覆盖，而不是风格命名这类可自动化的问题。能全自动合并吗？低风险且测试完备的改动可以，但涉及鉴权、支付、数据删除的必须人工评审。怎么减少幻觉？限制上下文、要求引用现有实现，优先让它修改已有代码而非凭空新增。
把评审重点放在“行为”而非“风格”
AI 生成的代码通常格式规整、命名尚可，因此评审时间不该花在风格上，而应集中在几个真正容易出问题的地方。
- 边界与异常路径：空集合、空字符串、极大值、并发重复调用是否被正确处理。生成代码最常见的缺陷就是“正常路径完美、异常路径缺失”。
- 错误处理的真实性：检查是否存在只记录不处理的异常、被吞掉的错误以及无条件的兜底返回值，这些会让故障在更晚、更难排查的阶段暴露。
- 安全相关的默认值：权限检查是否被省略、输入是否直接拼接进查询或命令、日志中是否包含敏感字段。生成代码不了解你的权限模型，默认可能不安全。
- 依赖与副作用：新增依赖是否必要、是否有更轻的替代；副作用（写文件、发请求）是否放在意料之外的位置。
- 可测试性：逻辑是否被硬编码的时间、随机数与全局状态绑死，导致无法编写稳定测试。
与流程的结合
把这些检查项写进评审模板，比依赖个人记忆更可靠。同时对 AI 生成比例较高的模块加强集成测试覆盖，用自动化手段弥补人工评审的注意力上限。评审者始终对合并结果负责，这一点不因代码来源而改变。
记录与复用评审结论
把评审中发现的典型问题整理成案例库，并在后续提示中直接引用。这样既能让生成结果逐步贴近团队规范，也能让新成员通过案例快速理解规则。评审结论沉淀下来，才算真正降低了后续成本。