代码审查是大多数团队最慢的环节之一——PR 提上去,等同事有空看,再来回讨论,一个改动从提交到合入可能耗掉几小时甚至一天。Ramp 的工程团队最近分享了他们用 Codex(搭载 GPT-5.5)做 code review 的实践:原本需要数小时才能收到的实质性反馈,现在几分钟内就能拿到,并且能直接生成可合入的改进补丁。
这不是"让 AI 替你读 diff 然后输出一段废话"的玩法。Ramp 的做法更像是把 Codex 当成一个始终在线、秒级响应的高级 reviewer,和人类 reviewer 配合使用。
为什么传统 Code Review 慢
核心瓶颈不是"审查本身难",而是等待时间:
- 同事在开会、在写代码、在休假——你排队等反馈。
- 大 PR 让人望而生畏,reviewer 勉强扫一遍就 approve,质量打折。
- 小 PR 虽然容易审,但频繁打断 reviewer 的主线工作,上下文切换成本高。
结果就是:要么慢,要么糙。Ramp 的思路是——让 Codex 先过一遍,给出结构化反馈和可直接采用的修改建议,人类 reviewer 再做最终判断。AI 不替代人,但把"空等"的时间窗口填满了。
Codex 在 Review 中的具体角色
根据 Ramp 的分享,Codex 在他们的流程里承担几件事:
- 逐 diff 段落给出意见——不是笼统说"这段有问题",而是指出具体行、具体风险,并解释原因。
- 生成改进补丁——对发现的问题,Codex 直接输出修改后的代码片段,工程师可以一键采纳或手动调整后合入。
- 识别跨文件影响——当一个 PR 改了 A 模块的接口,Codex 能提醒 B 模块的调用方也需要同步更新。
GPT-5.5 的加持让这些反馈的质量显著提升——逻辑推理更准确,对上下文的理解更深,不再停留在"变量命名不规范"这种表面层。
实践:给你的 PR 流程接入 AI Review
下面是一个可以直接改造使用的 GitHub Actions 工作流,在 PR 创建或更新时自动调用 OpenAI API 对 diff 做 review,并把结果评论到 PR 上。
第一步:创建工作流文件
在仓库 .github/workflows/ai-review.yml 中写入:
name: AI Code Review
on:
pull_request:
types: [opened, synchronize]
permissions:
pull-requests: write
contents: read
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Get PR diff
id: diff
run: |
# 获取 PR 相对于 base 分支的 diff
DIFF=$(git diff origin/${{ github.base_ref }}...HEAD)
# diff 太长时截断,避免超出 API token 限制
echo "diff<<EOF" >> $GITHUB_OUTPUT
echo "$DIFF" | head -c 30000 >> $GITHUB_OUTPUT
echo "EOF" >> $GITHUB_OUTPUT
- name: Call OpenAI for review
id: ai
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
run: |
python3 .github/scripts/ai_review.py \
"${{ steps.diff.outputs.diff }}" \
"${{ github.repository }}" \
"${{ github.event.pull_request.number }}"
- name: Comment on PR
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh pr comment ${{ github.event.pull_request.number }} \
--body-file .github/scripts/review_comment.md
第二步:编写 review 脚本
创建 .github/scripts/ai_review.py:
#!/usr/bin/env python3
"""调用 OpenAI API 对 PR diff 进行 code review,输出结构化评论。"""
import json
import os
import sys
import urllib.request
API_KEY = os.environ["OPENAI_API_KEY"]
MODEL = "gpt-4o" # 可替换为 gpt-5.5 等更新模型
def call_openai(diff: str, repo: str, pr_number: int) -> str:
prompt = f"""你是一位资深工程师,正在审查以下 PR diff。
仓库: {repo}, PR #{pr_number}
请逐段分析 diff,对每个发现的问题:
1. 指出具体文件和行号范围
2. 解释问题原因(安全、性能、逻辑错误、可维护性等)
3. 给出修改建议或改进后的代码片段
如果没有问题,简要说明改动看起来合理的地方。
用中文输出,格式为 Markdown。
Diff:
{diff}
"""
payload = {
"model": MODEL,
"messages": [{"role": "user", "content": prompt}],
"temperature": 0.2, # 低温度保证输出稳定
"max_tokens": 4096,
}
req = urllib.request.Request(
"https://api.openai.com/v1/chat/completions",
data=json.dumps(payload).encode(),
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
},
)
with urllib.request.urlopen(req) as resp:
result = json.loads(resp.read())
return result["choices"][0]["message"]["content"]
def main():
diff_text = sys.argv[1]
repo = sys.argv[2]
pr_number = int(sys.argv[3])
review = call_openai(diff_text, repo, pr_number)
# 写入评论文件,供后续 step 使用
with open(".github/scripts/review_comment.md", "w") as f:
f.write(f"## 🤖 AI Code Review\n\n{review}\n\n---\n*由 AI 自动生成,仅供参考,最终判断由人类 reviewer 负责。*")
if __name__ == "__main__":
main()
第三步:配置 Secrets
在 GitHub 仓库 Settings → Secrets and variables → Actions 中添加:
OPENAI_API_KEY:你的 OpenAI API KeyGITHUB_TOKEN:默认已有,确保 Actions 有 PR 写权限即可
提交一个测试 PR,几分钟后你应该能看到 AI review 评论出现在 PR 页面上。
注意:上面的示例用的是
gpt-4o。如果你的团队有 Codex / GPT-5.5 的访问权限,把MODEL变量替换即可。Codex 的优势在于它不只是"读 diff 然后评论",还能直接生成可采纳的代码补丁——这需要 OpenAI Codex 产品的专用 API,目前仍在逐步开放中。
人类 Reviewer 做什么
Ramp 强调的关键点:AI review 不替代人类 review,而是前置。
实际操作中,他们的分工大致是:
| 职责 | Codex | 人类 |
|---|---|---|
| 逐行找 bug / 安全问题 | ✅ 先扫一轮 | ✅ 最终确认 |
| 跨模块影响分析 | ✅ 提醒关联改动 | ✅ 判断是否真的需要改 |
| 业务逻辑合理性 | ❌ 缺乏业务上下文 | ✅ 核心判断 |
| 代码风格 / 命名偏好 | ✅ 通用建议 | ✅ 团队特有规范 |
| 最终 approve / reject | ❌ | ✅ |
工程师拿到 Codex 的反馈后,先快速筛一遍——采纳合理的修改建议,忽略不适用的,然后人类 reviewer 聚焦在业务逻辑和架构决策上。双方叠加,既快又稳。
采纳前的检查清单
把 AI review 接入流程不难,但要让它真正产生价值而不是变成噪音,有几个实践要点:
- 控制 diff 长度——超过 30000 字符的 diff,模型会丢失细节。拆小 PR 是前提,大 PR 的 AI review 质量会明显下降。
- 低 temperature——review 场景不需要创意,需要准确。
temperature设 0.1–0.3。 - 标注 AI 来源——每条 AI 评论都应明确标注"自动生成,仅供参考",避免误导新人。
- 过滤噪音——AI 会指出一些"技术上正确但业务上不需要改"的东西。团队需要快速形成判断力,别被每条建议拖住。
- 敏感代码隔离——涉及密钥、认证逻辑、金融计算的 diff,不建议发给外部 API。用本地部署模型或跳过 AI review。
Ramp 的经验表明,当 PR 体积控制在合理范围、团队对 AI 反馈建立了筛选习惯后,code review 的平均等待时间从小时级压缩到了分钟级。这不是魔法——是流程设计加上模型能力提升的叠加效果。