一、先说为什么要做这个团队里代码 review 一直是个痛点。小团队没专门的 reviewer代码经常是自审自合——自己写完、自己点 approve、自己 merge。大团队有 review 流程但资深工程师一天要被拉去审十几个 PR根本没时间写自己的代码。更麻烦的是新人交上来的代码总有些低级问题反复出现——变量命名不规范、异常处理只写 print(e)、SQL 查询没走索引、接口没做限流……这些问题都知道不该犯但你不可能每次手动查。于是花了一个周六下午搭了一个自动代码审查机器人。部署一次之后每次有人提 PR机器人自动跑一遍检查把问题标注在 PR 下面。上线两个月新人的代码质量肉眼可见地提升了。因为不需要等人 review机器人秒回反馈循环从半天到一天变成了提交后 30 秒。二、整体架构技术选型三、核心代码3.1 项目结构3.2 入口接收 Webhook# main.pyfromfastapiimportFastAPI,Requestfromreviewerimportreview_codefromgithub_clientimportpost_review_comment appFastAPI()app.post(/webhook)asyncdefhandle_pr(request:Request):payloadawaitrequest.json()# 只处理 PR 打开或同步事件actionpayload.get(action)ifactionnotin(opened,synchronize):return{status:ignored}pr_numberpayload[pull_request][number]repo_namepayload[repository][full_name]diff_urlpayload[pull_request][diff_url]# 获取 PR 的代码变更importrequests diff_contentrequests.get(diff_url).text# AI 审查review_resultreview_code(diff_content)# 回写到 PRpost_review_comment(repo_name,pr_number,review_result)return{status:ok,issues_found:len(review_result)}3.3 AI 审查逻辑# reviewer.pyimportanthropic clientanthropic.Anthropic(api_keyyour-api-key)REVIEW_PROMPT你是一个严格的代码审查员。审查以下 Git diff找出 1. 逻辑问题空指针风险、边界条件遗漏、死锁可能 2. 安全问题SQL 注入、XSS、未验证的用户输入 3. 性能问题N1 查询、不必要的循环、未使用索引的 SQL 4. 代码风格变量命名不规范、过长的函数、重复代码 输出格式每个问题单独一条 [严重] 文件名:行数 — 问题描述 修复建议 [建议] 文件名:行数 — 问题描述 优化建议 如果代码没有明显问题回复 ✅ 未发现明显问题。 以下是需要审查的 diff defreview_code(diff_content:str)-str:# diff 太长就截断Claude 上下文窗口够大但控制成本iflen(diff_content)8000:diff_contentdiff_content[:8000]\n... (diff 过长已截断)responseclient.messages.create(modelclaude-sonnet-4-20250514,max_tokens2000,systemREVIEW_PROMPT,messages[{role:user,content:diff_content}])returnresponse.content[0].text3.4 GitHub API 回写# github_client.pyfromgithubimportGithub gGithub(your-github-token)defpost_review_comment(repo_name:str,pr_number:int,review_body:str):repog.get_repo(repo_name)prrepo.get_pull(pr_number)# 如果已有机器人的评论先删掉旧的bot_usernamecode-review-botforcommentinpr.get_issue_comments():ifcomment.user.loginbot_username:comment.delete()# 发新评论pr.create_issue_comment(review_body)3.5 DockerfileFROM python:3.11-slim WORKDIR/app COPY requirements.txt.RUN pip install-r requirements.txt COPY..EXPOSE8000CMD[uvicorn,main:app,--host,0.0.0.0,--port,8000]3.6 部署三步# 1. 设置环境变量exportANTHROPIC_API_KEYsk-ant-xxxexportGITHUB_TOKENghp_xxx# 2. 构建并启动dockerbuild-tcode-review-bot.dockerrun-d-p8000:8000\-eANTHROPIC_API_KEY$ANTHROPIC_API_KEY\-eGITHUB_TOKEN$GITHUB_TOKEN\--namereview-bot\code-review-bot# 3. 在 GitHub 仓库 Settings → Webhooks 中添加# Payload URL: http://你的服务器IP:8000/webhook# Content type: application/json# Events: Pull requests四、实测效果在三个项目上跑了两个月统计了一组数据说几个具体案例案例 1N1 查询新人写了一个接口循环里查数据库。代码能跑功能正常。人工 review 的时候大概率看一眼就过了——因为逻辑没错。机器人 30 秒标注“第 42-48 行存在 N1 查询建议使用 select_related 或批量查询。” 新人改完之后这个坑就没再犯过。案例 2密钥硬编码有个同事在配置里随手写了 API_SECRET “abc123”。人工 review 很难注意到——代码太多一眼扫过去就是个字符串赋值。机器人直接标了 严重“检测到疑似硬编码的密钥请改用环境变量。”案例 3SQL 注入风险一段拼接 SQL 的代码用了 f-stringqueryfSELECT * FROM users WHERE name {user_input}机器人标注 严重 给了参数化查询的示例代码。这个如果没有机器人大概率被漏掉——因为 reviewer 的注意力在业务逻辑上不在 SQL 写法上。五、几个关键决策的说明5.1 为什么选 Claude 而不是 GPT-4o测试了 50 个代码审查场景混合 Python、Go、JavaScript 代码用两个模型分别跑统计准确率Claude 在代码审查场景上的优势很明显——它对逻辑路径的追踪更准确。GPT-4o 在风格建议上稍好但整体差距 12 个百分点。5.2 为什么不直接用 GitHub Copilot Code ReviewGitHub 官方的 Copilot Code Review 最近也上线了但它做不到这些❌ 不支持自定义审查规则比如强制检查是否加了单元测试❌ 不支持中文审查意见团队内需要中文反馈❌ 审查深度不够——官方版倾向于发现明显问题我们这个能揪出潜在风险我们的版本可以做这些扩展代码里留了接口没写在这篇里# 自定义规则示例CUSTOM_RULES[检查所有 public 函数是否有 docstring,检查所有新增接口是否加了限流装饰器,检查数据库迁移文件是否同时更新了测试数据,]5.3 成本Claude API 审查一次平均消耗约 1500 token输入 1000 输出 500按官方定价 3/百万输入3/百万输入15/百万输出单次审查成本3×0.0013×0.00115 × 0.0005 ≈ $0.0105按一个团队平均每天 10 个 PR 算0.01×10×22工作日2.31/月一个月两块钱。比资深工程师每天花两小时 review 代码的成本低三个数量级。六、局限与改进方向坦诚说当前版本也有问题误报率约 14%。 AI 偶尔会把正常的代码标记为问题。目前的处理方式是人工复核——机器人标注的问题reviewer 看一眼判断是否误报。不支持跨文件分析。 只审查 diff 内容看不出这个函数改了之后会影响其他模块。这个问题计划通过 RAG 方案解决把整个项目的代码向量化审查时检索相关上下文一起喂给 AI。不支持业务逻辑深度审查。 比如这个电商优惠券规则和另一个冲突了——这种需要理解业务语义的判断当前做不到。这三个是后续优化的重点方向。七、完整代码仓库以上所有代码已在 GitHub 上开源Clone 下来填上 API Key 和 Tokendocker-compose up -d 就能跑起来。有遇到部署问题的或者想增加自定义审查规则的欢迎提 issue。后续更新会陆续加进去跨文件分析、自定义规则热加载、审查结果仪表盘。总结写这个机器人的初衷很简单不想在重复性 review 上浪费时间。做完之后发现了一个更好的价值反馈速度决定成长速度。以前新人写了一段有问题的代码要等半天才知道有问题。现在 30 秒就知道了。反馈越快纠正越快成长越快。如果你也在为代码 review 头疼花一个下午搭一个。搭完回来告诉我效果。