Codex CLI 真实编程工作流：从打开终端到合并 PR 的完整路径

TL;DR — Codex CLI 装好之后，真正卡效率的不是模型水平，是几个工作流细节没调对：会话起来时选错档位、上下文喂得太少、审批弹窗每分钟一次、断线之后不会找回上下文。把 @、--add-dir、/permissions、codex resume、codex exec、MCP 这几条组合用顺，效率能翻倍。下面按一天里事情发生的顺序讲，配 OfoxAI 国内可用的最小配置。

写在前面：本文跳过装机环节

如果你还没装 Codex CLI，或者卡在网络代理、API Key、config.toml 字段含义这些问题上，先看 Codex CLI 进阶配置：自定义 API、多模型切换与 config.toml 完全指南 把环境跑通再回来。本文假设你已经能 codex 起来对话，关注的问题是：装好之后，怎么从一句模糊需求走到一份能合的 PR。

第 1 步：起会话时就把模型档位选对

打开终端，敲 codex，进 TUI。第一件事不是开始打字，是按 /model 看当前用的是哪个模型。

OfoxAI 上 Codex 这边常用的三档分配是：

• openai/gpt-5.5 — 当前最新旗舰，复杂重构、跨文件改动、写新模块首选。1M 上下文，慢一点但少返工。
• openai/gpt-5.4-mini — 单文件修 bug、加测试、改文案。响应快，便宜。
• openai/gpt-5.3-codex — 纯代码生成场景（“给我一个 retry 装饰器”），prompt 短、输出代码为主。

/model 是会话级切换，下次开 codex 又会回到 config 里的默认。如果你 70% 时间都用 mini，把默认改了：

# ~/.codex/config.toml
model = "openai/gpt-5.4-mini"
model_provider = "ofoxai"
model_reasoning_effort = "medium"

model_reasoning_effort 是个被低估的旋钮。简单 bug 用 low 能省一半 token；架构级改动开 high，模型多想几轮再下手。

第 2 步：让 Codex 看见全部上下文

模型再聪明，看不到代码也是瞎猜。Codex CLI 有三种喂上下文的姿势，按精确度从低到高：

@ 模糊搜文件 — 在 composer 里输 @user，会列出所有文件名带 user 的候选，回车塞进 prompt。比起手动复制路径快得多。

--add-dir 多项目协同 — 默认 Codex 只能改 cwd 下的文件。要它同时读 monorepo 里的另一个 package：

codex --add-dir ../shared-utils --add-dir ../api-types

这两个目录一并加入可读写域，模型能同时看见类型定义和实现。

--cd 不切目录换工作根 — 想让 Codex 在另一个仓库里干活又不想 cd：

codex --cd ~/work/billing "把这个 webhook 处理器加上重试"

如果你常用 VS Code / Cursor，OpenAI 的 Codex IDE 扩展和 CLI 共享同一份 ~/.codex/config.toml 和登录态，可以直接在编辑器里把当前文件丢给同一个 agent 处理，省下 cat file.py 整段粘贴的步骤。

第 3 步：审批流——让 Codex 解释计划再执行

Codex 默认会在做”危险动作”前停下来等你确认。这个机制不要直接关掉，而是调到合适的颗粒度。

/permissions 三档：

• Read-only — 只读，所有写操作都问。新接触代码库时用这个跟模型对一遍方案。
• Auto（默认） — 工作区内读写自动进，跑外部命令、装包、网络访问要确认。
• Full Access — 全开，仅在临时容器或一次性脚本里用。

实际工作里 Auto 够 90% 场景。剩下 10% 会被这种审批打断：跑测试、pnpm install、git push。两条路降低打断频率——

完全信任的环境里把 approval_policy 调成 never（仍受沙箱约束）：

approval_policy = "never"
sandbox_mode = "workspace-write"

更精细的做法是写 ~/.codex/rules/default.rules，用 Starlark 把常跑命令显式 allow，其它命令保持 on-request：

prefix_rule(
    pattern = ["pnpm", "test"],
    decision = "allow",
    justification = "Allow pnpm test without prompt",
)
prefix_rule(
    pattern = ["pytest"],
    decision = "allow",
    justification = "Allow pytest without prompt",
)

写完用 codex execpolicy check -- pnpm test 验证规则确实命中。

第 4 步：用 /diff 和 /review 做代码审查

模型给你写完一坨代码，下一步不是直接 accept。两个命令一定要用：

/diff — workspace-aware，只显示这次会话改过的文件，按文件聚合。比 git diff 干净，因为它会把模型还在编辑的中间状态也排除掉。

/review — 让 Codex 自己 review 自己。听起来像左右互搏，实际很有用：模型在生成代码时容易乐观，review 模式会更挑剔，常常把”少了 null check”、“测试只覆盖了 happy path”这种问题钓出来。

/review 是交互式的，敲下去会列出三种模式：审未提交改动、对比某个 commit、对比某条本地分支与上游的合并基（写完一个 feature 提交 PR 前跑一次，能省 reviewer 不少回复）。要换更强的模型专门跑 review，在 config.toml 里加 review_model = "openai/gpt-5.5"。

第 5 步：会话中断了怎么办

终端崩了、SSH 掉线、按错快捷键，30 分钟的对话没了。这是大多数人放弃 CLI 工具的瞬间。Codex 的 resume 解决这个：

# 接最近一次
codex resume --last

# 列所有会话挑一个
codex resume

codex resume 会出一个选择器，按时间倒序列出近期会话，标着工作目录、最后一条消息、token 用量。挑一条 enter，整个上下文（包括之前的 plan、approvals、文件 diff）都还在。

