我们团队用AI做代码评审：从每周10小时降到4小时

零壹AI实验室
2 阅读7分钟

我们团队用AI做代码评审：从每周10小时降到4小时

带9人技术团队，代码评审（Code Review, CR）一直是个痛点。

之前的工作流：

  1. 开发者提交PR（Pull Request）
  2. 我或Tech Lead手动review（逐行看代码）
  3. 提修改意见
  4. 开发者修改
  5. 再次review
  6. 合并

问题：

  • 耗时：每个PR平均30分钟review时间，9个人的团队，每周约10小时花在CR上
  • 不一致：不同的人review，标准不统一（我看架构，另一个Tech Lead看代码风格，第三个看性能）
  • 遗漏：人工review会疲劳，有时候明显的问题（比如硬编码密码、没关数据库连接）会漏掉

于是我们想：能不能让AI先做第一轮review，人工只复核？

我们的AI + 人工混合评审工作流

经过2个月的摸索，我们形成了一套稳定的工作流：

开发者提交PR
   ↓
AI自动做第一轮review（10分钟内完成）
   ↓
AI生成review意见（直接评论在PR里）
   ↓
开发者根据AI意见修改代码
   ↓
人工复核（只看法务、架构、安全相关的问题）
   ↓
合并

效果：

  • Code Review时间：从每周10小时降到4小时（节省60%）
  • Bug漏检率：从15%降到8%（AI能发现一些人工容易漏的问题）
  • 开发者满意度：从"CR很烦"到"AI先帮我找问题，改起来更快"

具体做法：如何用AI做第一轮Review

Step 1：选工具（我们试了4个）

工具优点缺点我们的评分
GitHub Copilot Chat集成在PR页面，方便只能看代码，不理解项目上下文6/10
CodeRabbit专门针对CR的AI工具，能理解项目结构付费（每个开发者$10/月）8/10
Claude Opus 4.7理解能力强，能发现深层问题需要手动粘贴代码，没有自动化9/10（质量最高）
Gemini 2.5 Pro能读懂项目文档，理解架构设计有时候会"过度解读"，提一些不必要的修改意见7/10

我们的最终选择：Claude Opus 4.7（质量最高）+ CodeRabbit（自动化）

理由：Claude负责"深度review"（架构、安全、性能），CodeRabbit负责"基础review"（代码风格、明显bug、最佳实践）。

Step 2：配置AI Review的Prompt（关键！）

AI做CR最大的问题是"提了一堆没必要的修改意见"。

比如你写了个快速排序，AI会说"建议改用标准库的排序函数"（废话，我知道，但这是面试题）。

解决方法：给AI明确的Review重点。

我们的Prompt模板：

你是一个资深代码审查专家。请对以下PR进行代码审查，重点关注：

【必须检查的项】
1. 安全漏洞（SQL注入、XSS、硬编码密码、未加密的敏感信息）
2. 性能问题（N+1查询、大O复杂度、内存泄漏）
3. 边界情况（空值处理、数组越界、并发问题）
4. 代码重复（DRY原则）
5. 错误处理（是否捕获了所有异常、错误信息是否足够）

【不需要检查的项】
- 代码风格（我们有ESLint / CheckStyle）
- 变量命名（只要能看懂就行）
- 注释数量（有必要的注释即可）

【输出格式】
对每个发现的问题，按以下格式输出：
- **问题**：[描述问题]
- **严重程度**：[严重 / 中等 / 轻微]
- **建议**：[如何修改]
- **示例**：[给出修改前后的代码对比]

【特别注意】
如果这个PR是"快速原型"或"POC（概念验证）"，请降低你的要求。

效果：

用这个Prompt后，AI提的修改意见中，有80%是我们认可并修改的（之前只有50%）。

Step 3：自动化（让AI在PR提交时自动Review）

我们用了两种方法：

方法1：GitHub Actions + Claude API（推荐）

在 .github/workflows/ai-review.yml 里配置：

name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Get PR diff
        run: |
          git diff origin/main...HEAD > pr_diff.txt
      
      - name: Send to Claude for review
        run: |
          # 调用Claude API，把diff发给它
          curl -X POST https://api.anthropic.com/v1/messages \
            -H "x-api-key: ${{ secrets.CLAUDE_API_KEY }}" \
            -H "anthropic-version: 2023-06-01" \
            -d @- <<EOF
          {
            "model": "claude-opus-4.7",
            "max_tokens": 4096,
            "messages": [{
              "role": "user",
              "content": "请review以下代码变更：\n$(cat pr_diff.txt)"
            }]
          }
          EOF
      
      - name: Post review comments
        uses: some-action-that-posts-comments@v1
        with:
          comments: ${{ steps.ai-review.outputs.comments }}

优点：全自动化，PR一提交，AI就开始review
缺点：需要写脚本，Claude API要花钱（但便宜，一次review约$0.05）

方法2：CodeRabbit（最简单）

直接安装CodeRabbit的GitHub App，它会在PR里自动评论。

优点：零配置，装上就能用
缺点：付费（$10/开发者/月），定制化能力弱

Step 4：人工复核（AI之后，人该看什么？）

AI做完第一轮review后，人不是不看了，而是看的地方不一样。

