如何使用 AI 进行代码审查：自动化 PR 反馈，不遗漏任何错误

代码审查是指由原作者以外的人对源代码进行系统性检查。其目标是发现bug、提高代码质量、在团队中分享知识并保持代码库的一致性。

根据 谷歌工程实践文档，代码审查者在每次审查中都应关注设计、功能性、复杂性、测试、命名、注释、风格和文档。Atlassian的研究表明， 如果持续实践，代码审查可将缺陷减少60-90% 。

这些基本原则没有改变。改变的是被审查代码的数量和性质。

现在，AI编码助手在许多团队中生成了30-60%的代码。根据GitHub自己的研究，使用GitHub Copilot的开发者有30%的时间接受建议。这意味着审查者越来越多地评估他们没有看到编写过程的代码，而这些代码的作者（AI）在被问及原因时无法解释。

出现了三个问题：

1. 工作量过载。更快生成更多代码意味着需要审查更多的PR，而审查者能力却没有增加。
2. 欺骗性的正确性。AI生成的代码通常看起来语法完美，但包含微妙的逻辑错误、硬编码假设或遗漏的边缘情况。
3. 上下文盲区。编写代码的AI不了解你的业务规则、你的部署限制，也不知道它刚刚生成的函数与另一个服务中的逻辑重复。

仅靠人工代码审查无法跟上。但完全用AI工具取代人工审查者会带来另一种风险：工具能够捕获模式级错误，但会遗漏应用级行为。答案是分层——将正确的审查任务分配给正确的审查者（人类、工具或代理）。

‍

在引入AI工具之前，团队需要一个清晰的框架来明确代码审查应涵盖哪些内容。大多数清单侧重于风格和语法。一个完整的清单包括四个层面：

这个清单被有意地设计成一个渐进式结构。每一层都建立在前一层的基础上。Linter处理格式，这样人类就可以专注于逻辑。AI审查工具处理样板模式检测，这样人类就可以专注于架构。AI代理处理行为验证，这样人类就可以专注于产品决策。

‍

大多数团队的人工同行审查流程遵循可预测的模式：

1. 开发者发起一个拉取请求，并附带变更描述。
2. 分配一到两名审查者（或自愿审查）。
3. 审查者逐文件阅读差异（diff）。
4. 审查者在特定行留下内联注释。
5. 开发者回复注释，进行修改，推送更新。
6. 审查者批准。PR合并。

这个流程适用于小型团队且开发速度适中。它在大规模应用时会失效，原因有三：

审查延迟。在大多数公司，从PR发起到着第一条审查评论的平均时间是24小时。对于大型PR（500行以上），可能需要48-72小时。当审查者要求修改并重复此循环时，这种延迟会加剧。

深度不一致。在时间压力下，审查者会草草了事。微软研究院2023年的一项研究发现，审查者平均每次审查花费10分钟，无论PR大小——这意味着一个50行的PR与一个500行的PR得到相同的关注。

知识孤岛。当只有一个了解某个子系统的人时，他们就成了瓶颈审查者。如果他们休假或工作量过大，PR就会堆积如山。

这些问题都不能通过告诉开发者“更仔细地审查”来解决。它们需要结构性解决方案——能够处理机器可审查部分的工具和代理，这样人类就可以专注于只有人类才能评估的部分。

‍

代码审查工具：Linter、SAST和静态分析

第一个自动化层是确定性工具。这些不是AI——它们对代码应用固定规则。

Linter（ESLint、Pylint、Rubocop、Clippy）强制执行风格一致性并发现常见错误。它们快速、可预测且免费。每个团队都应该在CI中运行Linter。

静态应用安全测试（SAST）工具（SonarQube、Semgrep、Snyk Code、CodeQL）扫描代码以查找已知漏洞模式——SQL注入、XSS、不安全的反序列化、硬编码密钥。它们在AST（抽象语法树）上操作，并根据已知漏洞数据库进行模式匹配。

类型检查器（TypeScript、mypy、Flow）在编译时捕获类型不匹配，否则这些不匹配会在生产环境中表现为运行时错误。

这些工具必不可少但有局限性。它们只能捕获可以表达为规则的内容。它们无法评估：

• 函数的逻辑是否与其构建的产品需求相符
• 新的API端点是否在所有边缘情况下正确处理授权
• UI更改是否引入了视觉回归
• 数据库查询在生产规模下是否能正常运行

对于这些评估，你需要AI。

‍

AI代码审查工具：它们如何工作以及它们能发现什么

AI代码审查工具介于静态分析和人工审查者之间。它们使用大型语言模型来理解代码语义——不仅仅是模式，还有含义。

以下是主要工具的比较：

