10 GitHub Action、代码审查与团队化：把 Codex 放进工程流程
系列进度
Codex 从零教程 · 第 10 / 10 篇
整理说明
这篇内容怎么整理
郭震 · 2026-06-04
阅读路线
先按这条路线读
先抓住主线，再回到代码、配置和图文细节，读起来会更稳。
图文索引
按图先建立主线，再跳回正文核对步骤、配置和判断标准。
查看大图最后一篇讲团队化。
个人用 Codex，重点是提高自己的开发速度。团队用 Codex，重点就变成了：规则一致、权限可控、结果可追踪、代码有人审。
把 Codex 接进 GitHub 后，我不会让它绕过团队流程。更稳的做法是让它生成草稿 PR、补测试、解释 diff，再交给人审和 CI 决定能不能合并。
查看大图团队化的关键不是让 Codex 权限最大，而是让每次变更可追踪。谁触发、改了哪些文件、跑了哪些检查、谁批准，这些记录比“自动完成”更重要。
先从代码审查开始
Codex 很适合做 PR 前的自查：
查看大图接入 GitHub Action 和代码审查时，先确认触发条件、检查项、审查范围、合并权限和失败回滚方式。
/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。
查看大图看完《GitHub Action、代码审查与团队化：把 Codex 放进工...》后，建议用一分钟复盘：关键概念是否分清、练习步骤是否可复现、结论能不能换成自己的话。
适合：
- 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 条开始：
- 每个仓库都有
AGENTS.md。 - 关键目录有更具体的子目录规则。
- Codex 生成的代码必须有人 review。
- CI 不通过不能合并。
- 涉及权限、支付、数据库、部署必须人工确认。
- Skills、Hooks、MCP 配置都要进代码审查。
这 6 条比“我们全面拥抱 AI 编程”实在多了。
这套教程的收尾
Codex 最有价值的地方，不是替你“少写几行代码”，而是把工程里的重复认知劳动变少：读项目、找入口、跑检查、看 diff、写总结、审查风险。
查看大图如果想把《GitHub Action、代码审查与团队化：把 Codex 放进工程流程》用到自己的任务里，可以先缩小场景，只验证一个最关键的判断点。
查看大图学完《GitHub Action、代码审查与团队化：把 Codex 放进工程流程》后，不妨换一个自己的场景试一次，重点观察输入、处理和输出是否能对应起来。
你把目标和边界说清楚，它能帮你把事情推进。你把权限和验证丢掉，它也可能把问题放大。学 Codex 的核心不是学一句神奇 prompt，而是搭一套能长期复用的工程协作方式。
参考资料：
继续阅读
