从个人工具到团队流水线

9.1 第一道防线：提交前的本地评审

最便宜的问题是在提交前被发现的问题。在会话里执行：

/review

它会以只读子回合运行——不写你的工作区，只审，然后把结论作为一条独立记录呈现出来。可选的审查基准包括：对比某个基线分支、审未提交的改动、审某一个提交，或者给出自定义的审查指令。

为什么这一步有价值：Codex 刚刚才写完这段代码，它的”自我评审”确实存在盲区，但它对你没让它注意的东西（比如你没提但 AGENTS.md 里写了的规则）反而查得出来。把 /review 当成提交前的自动 checklist，而不是当成质量保证。

也可以从命令行直接跑：

codex review

开启方式：先为仓库配置好 Codex 云端，然后在 https://chatgpt.com/codex/settings/code-review 为该仓库打开代码评审。这一步需要你在仓库上有 push 或 admin 权限。

用法：

一个重要的设计取舍：Codex 只报 P0/P1 级别的问题。这意味着它会主动放过大量”可以更好但不影响正确性”的意见。这是刻意的——评审机器人最大的失败模式是噪音过多导致所有人开始无视它。

评审规则来自 AGENTS.md 里的 ## Code Review Rules 小节（见第5章）。规则要写在离被管辖代码最近的那份文件里，根目录写通用规则，子目录写该模块特有的规则。

codex exec 是非交互模式，专门用于脚本和 CI。它把过程输出到 stderr，最终结果输出到 stdout，所以可以直接参与管道。

基本用法：

codex exec "总结这个仓库的目录结构"

几个关键参数：

真正好用的是管道形态——把失败信息喂给它：

npm test 2>&1 | codex exec "总结失败原因并给出修复方案" | tee summary.md

也可以用标准输入作为完整提示词，或者接着上一次的会话继续：

cat prompt.txt | codex exec -
codex exec resume --last "继续下一步"

在 GitHub Actions 里，官方提供了现成的 action，用法形如：

- uses: openai/codex-action@v1
  with:
    openai-api-key: ${{ secrets.OPENAI_API_KEY }}
    prompt: "Run tests and fix failures"

云端任务跑在隔离环境里，可以从网页、GitHub、GitLab、Linear、Slack 发起。它和本地 CLI 的核心区别是：任务在后台跑，你可以同时干别的，而且可以并行跑几个方案做对比。

使用前需要先配置环境：这个仓库需要哪些依赖、哪些工具、哪些环境变量和密钥。这一步是云端任务成败的关键——环境配不对，任务会卡在”装依赖失败”上。

任务完成后，你看到的是摘要和 diff。可以让它继续改，也可以直接开一个 PR。本地想把云端的改动拉下来接着做，用：

codex apply

什么任务值得丢到云上：耗时长、你不需要盯着、且边界清楚的。比如”把这个模块的测试覆盖率从 40% 提到 80%“。什么不适合：需要频繁交互澄清的、依赖本地特殊环境的、边界模糊的探索型任务。

全开会导致同一个问题被报四遍，团队很快会开始无视它。一套务实的分工：

新团队的推荐引入顺序：先只开 PR 评审，跑两周，看它报的问题准不准、AGENTS.md 的规则要怎么调。稳定之后再加 CI 检查。本地 /review 交给个人自愿使用。云端任务最后接，因为它对环境配置的要求最高。