AI能搞定的（人工不需要再看）：

  • ✅ 代码风格问题（ESLint能搞定）
  • ✅ 明显的bug（空指针、数组越界）
  • ✅ 最佳实践（比如"这个函数太长了，建议拆分"）

AI搞不定的（人工必须看）：

  • ❌ 架构设计（AI不理解你的业务，可能会提一些"技术上对，但业务上没必要"的修改）
  • ❌ 安全敏感部分（比如鉴权逻辑、加密算法，必须人来复核）
  • ❌ 性能优化的权衡（AI会建议"加缓存"，但不知道你的缓存策略是什么）

我们的人工复核清单：

□ 架构设计是否合理？
□ 有没有安全风险？
□ 性能优化是否可行（考虑业务场景）？
□ AI提的修改意见是否合理（有没有"过度优化"）？
□ 测试覆盖是否足够？

时间：原来每个PR要30分钟，现在只需要10分钟（只看法务、架构、安全）。

实战案例：AI帮我们抓到了一个生产事故级别bug

说个真实案例。

场景：一个支付模块的PR，开发者在 PaymentService.process() 里加了新功能。

AI的review意见：

⚠️ **严重问题**：在 `process()` 方法里，你先扣款，再记录日志。
如果扣款成功，但日志记录失败（比如数据库宕机），会导致"钱扣了，但没记录"的情况。

**建议**：先把日志记录到本地文件（或消息队列），再扣款。这样即使数据库宕机，也不会丢失记录。

**严重程度**：严重

我们的人工复核：看了AI的意见，觉得有道理，让开发者修改。

结果：修改后2周，生产环境真的出现了"数据库宕机"的情况。但因为我们先记录了日志，没丢失任何支付记录。

如果没看AI的review：这个bug会到生产环境，可能导致"钱扣了但没记录"的事故（损失无法估量）。

常见坑：AI Code Review的5个陷阱

我们踩过这些坑，分享给你：

坑1：AI会"过度建议"

AI有时候会提一堆"技术上对，但实际没必要"的修改意见。

比如你写了个简单的脚本，AI会说"建议拆分成3个函数，每个函数不超过20行"（没必要，脚本越简单越好）。

解决方法：在Prompt里明确"不需要检查的项"。

坑2：AI不理解业务逻辑

AI看的是代码，不是需求文档。

比如你的需求是"快速上线一个MVP"，AI会建议你"加单元测试、集成测试、E2E测试"（但MVP不需要这么完整的测试）。

解决方法：在PR描述里写清楚"这是一个MVP，不需要完整的测试"。

坑3：AI的"最佳实践"不一定适合你

AI会建议"用Redis做缓存"，但你的项目可能根本不需要缓存（数据量很小）。

解决方法：人工复核时，判断AI的建议是否符合项目实际情况。

坑4：AI会让开发者"过度依赖"

有个开发者，每次提交PR前，都让AI先review一遍，然后把AI的所有建议都改了。

结果：代码变成了"AI喜欢的风格"，而不是"团队统一的风格"。

解决方法：团队要有自己的代码规范，AI的建议只是参考，不是命令。

坑5：AI Review会慢（大模型响应时间）

Claude API review一个中等大小的PR（约500行变更），需要约2-3分钟。

如果同时有5个PR提交，AI review会排队。

解决方法：用异步方式（GitHub Actions + 消息通知），AI review完成后，自动通知开发者。

效果评估：数据说话

我们跑了2个月，统计了数据：

指标使用前使用后变化
每周CR总时间10小时4小时↓ 60%
Bug漏检率15%8%↓ 47%
PR平均合并时间2.5天1.2天↓ 52%
开发者满意度6/108/10↑ 33%
AI API费用-$50/月新增成本

结论：节省的时间价值 >> AI API费用。

如何开始：给想试AI Code Review的团队

第一步：选一个较小的项目试点

不要一开始就在核心项目上用AI review。

先在一个小项目（比如内部工具、测试项目）上试2周，看看效果。

第二步：配置Prompt（别用默认的）

AI默认的review标准不适合所有团队。

根据你的团队情况，定制Prompt（参考我上面的模板）。

第三步：人工复核AI的意见

前10个PR，AI review后，你要逐个看AI的意见是否合理。

把不合理的意见记录下来，用来优化Prompt。

第四步：逐步形成团队规范

2个月后，你们会有自己的"AI Review规范"（比如"安全相关的必须由人复核"）。

把这个规范写成文档，新人来了也能快速上手。

最后说一句

AI Code Review不是"代替人工"，而是"增强人工"。

它不能替代你对架构的理解，不能替代你对业务的判断，但它能帮你节省时间，让你专注于更重要的事。

如果你还在手动review所有代码，真的可以试试AI。

不是为了偷懒，而是为了把时间花在更值得的地方。

互动时间

你们团队用AI做Code Review吗？效果怎么样？

有没有遇到AI提了一些"莫名其妙"的修改意见？欢迎在评论区分享。

如果这篇对你有帮助，点个赞吧。

创作时间：2026-05-11
实践周期：2个月（2026年3月-5月）
团队规模：9人技术团队
节省时间：每周6小时 × 9人 = 54小时/月

avatar
文章
阅读
粉丝