我搭了一个AI代码审查机器人，每天自动Review PR——从原理到完整实现，且代码不离开内网

上周发了个PR，半小时没人审。自己看了一遍，有个SQL注入没发现。合了，上线了，被安全团队找上门了。

——这场景不陌生吧？

代码审查有两个老问题：没人审和审不细。前者是人的问题，后者是精力问题。连续审5个PR，第6个你基本就在走形式了。

我搭了一个AI代码审查机器人，接在GitHub上，每次开PR自动审查，几分钟出结果。Bug、安全漏洞、性能问题、代码风格，四个维度逐个扫描。不取代人工审查，但能把"走形式"那部分接过去。

今天把整个搭建过程拆开讲，包括架构设计、核心代码、踩过的坑，还有跟商业方案的对比。代码开源，你clone下来就能跑。

先说清楚：它能做什么、不能做什么

能做的：

• 检测常见Bug模式（空指针、资源泄露、并发问题）
• 发现安全漏洞（SQL注入、硬编码密钥、XSS）
• 识别性能问题（N+1查询、不必要的循环）
• 给出可维护性建议（命名、冗余代码、魔法数字）

不能做的：

• 理解跨文件的复杂业务逻辑
• 判断功能是否符合产品需求
• 替代资深工程师的架构审查

一句话：它是一个不知疲倦的初级审查员，不是资深架构师。

把它当成第一道过滤，人工审查集中在它搞不定的部分。

架构：一条流水线

GitHub PR Event (Webhook / Actions) ↓ 获取 PR Diff (GitHub API) ↓ 解析 Diff → 按文件分组 → 过滤非代码文件 ↓ 逐文件调用 LLM 分析（Bug/安全/性能/可维护性） ↓ 汇总审查结果 → 发布 PR Review Comment

五个步骤，每一步都很明确。重点在中间三步。

第一步：拿到Diff

通过GitHub REST API获取PR的diff。关键细节——请求头要用Accept: application/vnd.github.v3.diff，这样直接返回unified diff文本，不需要处理JSON。

async def get_pr_diff(owner, repo, pr_number): url = f"https://api.github.com/repos/{owner}/{repo}/pulls/{pr_number}" headers = { "Authorization": f"token {GITHUB_TOKEN}", "Accept": "application/vnd.github.v3.diff", } async with httpx.AsyncClient() as client: resp = await client.get(url, headers=headers) resp.raise_for_status() return resp.text

为什么用异步？因为后面要调LLM API，同步请求会阻塞。FastAPI + httpx的组合在Python生态里最成熟。

第二步：解析Diff

这是最容易踩坑的一步。unified diff的格式看起来简单，但有几个容易忽略的点——

1. a/ 和 b/ 前缀

git diff的输出，文件路径带a/和b/前缀（--- a/src/main.py / +++ b/src/main.py）。但GitHub API返回的diff有时不带。解析时要注意。

2. 行数不一定对

@@ -1,6 +1,8 @@表示原文件从第1行开始共6行，新文件从第1行开始共8行。但有时候count为0（比如纯新增文件），需要处理边界情况。

3. 大diff会撑爆上下文

一个改了50个文件的PR，diff可能有几万行。LLM的上下文窗口装不下，必须分块处理。

我的方案：按文件分组，过滤非代码文件，超大文件跳过。

# 只审查代码文件 REVIEW_EXTENSIONS = {".py", ".js", ".ts", ".java", ".go", ".rs"} # 超过500行的文件跳过 MAX_DIFF_LINES = 500

过滤非代码文件不是偷懒——审查README.md或package-lock.json的变更没有意义，只会浪费token和产生噪音。

第三步：调用LLM分析

这是核心。prompt设计直接决定审查质量。

我试过三种prompt策略——

策略A：自由审查（"请审查这段代码"） → 结果：泛泛而谈，说了一堆正确的废话

策略B：Checklist式审查（列出检查项，逐项打分） → 结果：太机械，每个文件都差不多，有用的信息被淹没

策略C：维度引导 + 约束条件（最终方案）

审查维度： 1. Bug风险：逻辑错误、空指针、资源泄露、并发问题 2. 安全问题：SQL注入、XSS、硬编码密钥 3. 性能问题：不必要的循环、N+1查询 4. 可维护性：命名、冗余、魔法数字 约束： - 只指出真正的问题，不要为了审查而审查 - 每个问题给具体行号和修改建议 - 代码没问题就直接说"LGTM"