实战习惯：复杂任务前先 codex resume --last 确认上次状态，避免重新解释一遍 context。要从某个历史节点分支出去做新尝试又不污染原会话，用 codex fork --last，或者会话里直接敲 /fork。

第 6 步：codex exec 把工作流塞进 CI

到这一步你已经能在 TUI 里高效干活了。下一层是把”模型该做的事”自动化。

codex exec 是非交互模式，无 TUI、走 stdout、可管道：

codex exec "基于 git diff HEAD~1 给出 review 评论，markdown 格式"
codex exec --model openai/gpt-5.4-mini "扫一遍 TODO 标记，输出 JSON 列表"

放进 GitHub Actions 大概长这样：

- name: Codex Auto Review
  env:
    OFOXAI_API_KEY: ${{ secrets.OFOXAI_API_KEY }}
  run: |
    codex exec --skip-git-repo-check \
      "review the diff vs origin/main, post findings as markdown" \
      > review.md

--skip-git-repo-check 在 CI 容器里必加，不然会被 git 安全策略拦下来。

常见用法：PR 触发时自动 review、nightly 跑一遍 lint warning 给修复建议、每周扫一次 TODO 出 issue 列表。

第 7 步：用 MCP 给 Codex 接团队内部工具

Model Context Protocol（MCP）是 Anthropic 那边定的标准，OpenAI Codex 也支持，所以你写过的 MCP server 可以同时被 Claude Code 和 Codex CLI 用。

在 ~/.codex/config.toml 里加：

[mcp_servers.linear]
command = "npx"
args = ["-y", "@linear/mcp-server"]
env = { LINEAR_API_KEY = "lin_api_..." }

[mcp_servers.postgres]
command = "uv"
args = ["run", "mcp-server-postgres", "--connection-string", "$DB_URL"]

下次 codex 启动会自动拉起这两个 server，敲 /mcp 就能看到当前已注册的 server 和工具状态。模型现在能直接查 Linear 工单、跑 SQL 查数据，不再需要你手动复制粘贴。

排查 MCP 不通的三个动作前面 FAQ 里写过，最常见还是 npx 包没拉下来——日志在 ~/.codex/log/，第一次接入时盯着看一眼最稳妥。Codex 这边的报错风格和AI API 报错排查指南里写的那套基本一致，遇到模型相关错误码可以直接对照查。

第 8 步：高级用法速览（图片输入、远程 TUI）

下面这两个能力不是每天都用，但用上一次就回不去。

图片输入 — codex -i screenshot.png "解释一下这个报错"，把截图直接喂给模型。前端调样式时特别顺手，“按钮没居中”再怎么描述也不如直接丢张图。

远程 TUI — 在公司开发机起 codex app-server --listen ws://0.0.0.0:4500，本地用 codex --remote wss://devbox:4500 接进来（生产环境记得配 --ws-auth 加 token）。算力在远端、TUI 在本地、本机内存不掉，Mac Air 用户狂喜。

国内开发者的两个现实问题

网络稳定性 — Codex CLI 的国际线路偶尔会抖。OfoxAI 走国内 CDN，把 base_url 切成 https://api.ofox.ai/v1，延迟从 800ms+ 降到 100ms 以内，断流概率明显降低。

Provider 切换 — 同时配 OfoxAI 和 OpenAI 直连两个 provider，关键时刻能切回原厂做对照测试。具体 [model_providers.*] 字段写法，Codex CLI 进阶配置完全指南那篇有完整模板可以直接抄。

如果你还在挑工具，Vibe Coding 工具横评 把 Cursor、Windsurf、Roo Code、Claude Code 和 Codex CLI 放在一起跑过同样任务，能直观看到各自适合什么场景。重模型本身能力的话，Claude Code 国内使用 + Opus 4.6 编程体验 是另一条主线，和 Codex CLI 互不冲突，很多人两边都开。

几个常见踩坑

坑 1：审批弹得太多 — 默认 on-request 在新项目里会被烦死。要么把 approval_policy 调成 never（仍受沙箱约束），要么写 ~/.codex/rules/default.rules 把 pnpm test、pytest、cargo build 这些常跑命令显式 allow，打断频率立刻降下来。

坑 2：context 窗口溢出 — /compact 会把历史消息压缩成摘要，大幅释放窗口。一个 5 小时的会话不 compact 一下，token 成本能翻三四倍。

坑 3：模型选了不存在的 id — 写错 model 名字，第一次调用才报 404。会话里敲 /debug-config 能直接打印当前生效的 model、provider、approval 策略，CI 里尤其重要，免得跑到一半才发现。

坑 4：MCP server 装了但 Codex 看不到 — 八成是 config.toml 写在了项目级 .codex/config.toml 但没信任项目（首次打开会有信任提示，跳过了就不会加载）。回到该目录重开 codex 选信任，或者直接把配置挪到 ~/.codex/config.toml 全局生效。

写在最后

“AI 帮我写代码”这件事 Cursor、Claude Code、Codex CLI 都能做。Codex CLI 的特殊之处在于全程都在终端里——同一个 tmux 窗口能开会话、查 git、跑测试、审 diff，不用切走。习惯键盘流的开发者用一周就回不去 IDE 了。

上面这 8 步真正跑顺，写代码的节奏会从”我打字、模型应答”过渡到”我描述意图、模型执行、我审结果”。中间会有摩擦——审批策略调过好几轮、MCP server 装了好几次才稳——但调好之后效率确实不一样。OfoxAI 把国内访问那道坎踏平了，剩下的就是把这套节奏养成习惯。