AI Code Review 自动化接入实战：30分钟给项目装上智能审查
接手一个遗留项目，PR 里全是缩进不一致、变量命名混乱、缺少边界检查的问题，人工 review 成了体力活，我决定用 AI 做自动化 Code Review。
问题是什么
团队从 3 人扩张到 10 人，PR 数量翻了 4 倍。每次 review 都在重复同样的事：提醒别人加空指针判断、统一错误处理风格、补单元测试。
更头疼的是，合并后才发现没覆盖的边界条件上了生产。
人工 review 应该聚焦在架构设计和业务逻辑上，不是抓这些 lint 规则的漏网之鱼。我需要一个自动化工具，在 PR 提交时就自动跑一轮 review，把低级问题筛掉，留给人类的才是真正值得讨论的变更。
解决思路
我调研了几类方案：
| 方案 | 优点 | 缺点 |
|---|---|---|
| GitHub CodeQL / SonarCloud | 深度静态分析，免费 | 规则死板，误报多，没有上下文理解 |
| OpenAI GPT-4 API 自建 | 灵活可控，理解代码语义 | 成本高，需要自己搓集成 |
| 开源工具 + 本地 LLM（ollama） | 零成本，数据不出网 | 需要 GPU，小模型效果一般 |
最终选了 GitHub Actions + OpenAI API。成本可控（每次 review 约 $0.02），配置简单，GPT-4 对代码上下文的理解远超静态分析工具。
操作步骤
步骤1：创建 GitHub Actions 工作流
在项目根目录创建 .github/workflows/ai-code-review.yml：
name: AI Code Review
on:
pull_request:
types: [opened, synchronize]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Get diff
id: diff
run: |
DIFF=$(git diff origin/${{ github.base_ref }}...HEAD -- '*.py' '*.js' '*.ts' '*.go')
# 限制 diff 长度，避免 token 超限
echo "diff=${DIFF:0:50000}" >> $GITHUB_OUTPUT
- name: AI Review
uses: openai/gpt-4-review@v1
with:
openai-api-key: ${{ secrets.OPENAI_API_KEY }}
diff: ${{ steps.diff.outputs.diff }}
fetch-depth: 0很关键——默认的 shallow clone 拿不到历史 commit，diff 会为空。
步骤2：配置 OpenAI API Key
到 GitHub 仓库 Settings → Secrets and variables → Actions，添加 OPENAI_API_KEY。
有个坑：不要直接用你的个人 API Key。开一个 dedicated 的 API Key，加上用量上限：
# OpenAI 后台设置硬上限
Usage limits → Hard limit → $10/month
我有个同事忘了设上限，一个下午被 CI 跑了 $37——因为有人 push 了 6 次。
步骤3：写 Prompt
Action 的核心是 prompt。在 repo 里建 .github/ai-review-prompt.md：
你是资深代码审查者。请 review 以下 diff，按严重程度分类：
## 严重缺陷（必须修复）
- 空指针 / 未处理 nil
- 并发安全问题
- SQL 注入或其他安全漏洞
- 资源未释放
## 改进建议（建议修复）
- 缺少边界检查
- 错误被静默吞掉
- 日志不足或过度日志
## 代码风格（值得讨论）
- 命名不符合项目规范
- 重复代码可抽象
- 函数过长
输出格式要求：
- 每条评论标注**文件:行号**
- 给出**修改建议代码**
- 如果是误报，明确说"无需处理"
然后在 Action 中引用它：
- name: AI Review
uses: openai/gpt-4-review@v1
with:
api-key: ${{ secrets.OPENAI_API_KEY }}
prompt-file: .github/ai-review-prompt.md
diff: ${{ steps.diff.outputs.diff }}
步骤4：加增量 Review 逻辑
全量 diff 每次都 review 太浪费。改成只 review 新增/修改的代码：
- name: Get incremental diff
id: diff
run: |
# 只取新增和修改的行（排除删除）
DIFF=$(git diff origin/${{ github.base_ref }}...HEAD \
--diff-filter=ACM -- '*.py' '*.js' '*.ts' \
| grep -E '^(\+|---|\@\@)' \
| head -c 30000)
echo "diff<<EOF" >> $GITHUB_OUTPUT
echo "$DIFF" >> $GITHUB_OUTPUT
echo "EOF" >> $GITHUB_OUTPUT
用 head -c 30000 是因为 GPT-4 的 context 有限。超过 30K 字符的 diff 我会拆成多个 chunk 分批 review。
步骤5：结果发布为 PR Comment
写一个小脚本把 review 结果贴回 PR：
# post_review.py
import os
import json
from github import Github
g = Github(os.environ["GITHUB_TOKEN"])
repo = g.get_repo(os.environ["GITHUB_REPOSITORY"])
pr = repo.get_pull(int(os.environ["PR_NUMBER"]))
with open("review_result.md") as f:
body = f.read()
# 删除旧 review comment（避免堆叠）
for comment in pr.get_issue_comments():
if comment.user.login == "github-actions[bot]":
comment.delete()
pr.create_issue_comment(body)
在 workflow 最后加上：
- name: Post Review Comment
run: python .github/post_review.py
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
PR_NUMBER: ${{ github.event.pull_request.number }}
删除旧 comment 再重建，不是一直追加——不然 PR 页面上全是 AI 评论，人类 reviewer 根本找不到重点。
结果与总结
跑了两周，效果显著：
- 75% 的格式/命名问题在人工 review 前就被 AI 抓出来了
- PR review 周期从平均 4 小时缩短到 1.5 小时
- 最意外的收获：AI 在 SQL 注入检测上比团队里一半的人强
踩过的坑：
- Token 超限是最频发的问题。大 PR 自动跳过，改用小 PR 强制拆分 Review。
- 误报率约 15%。一开始大家觉得烦，后来我加了 "无需处理" 标记，接受度明显提升。
- 不要 review 自动生成的代码（migration、generated proto）。在 diff 过滤时排除这些文件。
- 上下文不足导致误判。单文件 diff 让 AI 看不到相关函数定义——我在 prompt 里加了一句 "如果上下文不足请标注 [context-needed]"，让人类 reviewer 知道这是值得看的点。
延伸思考
这套方案还有几个方向可以深挖：
- 多模型组合：小 diff 用 GPT-4o-mini（$0.15/M token），大 diff 才用 GPT-4，成本能再降 60%
- 本地知识库增强：把项目的架构文档、编码规范塞进 RAG，让 AI review 更贴合团队约定，而不是泛泛的通用建议
- Review 质量打分：收集每次 AI review 的采纳率，低于 30% 的 prompt 需要优化。数据驱动调教比凭感觉改 prompt 靠谱得多
- 自动创建 issue：对于反复出现的同类问题（比如 "这个 package 又有安全漏洞"），自动提 issue 并 assign 给负责人
AI Code Review 不是替代人，而是把人的精力释放给真正有价值的问题。在 PR 里看到 AI 已经筛过一轮后，我的回复从"这里少了个 err check"变成了"这个逻辑可以换个思路"——这才是 review 该有的样子。
评论已关闭！