AI 代码审查——自动化 PR Review 配置与 5 套专项检查模板

第12章：AI 代码审查——自动化 PR Review 配置与 5 套专项检查模板

用 Claude API 自动化 PR Review：GitHub Actions 完整可运行配置，安全漏洞、性能问题、代码规范三维检查。附 5 套专项 Review Prompt 模板，覆盖安全、数据库性能、错误处理、测试完整性、API 设计。读完本章，你可以当天就把自动化 Review 跑起来。

AI Review 的定位：第一轮过滤，不是最终裁判

在引入 AI Review 之前，先搞清楚它能做什么、不能做什么：

结论： AI 做第一轮 Review，筛掉机械性问题；人工做第二轮，判断业务逻辑和架构合理性。这样分工后，人工 Review 的时间可以缩短 40-60%，而且质量更高——因为人工可以聚焦在真正需要判断力的地方。

方式 1：本地快速 Review（最简单，立刻能用）

# 提交前快速 Review 当前改动
git diff HEAD | claude -p "
作为资深工程师，Review 这个 diff：
1. 有没有安全漏洞（SQL 注入、XSS、未验证输入、密钥硬编码）
2. 有没有明显的性能问题（N+1 查询、循环里的同步 IO）
3. 错误处理是否完整（有没有被吞掉的异常）
4. 有没有遗漏测试的情况

每个问题给出：文件名和行号、严重程度（high/medium/low）、修复建议
"

这个方法零配置，提交前跑一下，2 分钟内出结果。适合个人项目和小团队。

方式 2：GitHub Actions 自动 PR Review（完整可运行配置）

以下是一个完整的 GitHub Actions 配置，在每次 PR 创建或更新时自动触发 Claude API Review，并把结果作为评论发布到 PR 上。

# YAML — .github/workflows/ai-review.yml
name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      contents: read

    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get PR diff
        run: |
          git diff origin/${{ github.base_ref }}...HEAD > pr.diff
          echo "DIFF_SIZE=$(wc -c < pr.diff)" >> $GITHUB_ENV

      - name: AI Review
        if: env.DIFF_SIZE != '0'
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          pip install anthropic
          python3 << 'EOF'
          import anthropic, os

          diff = open('pr.diff').read()[:30000]  # 限制大小，避免超出 token 上限

          client = anthropic.Anthropic()
          response = client.messages.create(
              model="claude-haiku-4-5-20251001",
              max_tokens=2048,
              messages=[{
                  "role": "user",
                  "content": f"""你是资深工程师，正在做 Code Review。

请分析这个 PR diff，找出以下问题：
1. 安全漏洞（SQL 注入、XSS、密钥硬编码、权限缺失）
2. 明显的性能问题（N+1 查询、缺索引、阻塞操作）
3. 错误处理缺失（被吞的异常、缺少超时处理）
4. 空值/未定义引用风险

输出格式：
**[HIGH/MEDIUM/LOW]** `文件名:行号` — 问题描述 — 修复建议

只报真实问题，不报 nit。如果没有问题，输出 "LGTM"。

Diff:
{diff}"""
              }]
          )

          review = response.content[0].text
          with open('review.txt', 'w') as f:
              f.write(review)
          print(review)
          EOF

      - name: Post Review Comment
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          REVIEW=$(cat review.txt)
          gh pr comment ${{ github.event.number }} --body "## AI Code Review

$REVIEW

---
*由 Claude 自动生成。仍需人工 Review 业务逻辑和架构决策。*"

配置说明： 需要在仓库 Settings → Secrets 里添加 ANTHROPIC_API_KEY。使用 claude-haiku-4-5-20251001 而非 claude-sonnet，每次 Review 的 API 费用约为 $0.002-0.01，对大多数团队可以忽略不计。如果 PR diff 超过 30000 字符，会被截断——在 .cursorrules 里规定"每个 PR 专注一个功能，diff 不超过 400 行"可以从根本上解决这个问题。

5 套专项 Review Prompt 模板

根据 PR 的性质选择对应的专项模板，效果比通用模板好 3 倍。

专项 1：安全 Review（涉及认证、支付、用户数据的 PR 必用）

Security Review Prompt

作为应用安全专家，Review 以下代码中的安全风险：

