AI 已经改变了代码审查流程。到 2026 年，大多数开发者都会在某个环节使用 AI 辅助 review：有人用它扫语法和风格，有人用它做安全检查，也有人让它先看完整 PR 再由人工复核。

但 AI 代码审查不是“让模型替代 reviewer”。它更适合承担高频、机械、模式化的第一轮检查，把人的注意力留给架构取舍、业务逻辑和团队约定。

这篇文章整理一套可落地的 AI code review 工作流：AI 负责什么，人负责什么，如何接入 IDE / PR / CI，以及怎样避免让 AI 产生大量噪音评论。

代码审查正在发生什么变化

传统 review 依赖人工经验，优点是理解上下文深，缺点是慢、覆盖不均匀、容易受 reviewer 状态影响。AI 辅助 review 的优势是快、稳定、覆盖范围广，但它对业务语义和团队上下文理解有限。

维度传统人工 ReviewAI 辅助 Review
速度小 PR 也可能等数小时通常几分钟出第一轮结果
一致性取决于 reviewer可以按固定 checklist 执行
覆盖面常抽查重点文件可以扫完整 diff
架构判断强弱，需要人把关
业务语义强容易误判
成本人的时间工具/API 费用

结论很简单：AI 适合做第一轮机械检查，不适合独自拍板。

AI 擅长检查什么

AI 代码审查最适合处理“模式明确”的问题。

机械类问题

  • 语法错误和拼写错误；
  • 命名不一致；
  • import/export 问题；
  • 类型不匹配；
  • 重复代码；
  • 显而易见的边界条件遗漏。

常见安全问题

  • SQL 注入、命令注入、XSS 等已知模式；
  • 明文密钥或敏感日志；
  • 缺少输入校验；
  • 权限检查遗漏；
  • 不安全的依赖使用。

测试和文档问题

  • 修改了核心逻辑但没有测试；
  • 测试只覆盖 happy path；
  • README / 注释与行为不一致；
  • API 参数变了但调用方没同步。

这些检查不需要深度业务理解，适合交给 AI 先扫一遍。

AI 不擅长什么

下面这些仍然需要人做最终判断。

架构和边界

AI 可以指出“这里耦合变高了”，但它很难知道团队为什么要这样设计。比如一个看起来重复的函数，可能是刻意避免跨模块依赖；一个看起来可以抽象的逻辑，可能还没到抽象时机。

业务正确性

模型能看懂代码语法，不一定能判断“这个优惠券规则是否符合财务要求”。涉及领域知识、权限边界、计费逻辑、风控逻辑时，AI 只能辅助提问，不能替代 owner 判断。

团队约定

每个团队都有自己的约定：目录结构、异常处理风格、日志级别、测试命名、feature flag 策略。AI 如果没有读到项目规则，很容易给出“通用但不适合本仓库”的建议。

三层 AI Review 流程

推荐把 AI review 分成三层，而不是一次性让模型“帮我看代码”。

第一层：本地预检查

适合在提交前运行，只阻断严重问题。

1
2
# 示例：只检查 staged 文件
ai-review --files $(git diff --cached --name-only) --mode quick

本地预检查关注：

  • 明显 bug；
  • 敏感信息；
  • 破坏类型/导入；
  • 缺少必要测试；
  • 大面积无关改动。

不要让本地 AI review 阻断所有风格问题，否则开发体验会变差。

第二层：PR 自动审查

PR 打开后，AI 可以做完整 diff 扫描，输出摘要和高风险点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
name: AI Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: AI Review
        run: |
          ai-review pr \
            --severity-threshold medium \
            --focus bugs,security,tests

PR 自动审查不应该直接替代 reviewer approve，它更像“预筛选”。

第三层：人工复核关键判断

人类 reviewer 应重点看：

  • 架构边界是否合理；
  • 业务逻辑是否符合需求；
  • 是否引入不必要复杂度；
  • 测试是否真正覆盖风险；
  • AI 提出的严重问题是否真实。

最好的流程是：AI 先归类，人再判断。

有效的 AI Review Prompt

不要只写“帮我 review”。要明确维度和输出格式。

通用 review prompt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
请审查以下代码变更，重点关注：
1. 会导致生产问题的 bug；
2. 安全风险；
3. 性能退化；
4. 测试缺口；
5. 与现有项目模式不一致的地方。

输出格式：
- 严重级别：blocker / major / minor
- 文件和行号
- 问题说明
- 为什么这是问题
- 建议修复方式

不要输出纯风格偏好，不要重复 linter 能发现的问题。

安全 review prompt

1
2
3
4
5
6
7
8
9
请从安全角度审查这段代码，重点看：
- 注入风险；
- 权限绕过；
- 敏感信息泄露；
- 输入校验；
- 依赖和外部调用；
- 日志是否暴露隐私。

如果不确定，请标记为“需要人工确认”，不要编造风险。

架构 review prompt

1
2
3
4
5
6
请审查这次改动是否符合当前项目架构：
- 模块边界是否清晰；
- 是否引入跨层依赖；
- 是否把页面特例塞进全局逻辑；
- 是否出现不必要抽象；
- 是否能通过更小改动解决问题。

如何降低 AI Review 噪音

1. 限定严重级别

只让 AI 输出 blocker / major。minor 交给 linter 和 formatter。

2. 给项目规则

把项目约定作为上下文输入，比如：

  • 不做无关重构；
  • 文件路径规则；
  • 测试策略；
  • 站点特有约束；
  • 安全边界。

3. 要求可复现

让 AI 对每个问题说明“如何验证”。不能验证的问题，默认降级为建议。

4. 分维度审查

不要一次审查全部。可以拆成：

1
bug review → security review → test review → architecture review

这样比一次大 prompt 更稳定。

AI Review 的落地清单

阶段AI 做什么人做什么
提交前扫 staged 文件、敏感信息、明显 bug判断是否继续提交
PR 打开总结变更、标注高风险文件确认 scope 是否正确
Review 中提供 bug/security/test 建议判断真假和优先级
合并前检查测试、构建、未解决 blocker最终 approve

常见错误

错误 1：把 AI 评论全部当真

AI 会误报，特别是架构和业务逻辑。严重问题必须人工复核。

错误 2：让 AI 输出太多风格建议

这会淹没有价值的问题。风格交给 formatter。

错误 3：不给项目上下文

没有项目规则，AI 会给通用建议，甚至建议违反团队约定的改法。

错误 4：没有验证闭环

AI 提出问题后，必须有测试、复现步骤或人工判断结果，否则只是聊天记录。

推荐实践

  1. 本地 AI review 只查 blocker；
  2. PR AI review 输出摘要 + 高风险点；
  3. 人类 reviewer 负责架构和业务判断；
  4. 所有 AI 发现都要可验证；
  5. 每次误报都沉淀为项目规则；
  6. 不让 AI 直接 approve 或 merge。

总结

2026 年的 AI 代码审查，最有效的方式不是让 AI 替代人，而是把它放在正确的位置：先做大范围机械检查，再把真正需要判断的问题交给人。

如果你把 AI review 当作“第一轮筛查器”，它能节省大量时间；如果你把它当成“最终 reviewer”，它会制造新的风险。