文章摘要
一款名为SGLangReviewInbox的工具已开源，它将接收他人请求进行代码审查的PR，交由Codex根据特定审查规则完成审查、复核、CI跟进、批准及合并等操作，仅需人工处理高风险PR。相关项目链

一款名为SGLang Review Inbox的工具已开源，它将接收他人请求进行代码审查的PR，交由Codex根据特定审查规则完成审查、复核、CI跟进、批准及合并等操作，仅需人工处理高风险PR。

相关项目链接，欢迎关注和使用：

0x0. 前言

首先要感谢OpenAI向开源框架贡献者提供的免费Codex Pro额度，本次升级后获得了200美元的额度支持，相当于享受了一年的该会员服务。由衷感谢OpenAI的支持。

但不得不吐槽的是，目前最新版本的模型在上下文压缩方面表现不佳，当对话较长时使用难度较大，希望后续能推出更优的模型，避免出现降智问题。

此前在相关讨论中曾提到，随着越来越多的代码由智能体生成，代码审查环节正面临人员短缺的问题，这一情况在相关项目中感受尤为明显。目前每天会收到大量来自Slack、私信、PR频道的PR请求，大部分由AI生成且改动较大，逐一查看、等待CI结果、跟进作者修改等工作占据了大量时间，每周消息量超过99+，几乎没有时间登录相关平台。

受相关代码审查博客启发，本周开发了一款可在本地运行的工具SGLang Review Inbox，它将他人请求的PR收集起来，交由Codex根据特定审查规则进行审查，之后完成复核、CI跟进、作者讨论、批准及合并操作，最后在原Slack线程中反馈结果，仅需人工处理高风险PR。

该工具从10月30日下午开始正式运行，截至目前约两天时间，共接收95个PR，智能体自行批准了29个，自动合并了7个。配套的审查规则也随相关工具v0.1.6版本更新，本文将一并介绍相关内容，所有代码均已开源，欢迎应用到自身的开源项目管理中。

0x1. sglang-humanize-review 本次更新内容

在之前的版本中，该审查规则主要依赖2026年7月27日之前的公开审查语料，但之后相关项目进行了多次重构，kernels和tests的组织方式发生了变化，仅使用旧语料会导致智能体按旧标准判断，容易遗漏新标准下的问题。

本次更新将当前的审查标准直接融入工具中，主要包括三部分：

  • maintainer-standards.md（必读）：规定了审查顺序、改动尽量小、重构后代码的存放位置、避免新增不必要的flag和环境变量、测试需覆盖改动路径且长期保留、PR描述要求、合并条件及评论规范等，与旧语料冲突时以此为准。
  • refactor-conventions.md：从60个已合并的重构PR中整理出30条规则，每条对应diff特征和失败守卫测试。
  • 近期审查语料：补充了2026年7月27日至10月30日的466个审查事件、204个公开PR，格式与主语料一致，可直接使用检索脚本。

实际使用中发现，当前模型本身查找bug的能力已很强，审查规则更重要的是明确项目的规矩和底线，比如哪些问题必须阻止，哪些无需在意，否则智能体可能会反复要求作者添加测试或benchmark，导致作者和审查者都疲惫不堪。另外，最重要的代码审查需使用最强思考强度的模型，才能避免遗漏bug。

0x2. PR在Review Inbox中的处理流程

PR在该工具中的处理流程大致如下：

接收来自Slack、私信、PR频道或GitHub上的PR
 -> 分诊：按改动路径和规模分为T1 / T2 / T3
 -> 按审查规则进行审查
 -> 另一个智能体复核每个阻塞问题
 -> 存在真实bug：反馈给作者并等待修改
 -> 无阻塞问题：T1 / T2直接批准，T3留待人工处理
 -> 跟进CI：触发、重跑、归因，必要时@作者
 -> 合并PR，在原Slack线程反馈结果

点开一个PR，可查看分诊结果、改动内容、执行流程，以及批准、重新审查等操作。

往下是每个问题的触发场景、修改建议、复核理由，以及最终会发布的评论原文，再往下是相关测试和当前CI状态。

经过两天调试，总结出几条关键规则：

  • 只有真实bug才阻止PR：缺测试、缺benchmark等意见为非阻塞，同一要求不反复提出。之前智能体反复要求作者重测性能，导致作者反感，已优化。
  • 每个阻塞问题需经复核，复核不通过的不发布。
  • GitHub上的回复为指令：回复“这个不用管”则撤掉对应意见，回复“LGTM”则批准，智能体仅执行指令，不额外回复。
  • CI基本由智能体管理：自动触发、重跑CI，判断基础设施问题（如runner、磁盘），无法判断则读日志；拿不到日志仅重跑，不@作者。
  • 合并需克制：每天最多自动合并10个，间隔至少1小时，标WIP或do-not-merge的不合并；遇到GitHub规则问题（如邮箱未关联）则@作者，不绕开规则。

注意：不能向智能体暴露敏感token，仅允许其发布评论和合并PR。

0x3. 控制token消耗

该工具运行时token消耗较大，最初全速运行21小时就使用了约2600万token，很快耗尽了账号的周额度，其中审查占六成，其余为复核、CI归因等。后续采取了多项优化措施：

  • 不再自动帮作者修改代码，之前代修及重新审查占了三分之一的token，改为仅发布评论让作者自行修改。
  • 分时段批处理，每天10:00、15:00、21:00处理任务，其余时间做非token密集型工作。
  • 增量复审，仅复查新改动，合入main则沿用之前结论。
  • CI先按规则判断，无需则不调用智能体；网页中文仅在打开PR时翻译。
  • 设置每日token上限为5M，可网页调整或手动运行，用完会有红色提醒。

按当前用量，后续每天大概3-4M，需再观察几天。

0x4. 部署到自身项目

部署流程较为简单：

git clone https://github.com/BBuf/sglang-review-inbox.git
cd sglang-review-inbox
cp config.example.json config.json
# 替换配置文件中的占位符为自身信息
CODEX_HOME=~/.codex codex login
python3 server.py --config config.json

之后打开本地地址即可，Slack为可选配置，可通过仓库中的文件创建应用并添加token。

几点建议：

  • 先用影子模式运行几天，默认仅查看，再切换自动模式；写操作有单独开关。
  • 流程通用，需替换CI命令、风险区域划分及审查规则，即可应用到其他项目。
  • 也可单独使用审查规则，安装到相关工具中即可。

0x5. 注意事项

该工具也存在代价：

  • 使用自身身份，需先在影子模式测试，避免发布不当内容。
  • 高风险PR仍需人工审查，不能放松CI门槛。
  • token消耗大，注意账号额度。
  • 不能绕过仓库规则，宁可@作者也不使用admin权限。
以上内容不代表本平台立场，仅供读者参考