1. SQL 注入：用户输入是否直接拼接进 SQL 字符串？ORM 是否用了参数化查询？
2. XSS：用户提供的内容是否未经转义就插入 DOM？innerHTML / dangerouslySetInnerHTML 是否安全？
3. 硬编码密钥：代码里是否有 API key、密码、token、private key？
4. 不安全的随机数：是否用 Math.random() 生成安全 token？应该用 crypto.randomBytes()
5. 路径遍历：文件操作是否对用户输入的路径做了限制？
6. 权限检查：每个 API 端点是否验证了调用者的身份和权限？是否存在越权访问漏洞？

@[相关文件]

对每个发现的问题：指出文件和行号，说明攻击向量，给出修复代码

专项 2：数据库性能 Review（数据库密集型功能必用）

DB Performance Review Prompt

作为数据库性能专家，Review 这段代码中的数据库操作：

1. N+1 查询：循环里是否有数据库查询？（例如：for 循环里调用 findById）
2. 缺失索引：WHERE 条件里的字段是否有索引？ORDER BY 字段是否有索引？
3. SELECT *：是否在只需要部分字段时用了 SELECT *？
4. 无分页的大结果集：是否有可能返回几万行的查询但没有 LIMIT？
5. 事务范围过大：是否把不需要在同一事务里的操作都塞进了一个事务？
6. 可以并行的串行查询：有没有互不依赖但却串行执行的查询？可以用 Promise.all

@[包含 DB 操作的文件]

对每个问题，估算在 100 万行数据量下的性能影响，给出优化方案

专项 3：错误处理 Review

Error Handling Review Prompt

检查这段代码的错误处理完整性：

1. 被吞的异常：catch 块里只有 console.log 而没有处理或重新抛出？
2. 缺少超时：外部 API 调用、数据库查询是否设置了超时？
3. 空值引用：是否有未检查 null/undefined 就直接访问属性的地方？
4. 用户可见的错误信息：操作失败时，用户是否收到有意义的错误提示？（不能只返回 500）
5. 部分失败处理：批量操作（例如发送 100 封邮件）中，一个失败是否会导致整批失败？

@[相关文件]

对每个问题给出文件名和行号，以及修复后的代码片段

专项 4：测试完整性 Review

Test Coverage Review Prompt

Review 这次 PR 的测试完整性：

1. 新增业务逻辑是否有对应的单元测试？
2. Happy path 是否被覆盖？
3. 边界条件是否有测试？（空输入、超大输入、负数、空数组）
4. 错误路径是否有测试？（第三方 API 失败、数据库报错、权限不足）
5. 测试是否真正验证了行为？还是只 mock 了所有依赖然后断言 mock 被调用？
   （后者是"测试存在的错觉"，没有保护价值）

@[diff文件]

对每段没有测试覆盖的重要逻辑，给出测试用例代码示例

专项 5：API 设计 Review（新增或修改公开 API 接口时使用）

API Design Review Prompt

从 API 设计角度 Review 这次变更：

1. RESTful 规范：HTTP 动词是否正确使用？（查询用 GET，有副作用用 POST/PUT/PATCH/DELETE）
2. 状态码：错误场景是否返回了正确的 HTTP 状态码？
   （404 vs 403 vs 400 vs 500 的区别）
3. 幂等性：PUT/PATCH 接口是否幂等？重复调用是否安全？
4. 向后兼容：如果是修改已有接口，是否破坏了已有调用方？
5. 错误响应格式：是否有统一的错误响应格式？{ error: string, code: string } 还是其他？
6. 分页设计：列表接口是否有分页？是否返回了 total 和 hasMore？

@[相关路由文件]

AI Review 不擅长的部分：人工必须覆盖

以下场景，AI Review 的结论不可信，必须依赖人工：

• 业务逻辑正确性。 代码技术上完全正确，但实现的功能完全不符合需求——只有懂业务的人能判断。
• 架构一致性。 AI 看到的是 diff，不是整个系统。某个孤立看合理的设计可能与系统其他部分的架构原则相悖。
• 团队隐性知识。 "为什么不用 Redis 缓存这个""这个模块当时为什么设计成这样"——这些历史决策只存在于人的记忆里。
• 产品权衡判断。 "这个功能值不值得这么复杂的实现？"这是产品和工程的判断，不是技术正误的判断。

分工建议： AI 负责机械性检查（安全、性能、规范、常见 bug），人工负责业务正确性和架构合理性。这种分工让人工 Review 的时间集中在真正需要判断力的地方，而不是消耗在"这个变量名不对""这里少了 null 检查"这类问题上。

本章 5 要点