AI代码审查工具的工作原理。当PR被打开时，工具会拉取差异（通常还有周围的文件上下文），将其发送给LLM，并生成内联注释。更好的工具还会分析完整的仓库上下文——理解更改的函数如何与代码库的其他部分交互。

它们能发现Linter遗漏的问题：

• 逻辑错误。“此函数在第47行提前返回，因此第52行的清理代码永远不会执行。”
• 遗漏的边缘情况。“此处理程序未考虑空数组，这将在生产环境中导致TypeError。”
• 带有上下文的安全问题。“此API端点接受用户输入，但未验证角色字段，从而允许权限提升。”
• 性能问题。“循环内的此数据库查询将生成N+1个查询。请考虑批量处理。”
• 文档缺失。“此公共函数没有JSDoc，并且参数名称模糊不清。”

要深入了解Claude Code如何专门处理代码审查，请参阅我们的指南： 如何使用Claude Code自动化代码审查。

AI审查工具仍然遗漏的问题。上表中列出的每个工具都基于相同的输入进行操作：代码差异和周围的文件上下文。它们读取代码，但不运行代码。这造成了一个根本性的盲点。

AI代理不仅仅是读取差异。它操作一台计算机。它可以打开浏览器，导航到你的预发布环境，与UI交互，截取屏幕截图，并验证代码更改是否产生了预期的行为。

实际操作中的区别如下：

使用Sai，代码审查工作流变成了一个闭环：

1. PR被打开。Sai检测到新的拉取请求。
2. 差异分析。Sai读取更改的文件并识别受影响的功能。
3. 上下文收集。Sai检查相关问题、之前的对话和部署日志。
4. 代码审查。Sai运行Claude Code的/review命令以捕获代码级别的问题——语法错误、逻辑漏洞、安全模式。
5. 行为测试。Sai打开浏览器，导航到预发布部署，并测试受影响的用户流程。
6. 证据收集。Sai截取屏幕截图，记录重现步骤，并捕获控制台错误。
7. 报告生成。Sai编译一份审查报告，包含代码级别的注释和行为级别的证据。
8. PR评论。Sai将完整的审查报告作为PR评论发布，并附带屏幕截图。

关键在于：步骤1-4是所有AI代码审查工具都能做到的。步骤5-8是只有拥有计算机访问权限的AI代理才能做到的。有关支持步骤3-4的Claude Code集成的详细演练，请参阅： Sai现在运行Claude Code。

‍

逐步指南：使用Sai设置AI驱动的代码审查

步骤1 — 连接你的GitHub仓库。在Sai中，连接你的GitHub账户。Sai通过GitHub API访问你的仓库——读取PR、差异、问题和CI/CD结果。没有任何代码离开你的基础设施；Sai通过API读取差异，就像任何GitHub应用一样。

步骤2 — 定义你的审查范围。告诉Sai要监控哪些仓库和分支。例如：“审查我们前端仓库中所有针对主分支的PR。”你可以设置审查触发器——每个PR、仅限超过100行的PR、仅限涉及特定目录的PR，或仅限来自AI编码工具的PR。

步骤3 — 设置代码审查规则。定义你的团队关注什么。Sai将这些作为审查标准：

• 安全性：检查硬编码密钥、SQL注入模式、未经验证的用户输入
• 性能：标记N+1查询、无限循环、缺失分页
• 测试：要求新公共函数具有测试覆盖率
• 架构：强制模块边界和导入限制
• 业务逻辑：验证计算是否符合文档要求

步骤4 — 配置行为验证。这是Sai与其他所有工具的区别。将Sai指向你的预发布环境URL。定义要测试的关键用户流程：

• 结账流程：添加商品、应用优惠券、验证总金额、完成购买
• 身份验证：登录、密码重置、会话过期
• 仪表盘：数据正确加载、筛选器正常工作、导出生成有效文件

当PR更改了影响这些流程的代码时，Sai不仅仅是审查差异。它会打开浏览器，在预发布环境上运行流程，并捕获每个步骤的屏幕截图。

步骤5 — 设置通知。选择Sai发布审查报告的位置：作为GitHub PR评论、Slack消息，或两者兼有。配置紧急程度——关键安全问题会触发即时Slack警报；风格建议仅作为PR评论发布。

步骤6 — 批准和监控。Sai在发布PR评论或发送消息之前总是会请求批准。你审查草稿评论，批准或编辑，然后Sai发布它。随着时间的推移，你可以为低风险发现（风格、文档）配置自动批准，同时对安全和逻辑发现保持需要批准。

对于已经使用Claude Code进行开发的团队，集成是无缝的——Sai在其分析管道中运行Claude Code的/review命令。请参阅我们的完整设置指南 Claude Code审查演练。

‍