10 GitHub Action、代码审查与团队化：把 Codex 放进工程流程

最后一篇讲团队化。

个人用 Codex，重点是提高自己的开发速度。团队用 Codex，重点就变成了：规则一致、权限可控、结果可追踪、代码有人审。

先从代码审查开始

Codex 很适合做 PR 前的自查：

/review

官方 best practices 里提到，/review 可以审查 uncommitted changes、commit，或者对比 base branch。你也可以在 AGENTS.md 里引用团队的 code_review.md，让 Codex 按你们自己的审查标准输出。

好的 review prompt 不要只说“看看有没有问题”，而是：

请按 code review 方式检查当前 diff。
优先找 bug、回归风险和缺失测试。
不要做风格吹毛求疵。
按严重程度排序，给出文件和原因。

这比让它夸你“整体不错”有用得多。

GitHub Action 适合什么

官方 Codex GitHub Action 文档介绍，openai/codex-action@v1 可以在 CI/CD 里运行 Codex，做 PR feedback、质量检查、release 准备、迁移等重复任务。它会安装 Codex CLI，并在你提供 API key 时启动 Responses API proxy，然后按你设置的权限运行 codex exec。

适合：

• PR 自动审查。
• release 前检查。
• CI 失败后给出修复建议。
• 固定 prompt 的质量门禁。

不适合：

• 让所有外部 PR 任意触发高权限任务。
• 把 API key 暴露给不受信任脚本。
• 没有人工 review 就自动合并。

CI 里的安全重点

官方文档特别强调，不要在会 checkout 或运行仓库代码的 workflow 里把 OPENAI_API_KEY 当作 job-level 环境变量随便暴露。Action 提供了安全策略，比如默认 drop-sudo，也可以限制触发用户。

团队落地时，至少做这些：

• 只允许可信用户触发。
• prompt 文件放进仓库 review。
• 使用最窄权限。
• 不让 Codex 直接自动合并。
• 输出结果保留为 artifact 或 PR comment，方便追踪。

团队化的最小规则

我建议从 6 条开始：

1. 每个仓库都有 AGENTS.md。
2. 关键目录有更具体的子目录规则。
3. Codex 生成的代码必须有人 review。
4. CI 不通过不能合并。
5. 涉及权限、支付、数据库、部署必须人工确认。
6. Skills、Hooks、MCP 配置都要进代码审查。

这 6 条比“我们全面拥抱 AI 编程”实在多了。

这套教程的收尾

Codex 最有价值的地方，不是替你“少写几行代码”，而是把工程里的重复认知劳动变少：读项目、找入口、跑检查、看 diff、写总结、审查风险。

你把目标和边界说清楚，它能帮你把事情推进。你把权限和验证丢掉，它也可能把问题放大。学 Codex 的核心不是学一句神奇 prompt，而是搭一套能长期复用的工程协作方式。

参考资料：

• Codex GitHub Action
• Codex app review
• Codex code review in GitHub