12 人团队的 Code Review Bot：4 个月真实账单 $184

去年 10 月一个朋友在做 Fintech 的创业公司找我。12 人研发，Node 做 API 层，Go 做结算核心，每周 PR 60-90 个。他们之前招了一个 senior 兼职做 code review，一周 20 小时，后来这哥们跳槽了，招不到合适的接棒。

CTO 问我：「你觉得 Claude 能不能顶上？我们不是要 AI 取代人，我们是真的找不到人。」

我接了，做了 4 个月。现在这个 bot 已经是他们 PR 流程的标配，月账单 $184.32，相当划算。下面写下完整的工程细节。

架构：GitHub Webhook → Agent SDK → Review Comment

整体链路特别简单：

GitHub webhook 监听 pull_request.opened 和 pull_request.synchronize
Lambda 触发，拉 PR diff 和变更文件
按分层规则路由到不同模型
结果回写 GitHub review comment，严重问题 block merge

用的是 Claude Agent SDK（不是裸 API），因为要处理文件读取、历史 commit 关联、跨文件引用这些，Agent 的 tool use 能力比手搓好用太多。这部分可以参考 Agent SDK 生产部署。

分层路由：Haiku 62% / Sonnet 34% / Opus 4%

这是成本控制的核心。不是所有 PR 都需要 Opus，90% 的问题 Haiku 就能接住。

我设计了一个 前置分流器（自己写的，不是 Claude 判断）：

if diff_lines < 50 and files_changed <= 3 and no_core_module:
    → Haiku（格式、命名、简单 bug）
elif touches_core_module or diff_lines > 200:
    → Sonnet（逻辑、边界条件、数据一致性）
elif introduces_new_module or changes_architecture:
    → Opus（架构影响、跨模块依赖）

「核心模块」是在配置里写死的路径列表：/services/settlement/*、/services/risk/* 等等。跑了 4 个月的路由命中分布：

Haiku：62%（大部分是改个 util 函数、加 log、改常量）
Sonnet：34%（真正的业务逻辑变更）
Opus：4%（新模块、大重构）

路由思路我写过多模型路由降本，这个项目是个比较完整的落地案例。

第一版差点被团队关掉

第一版上线一周，PR 作者的接受率 41%。大部分 comment 被标「Not useful」。

我去翻 PR 记录，发现问题很明显：Bot 太啰嗦了。

一个简单的 utils/formatter.go 改动，Bot 输出了 9 条 comment：

建议给 formatDate 函数加 godoc 注释
建议把 const 提到文件顶部
建议 error 信息首字母小写（Go 规范）
建议 import 分组
建议把重复的 time.Time 解析抽成函数
……

这些事没一个算错，但开发者看到 9 条 comment 心态就崩了：一个简单改动，review 比代码还长。

我当时跟 CTO 复盘的时候他说了一句：「人 review 的时候，有经验的 senior 是会挑重点说的，不会每个点都叨叨。你这个 Bot 现在像个刚毕业的实习生。」

改版：只说 must-fix

第二版我做了两个改动：

改动一：分级输出，默认只显示 must-fix

每条 comment 带一个严重级别：

must-fix：会导致 bug、安全问题、违反核心约定
should-fix：性能、可读性问题，建议改但不强制
nit：格式、命名等主观偏好

默认只输出 must-fix。should-fix 和 nit 折叠在 PR 末尾一个 summary 里，开发者想看可以展开。

改动二：prompt 里加了「少即是多」约束

原 prompt 里说「列出所有问题」，改成：

你是一个资深开发者在做 code review。你没有时间写长篇大论，只挑出 3 条以内真正重要的问题。如果没有真正重要的问题，直接说「LGTM」。

这一改特别关键。Claude 在自由创作上确实有点「想多说」的倾向，你不 prompt 它克制，它就倾向于多写。

两个改动之后接受率从 41% 涨到 87%。开发者反馈里出现最多的词是「精准」。

成本账：4 个月 $731.28

把每个月账单都拉出来：

月份	PR 数	总账单	单 PR 成本
12 月	281	$211.47	$0.75
1 月	296	$192.18	$0.65
2 月	247	$163.31	$0.66
3 月	274	$184.32	$0.67

12 月高是因为还在调优，prompt 改了很多次。稳定之后单 PR 成本 $0.65-$0.67。

里面 Opus 调用占到 51% 的成本但只有 4% 的流量，典型的长尾。我考虑过把 Opus 换成 Sonnet + 更长的思考链，但试了几次架构层面的判断 Sonnet 确实不如 Opus，这 4% 的钱省不下来。三款模型的取舍我写过 Claude 家族选型。

还有个省钱的地方是 Batch API。每天晚上有个 cron 任务会汇总当日所有 PR，生成周报（给 CTO 看哪些模块变更最多、哪些开发者 review 通过率高）。这个任务不急着返回，直接走 Batch 拿 50% 折扣，具体可以看 Batch API 省 50%。

跟人工 review 的对比

他们之前那个 senior 做兼职，月薪 1.2 万（20 小时/周的兼职价），折合 1700 美元。Bot 现在月成本 $184，哪怕算上我维护的时间，也不到人工一半。

但这不是替代。CTO 明确说过：Bot 能挡住 80% 的日常问题，让 senior 不用被淹没在琐碎 review 里。他们现在的流程是 Bot 先过，Bot 通过之后再让一个 senior 快速扫一眼架构层面的事。senior 每周花在 review 上的时间从 18 小时降到 4 小时。

踩过的其他坑

跨文件引用：第一版只看当前 PR 的 diff，不看被调用方的代码。后来用 Agent 的 file tool 加了被调用函数读取，bug 检出率涨了 23%。

历史 commit 关联：有些 bug 是「新代码跟三个月前的老代码冲突」，单看 PR 看不出来。我做了个简单的 git log 分析，把相关模块近 90 天的主要变更注入 context。这个思路其实是 Context 记忆系统的延伸。

语言差异：Go 的风格问题跟 Node 差别很大（error 处理、panic 策略、context 传递）。一开始我只写了一套 prompt 两边用，Go 开发者吐槽准确率低。后来拆成两套 system prompt 按语言分发，准确率立刻上来了。

Security review：跟普通 review 是两条独立链路。Security 涉及 SQL 注入、鉴权、密钥泄漏这些，规则更严，输出更保守。这块我参考了 MCP Security Best Practice 里的一些检查清单。

还在迭代的

自动修复提交：对于 nit 级别的问题，直接让 Bot 开一个 follow-up PR 自动改掉，开发者审核合并就行
性能回归检测：检测到新代码可能引入性能问题时，自动跑一次 benchmark 做对比
团队知识沉淀：review 中出现的「历史上踩过的坑」整理成 skill，后续 PR 直接引用。这块跟 Skill Workflow Chains 的思路相关

自己要做 Code Review Bot，记住两条
第一，别让 Bot 每条都叨叨，必须分级输出只说关键问题；第二，路由一定要做，Haiku 能接的活儿别丢给 Sonnet。我在多模型路由降本里有完整的路由配置样板。