"只指出真正的问题"这句话很关键。不加这句，LLM会觉得必须找出问题，然后开始编——把正常代码硬说成有Bug。加了之后，审查的精准度明显提升。

另一个关键参数：temperature=0.3。代码审查需要确定性输出，不是创意写作。低温度让LLM更稳定地输出一致的结果。

⚠️ 踩坑提醒：LLM在代码审查上的F1分数并不高。

Meta 2025年发布的CodeReviewEval benchmark显示，GPT-4o在"发现真实缺陷"任务上F1约0.58。也就是说——它会漏掉约40%的真实Bug，同时误报约40%。

所以：AI审查是第一道防线，不是最后一道。

第四步：发布评论

通过GitHub API创建PR Review。这里有个坑——

Review Comment vs Issue Comment：

• Issue Comment（POST /issues/{n}/comments）：评论挂在PR上，不关联代码行
• Review Comment（POST /pulls/{n}/reviews）：正式的代码审查，可以关联具体行

用Review Comment，因为它在GitHub的PR界面上显示得更正式，有"Approved" / "Changes Requested" / "Comment"三种状态。我选了"Comment"——只提建议，不block PR。让AI有block PR的权力？那是在给自己找麻烦。

第五步：幂等性

同一PR推了新commit，会触发新的synchronize事件。如果不做处理，之前commit的审查评论还会在。两个选择：

1. 每次审查都发新评论（简单，但评论会越积越多）
2. 更新之前的评论（需要追踪comment ID）

我选了方案1，在评论里加上commit SHA作标识。

简单可靠，不引入状态管理。

两种部署方式

▪ 方式一：GitHub Actions（推荐零运维方案）

# .github/workflows/review.ymlon: pull_request: types: [opened, synchronize] jobs: review: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: pip install httpx pydantic - run: python scripts/review.py --owner OWNER --repo REPO --pr PR --commit SHA env: OPENAI_API_KEY: {{ secrets.OPENAI_API_KEY }} GITHUB_TOKEN: {{ secrets.GITHUB_TOKEN }}

优点：不需要服务器，GitHub免费额度够用。

缺点：每次审查要冷启动，大概多10-20秒。

▪ 方式二：Webhook服务器（适合自托管）

pip install -e ".[dev]" python -m src.main # FastAPI跑在8080端口

需要在GitHub仓库的Webhook设置里配你的服务器地址。

优点：响应更快，可以加缓存和限流。

缺点：要维护一台服务器。

我的建议：先用Actions跑起来，审查量大再切Webhook。

用哪个模型？

支持任何兼容OpenAI API的模型——改OPENAI_BASE_URL和OPENAI_MODEL两个环境变量就行。

⚠️ 踩坑提醒：别用小模型做代码审查。

7B以下的模型（包括deepseek-r1:1.5b）在代码审查任务上几乎不可用——要么漏检严重，要么把正常代码批成Bug。至少用9B以上的模型，或者直接用API。

跟商业方案比，差在哪？

选哪个？

• 3人以下团队，PR不多（<10/天）→ 自建够用
• 10人以上团队，需要稳定可靠 → CodeRabbit免费层或Copilot Review
• 代码不能出内网 → 自建 + 本地模型

完整代码

GitHub仓库：https://github.com/helloworldtang/ai-pr-reviewer

clone下来，配好环境变量，跑通7个测试，接上你的仓库。10分钟搞定。

git clone https://github.com/helloworldtang/ai-pr-reviewer cd ai-pr-reviewer cp .env.example .env # 填入你的配置 pip install -e ".[dev]" pytest tests/ -v # 7个测试全过

💡 一句话带走：AI代码审查不是替代人工，是帮你把"走形式"的部分自动化——省下的精力用在真正需要思考的地方。

你们团队做代码审查吗？是人工审还是用工具？最大的痛点是什么？说说你的情况，帮你看看怎么接AI。

参考来源：

• Meta: "CodeReviewEval: A Benchmark for Automated Code Review using LLMs" (2025) — GPT-4o F1≈0.58 https://arxiv.org/abs/2505.20206
• GitHub REST API: pulls端点diff格式文档 https://docs.github.com/cn/rest/pulls/pulls#custom-media-types-for-pull-requests
• Anthropic: "Building Effective Agents" — 工具设计原则（专用工具优于通用工具） https://www.anthropic.com/engineering/building-effective-agents
• PR-Agent (Codium-ai): 开源AI审查方案参考 https://github.com/The-PR-Agent/pr-agent