AI Code Reviewer：用 GPT-4 为每个 PR 配上免费资深评审

故事开场：一个开源项目作者的真实痛点

Code Review（代码评审）是软件工程中公认的"质量保障神器"——但现实很骨感。团队规模小时还好，当开发者数量超过 3 人、PR 堆积如山时，资深开发者的评审时间就成了最稀缺的资源。漏掉边界条件、未处理空值、注释代码忘了删——这些低级问题本不该消耗高工时工程师的注意力。

Ville Saukkonen 正是带着这个痛点创建了 ai-codereviewer。他想要的是：每次提交 PR，GPT-4 自动扫一遍 diff，指出真正值得关注的代码问题，让人类评审者把精力留给架构决策和业务逻辑。2023 年初项目上线 GitHub Actions Marketplace，到现在已经积累了超过 1029 颗 Star 和 870 个 Fork，成为 AI + DevOps 领域最具影响力的工具之一。

背景科普：GitHub Actions + AI 的正确打开方式

GitHub Actions 是 GitHub 内置的 CI/CD 自动化引擎，通过 YAML 配置文件定义工作流触发条件（push、PR 等）和执行步骤。AI Code Reviewer 的巧妙之处在于：它本身就是一个 GitHub Action——你不需要运行本地服务、不需要申请服务器，只需要在你自己的仓库里加一个 workflow 文件，把 ai-codereviewer 当作 action 引用进来，就能自动触发 AI 代码评审。

这种"插件式"设计的核心优势在于：

• 零运维：GitHub 托管运行时，开发者无需维护基础设施
• 天然集成：PR 评论直接出现在开发者熟悉的 GitHub 界面中
• 权限隔离：通过 GitHub Secrets 安全注入 OpenAI API Key，不泄露密钥

技术原理解析：三个步骤完成智能评审

项目的核心代码只有 1 个文件 src/main.ts（约 200 行 TypeScript），但逻辑完整清晰。整体处理流程分为三个阶段：

第一阶段：获取 PR Diff

通过 @octokit/rest 库调用 GitHub API，读取当前 PR 的代码变更差异（diff）。代码需要区分两种触发场景：

• PR 首次打开（action === "opened"）：直接通过 pulls.get 接口获取完整 diff
• 新提交推送（action === "synchronize"）：通过 repos.compareCommits 对比 before 和 after 两个 commit SHA，只获取增量部分

这解决了"同一个 PR 多次 push 只看最新变更"的实际需求。

第二阶段：构造 Prompt 并调用 GPT-4

对于 diff 中的每一个文件→代码块（chunk），系统构造一条 Prompt 发送给 OpenAI Chat Completions API。Prompt 设计非常精妙：

Your task is to review pull requests.
- 提供 JSON 格式响应: {"reviews": [{"lineNumber": <line_number>, "reviewComment": "<review>"}]}
- 只在有问题时给出评论，"reviews" 为空数组表示无需评论
- 使用 GitHub Markdown 格式
- 重要：不要建议在代码中添加注释
- 仅针对代码本身，不使用描述来推断功能

这里有一个细节值得注意：Prompt 中明确禁止 GPT "建议添加代码注释"——这是一个经过社区反馈迭代出来的设计决策，避免 AI 在评审中大量输出"建议加个注释"，反而制造噪音。

此外，代码使用了 temperature=0.2 和 max_tokens=700，以确保输出稳定、可控，避免 GPT 过度发挥。模型默认使用 GPT-4，也可通过配置参数切换为 gpt-4-1106-preview。

第三阶段：解析 JSON 并发布评审评论

GPT-4 返回的 JSON 被 JSON.parse() 解析为评论数组，然后通过 octokit.pulls.createReview 接口批量发布到 PR 页面。每条评论关联具体的文件路径和行号，开发者点击即可跳转到对应代码位置。

评论以 Review Comment 形式（非普通 issue 评论）提交，支持 Request Changes 或 Approve 事件类型，进一步集成到团队代码准入流程中。

架构与代码质量评估

维度	评估
架构风格	单文件函数式流水线（Get Diff → Parse → Analyze → Comment）
代码规范	TypeScript strict 模式，类型覆盖完整
依赖管理	@actions/core（GitHub Action SDK）、@octokit/rest（GitHub API）、openai（OpenAI 官方 SDK）、parse-diff（标准化 diff 解析）、minimatch（glob 排除模式）
代码行数	约 200 行（含空行和注释），可维护性高
测试覆盖	仓库内无测试用例，但功能逻辑简单直观
文档质量	README 结构清晰，安装步骤详细，示例 YAML 可直接复制使用
安全性	API Key 通过 GitHub Secrets 注入，不进入源码；@octokit/rest 使用官方认证方式

功能配置与使用门槛

参数配置

参数	必填	默认值	说明
GITHUB_TOKEN	✓	—	GitHub 默认 token，无需手动添加
OPENAI_API_KEY	✓	—	OpenAI API Key（建议新建专用 Key，限制额度）
OPENAI_API_MODEL	✗	gpt-4	可选 gpt-4-1106-preview（JSON 模式支持）
exclude	✗	空	glob 模式，多个用逗号分隔（如 **/*.json, dist/**）

适用场景

• 适合：个人开源项目、小团队（5 人以下）、希望在 PR 阶段自动捕获基础问题的团队
• 不适合：大型企业（合规要求、数据安全）、需要自定义评审规则（如特定命名规范、业务逻辑约束）的场景

成本估算

以一个中型 PR（100 个文件变更）为例，每个 chunk 约 10-20 行代码，假设产生 50-100 个 API 请求。GPT-4 的成本约为 $0.03/1K tokens，单次评审成本通常在 $0.1 - $0.5 范围内，对于大多数团队来说完全可以接受。

争议与局限

1. 隐私风险：代码 diff 会上传到 OpenAI API，闭源项目的代码可能面临数据泄露风险。官方建议使用 OPENAI_API_KEY 对应的组织后台开启"不使用数据训练"选项。
2. 评审质量不稳定：GPT-4 对同一段代码的评审结果可能每次不同，有时会漏报，有时会误报。需要团队自行判断哪些建议真正有价值。
3. 无法理解业务上下文：纯代码层面的评审无法感知"这个临时方案是为赶上线临时加的"这类背景信息，AI 有时会给出"正确但不适配"的建议。
4. API 限速：OpenAI API 有 RPM/TPM 限制，超大型 PR 或高频提交可能触发限流。

行业意义与增长趋势

AI Code Reviewer 的成功折射出一个更大的趋势：AI 正在从"辅助生成"向"辅助审核"渗透。相比 Copilot 的"帮你写代码"，Code Review 工具代表了"帮你检查代码"这一新范式——两者的结合覆盖了开发全生命周期。

项目从 2023 年初上线到 1029 Star，Fork/Star 比达到 84%，说明其不仅受个人开发者欢迎，也有大量用户直接 Fork 并部署到自己的组织中。从 GitHub Actions Marketplace 的角度看，它也是"AI + DevOps"类应用中最成功的范例之一。

快速上手

在你的 GitHub 仓库中添加 .github/workflows/ai-review.yml：

name: AI Code Reviewer
on:
  pull_request:
    types: [opened, synchronize]
permissions: write-all
jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: villesau/ai-codereviewer@main
        with:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          OPENAI_API_MODEL: "gpt-4"
          exclude: "**/*.json, **/*.md, yarn.lock"

作者头像：Ville Saukkonen