如何基于 AI 做 Code Review？

核心回答

基于 AI 做 Code Review，需要把代码变更、需求和相关实现组织成审查上下文，让模型提出有证据的缺陷，再通过代码回查或测试过滤误报，最后把意见定位到具体文件和变更行。目标是发现这次改动引入的功能、安全、兼容性或性能问题，而非生成一份泛泛的代码评价。

一套参考实现可以由服务接收 PR 更新事件，读取固定 base/head 的 diff，结合函数定义、调用方、接口约定与测试构建上下文；先执行适用的静态检查，再让模型分析业务和跨文件问题。输出包含位置、触发条件、实际后果和修改方向，经过核验、去重后展示给开发者。人工重点确认业务假设与重要结论，测试负责验证可执行行为，模型意见本身不等于合并结论。

审查输入怎样准备

首先固定审查版本，保存仓库、PR、base/head commit 和需求说明。评审一个分支的整体变更时，可以从明确的比较基点或 merge base 构造 diff；增量复审则还需知道上一轮审查到了哪个提交。否则 PR 更新后，模型可能引用旧行号，甚至把不同版本的代码拼在一起。

随后建立变更清单：哪些文件改变、涉及哪些功能、有哪些配置或数据库结构变化。生成文件和依赖锁文件可以采用不同检查方式，但被跳过的范围应留下记录，不能让“模型没读到”变成“审查通过”。

diff 用来确定重点，相关代码用来判断真假。 仅有新增的一行数据库调用，往往无法判断事务、鉴权或空值是否已由上层处理。可以按函数符号、引用关系和路径检索补齐：

• 修改函数的完整实现，以及关键调用方和被调用方。
• 接口、数据结构、权限检查、异常约定和必要配置。
• 原始需求、现有测试，以及本次修改的断言。

小改动按需读取即可；大型 PR 可以先按功能与依赖关系拆分审查，再汇总跨模块结论。单纯按 token 长度把文件切开，容易把调用方和实现分到互不知情的片段。上下文超出预算时，应保留未覆盖清单或进一步缩小审查任务。

模型和确定性检查怎样分工

编译、类型检查、Lint、依赖或安全规则适合先提供明确的诊断，模型则重点追踪需求与控制流、数据流的关系。例如异常被吞掉后，后续状态更新是否仍会执行；接口参数类型改变后，调用方是否仍按旧契约使用；缓存、事务与重试是否改变业务语义。

审查指令应要求模型围绕本次变更提出可操作的问题，并允许返回零条。每条意见至少说清楚：哪个位置，在什么输入或状态下，沿哪条执行路径，导致什么后果。 缺乏上下文的疑点先补查证据；命名偏好和代码风格建议与实际缺陷分开，避免重要问题淹没在评论里。

例如在一个教学支付场景中，diff 把扣款异常捕获后直接忽略，随后仍标记订单已支付。有效意见应解释“扣款失败时仍进入状态更新和通知分支”的具体路径，并指向异常处理与状态更新之间的位置。仅写“异常处理可能有风险”不能帮助开发者判断和修改。跨系统扣款场景还需结合超时、幂等和对账语义，不能仅凭一个异常就判断资金的最终状态。

如何过滤误报并输出结果

把候选意见交给核验步骤，主动查找能够推翻它的条件：上游是否已经校验、配置是否限制了该路径、数据库约束是否阻止了该状态、调用方是否保证了该参数。核验可以由一次单独的模型审查辅助完成，也可以直接用检索、静态分析或最小测试，不必为每个 PR 固定增加多 Agent 流程。

对可执行的缺陷，尽量构造能区分正确与错误行为的最小用例。用例预期来自需求或接口契约，再对照目标提交运行；必要时比较基线与变更版本，以确认问题是否由这次改动引入。并发、支付和权限问题可能需要更接近真实交互的测试，单个 Mock 测试不一定足够。测试或环境无法运行时，把结论依据和待确认条件说清楚。

输出可以采用结构化字段：head_sha、path、side、line、severity、trigger、impact、evidence、suggested_fix。发布到代码评审界面前，检查位置属于对应提交的 diff、文件路径确实存在；同一根因在多个位置出现时合并说明。PR 再次更新后，重新核对意见是否仍成立，避免重复评论或把旧建议贴到新代码上。

模型给出的补丁也要经过审查和针对性验证。审查任务默认只需读取代码与生成意见；确需运行测试时使用隔离的执行环境，不给它发布或业务写入权限。待审源码、注释和 PR 描述是分析材料，不应成为改变审查权限的指令。

怎样衡量审查系统是否有用

用历史变更和已确认缺陷建立评估集，保留正常改动与容易误报的反例。检查两个方向：提出的意见有多少经核验成立，以及已知缺陷有多少被发现，并按业务逻辑、鉴权、兼容性、并发等类型分组。人工采纳记录可以辅助评价，但“接受了建议”与“确实修复缺陷”还需区分。

同时观察每个 PR 的无效评论、重复意见、审查延迟、调用成本和开发者核验耗时。若评论越来越多，却没有减少漏掉的缺陷或人工负担，应调整上下文、问题标准和核验过程，而不是追求输出条数。低风险修改保持轻量，重要业务路径保留相应的领域审查与验证。

常见追问

Review Skill 需要包含什么？

适用范围、输入版本、取上下文的方法、项目约定、缺陷判定标准、输出格式，以及可选的检查脚本。Skill 沉淀审查方法；读取仓库、执行测试和发布评论由宿主工具完成，写进 Skill 的规则不会自动变成权限控制。

让同一个模型写代码再审查，能保证正确吗？

不能保证。模型可能沿用生成时的错误假设。审查时提供独立的需求和契约，要求反向寻找错误条件，再用静态结果、测试或领域知识核验，比单纯要求“再检查一遍”更有价值。

对应教程

参考资料