Codex GitHub 集成：在代码审查中让 Codex 帮你看 PR

适用场景

这篇手册适合希望把 Codex 放进 GitHub PR 流程的团队。它可以帮助检查 diff、指出潜在风险、总结改动和提醒缺失测试，但不应替代人工责任。

OpenAI 官方文档介绍了 Codex 的 GitHub 代码审查集成。具体安装和权限配置应以当前官方页面为准。

步骤 1：先确定审查目标

不要只让 Codex “看一下 PR”。更好的方式是说明审查重点。

示例：

请重点检查这个 PR 是否影响文章 URL、SEO 元数据、RSS 和 sitemap。
如果发现风险，请按严重程度列出文件和原因。

不同项目可以设置不同关注点：

• 前端项目：布局、可访问性、构建、状态管理。
• 内容站：slug、frontmatter、source、SEO。
• 后端项目：权限、数据一致性、迁移风险。
• 安全项目：输入验证、敏感信息、依赖风险。

步骤 2：控制 GitHub 权限

集成类工具通常需要仓库权限。配置前应确认：

• 需要访问哪些仓库。
• 是否需要读写权限。
• 是否能评论 PR。
• 是否能触发工作流。
• 是否能读取私有代码。

建议遵循最小权限原则：只给当前任务和仓库需要的权限。

步骤 3：让 Codex 输出可执行意见

好的 review 不只是“这里可能有问题”，还应说明影响和建议。

可以要求：

请按严重程度输出 findings。每条包含文件位置、问题、影响和建议修复方式。
如果没有发现问题，请说明剩余风险或未覆盖测试。

这能让 Codex 的评论更接近工程 review，而不是泛泛建议。

步骤 4：对大型 PR 先拆分范围

过大的 PR 会降低审查质量。可以先要求 Codex 做概览，再分模块审查。

流程示例：

• 先总结 PR 改了哪些区域。
• 标出风险最高的模块。
• 针对高风险模块做详细 review。
• 最后检查测试和文档是否匹配。

不要期待一次评论覆盖所有细节。

步骤 5：把团队 review 标准写进项目规则

如果团队希望 Codex 长期按固定标准审查，可以把标准写进 AGENTS.md 或 review 指南。

示例：

## Review 标准

- findings 优先，按严重程度排序。
- 必须指出文件和原因。
- 只提出可执行问题，不写泛泛建议。
- 如果没有发现问题，要说明测试缺口。

这样 Codex 在 App、CLI 或 GitHub 集成中都能保持一致风格。

常见错误

不要让 Codex 自动合并 PR。它可以辅助审查，但合并责任应留给团队。

不要给过大的权限。只开放需要的仓库和操作。

不要把过大的 PR 交给一次自动审查。先拆分范围更可靠。

不要忽略 CI。Codex review 和自动测试应互相补充。

小结

Codex GitHub 集成适合把 AI 审查加入 PR 流程。关键是明确审查目标、控制权限、要求可执行 findings，并保留人工合并责任。