两个开发者，同一把刀#

想象两个场景。

场景 A：小王装了 Codex CLI，兴奋地敲下第一个命令。他花了半小时调试 Prompt，终于让它改了一个文件。第二天又花了二十分钟重新描述项目背景，因为上次的会话上下文丢了。一周下来，他觉得"AI 编程好像也就那样"。

场景 B：老张也装了 Codex CLI。他先用十五分钟写了一个 30 行的 AGENTS.md，然后开了三个 worktree，让 Codex 同时跑着三个任务。任务间隙他去喝了杯咖啡，回来后发现 Codex 已经把单元测试修好了。下午他 /goal 存了一个探索性任务，第二天早上 codex resume --last 接着干，连背景都不用重讲。

同样的工具，天壤之别的体验。

这，就是 Codex CLI 的真相：你花在配置上的前两个小时，决定了你后面两百个小时的效率。

一个改变一切的文件：AGENTS.md#

如果你只从本文带走一件事，那就是这个：在项目根目录写一个 AGENTS.md。

Codex CLI 在每次会话启动时都会读这个文件。Claude Code 也会读（它读的是 CLAUDE.md——你可以把其中一个软链接到另一个）。把 AGENTS.md 当成活文档来维护：每一次你纠正了 Codex 两次以上的行为，就应该变成一条规则写进去。

一个能打的 AGENTS.md 长这样：

# AGENTS.md

## 技术栈
- Python 3.12, FastAPI, SQLAlchemy 2.x async
- pytest + anyio，不用 unittest
- Ruff 做 lint，Black 格式化，mypy --strict

## 不要做
- 不要写"复述代码"的注释
- 不要 import unittest.mock — 用 pytest fixtures
- 不要在 src/legacy/ 下创建新文件
- 运行 alembic upgrade 之前必须先跟我确认

## 要做
- 每个新文件顶部加 `from __future__ import annotations`
- 改完代码后跑 `make test path=<文件>` 而不是全量测试
- 新 API 端点统一放在 src/api/v2/

三条黄金法则：

  1. 从小开始。30 行胜过 300 行。太长的 AGENTS.md 会被模型的大脑忽略——就像开发者会忽略 50 页的代码规范文档一样。
  2. 编码你的「否决」。如果你发现自己一周内拒绝了 Codex 同样的建议两次，那下一条规则就该写进 AGENTS.md。
  3. 写行为约束，不要写性格要求。“要简洁"是愿望；“改完代码后必须跑 make test"是可执行的规则。

什么时候 Plan，什么时候直接干？#

Codex CLI 有一个 Plan 模式（/plan 或 Shift+Tab）——让 AI 先收集上下文、提出澄清问题，再动手写代码。这是它的超能力，但也是最大的坑。

用得对，省你半小时纠错。用不对，纯烧 Token。

下面是实战中真正有效的心智模型：

任务类型推荐模式
「给 SearchBar.tsx 的搜索输入加个防抖」直接描述就行
「重构认证模块，让 OAuth 和 SAML 共享同一个 session 模型」/plan 先
「全仓库把 getCwd 改名为 getCurrentWorkingDirectory」直接描述
「排查一下 staging 部署为什么健康检查一直挂」/plan 先
「用 Black 格式化这 40 个文件」直接描述（记得切到 Mini 模型）

一句话心法：如果你能用一句话说清楚改哪个文件、改成什么样，那就跳过 plan。如果你打字解释这个任务就要写一段话，那 plan 模式就是你最好的朋友。

并行时代：Worktree 让你同时开三个活#

Git worktree 是 Codex CLI 的「涡轮增压器」。它让你在同一个仓库里创建多个独立的工作目录，互不干扰。

# 一次性创建三个任务的工作区
git worktree add ../proj-feat-auth feat/auth
git worktree add ../proj-fix-cors  fix/cors
git worktree add ../proj-perf-list perf/list-render

# 三个终端、三个 Codex 会话、互不打架
(cd ../proj-feat-auth && codex)
(cd ../proj-fix-cors  && codex)
(cd ../proj-perf-list && codex)

# 用完了清理
git worktree remove ../proj-feat-auth

为什么这比单纯切分支强？

每个 worktree 有自己的 node_modules、自己构建缓存、自己的 pytest 缓存。在单个工作目录里切分支，所有这些都会失效，Codex 每次都要重新读取项目树。

Reddit 上的共识是：同时开 4–6 个并行 Codex 会话已经成了高级开发者的日常操作。

代价？磁盘空间。一个 2GB 的仓库开 5 个 worktree 大约占 10GB 再加构建产物。对 SSD 完全不是问题，对 256GB 的笔记本稍微揪心。

跨天任务：/goal 让你的上下文活到明天#

Codex CLI 0.128 版本带来了 /goal——一个会持久化的任务对象。你可以声明一个目标，Codex 会在多次会话之间暂停和恢复，而且 TUI 里提供了创建/暂停/恢复/清除的完整控制。

它真正发光的地方：

  • 一个涉及 40 个文件的大规模迁移，你想要一条连贯的工作线，而不是 12 个互相失联的会话
  • 一个事故复盘，你需要反复回到同一个调查场景
  • 一个技术探索，你希望能随时放下、随时捡起，不需要重新解释背景

它大材小用的地方：

  • 任何你能一次坐下来搞定的事情——codex resume --last 就够了
  • 纯粹的一次性探索，你不想对一条工作线做承诺

Skills：当你不该再重复粘贴 Prompt#

你有没有发现，自己每周都在写同样的话？

“帮我 review 一下这次 diff，检查有没有安全隐患…” “按照我们的项目规范新搭一个 API 端点…”

这就是 Skills 要解决的问题。把重复的指令封装成一个 SKILL.md 文件，Codex 每次调用时都能一致地执行。

0.128–0.130 版本把 Skills 和插件提升到了一等公民的地位——支持工作区共享、权限控制、市场安装/升级流程。

一个精简但有效的 Skill 长这样：

# review-pr

被调用时，运行 `git diff main..HEAD`，对照 AGENTS.md 中的「不要做」列表审查每个文件。

输出：
- 按文件列出发现的问题（严重程度：blocker/nit）
- 一段适合贴到 PR comment 里的两句话总结
- 任何你注意到的测试覆盖缺口

不要直接改代码。不要打开跟本次 diff 无关的文件。

一个 10 行的代码审查 Skill，两天就能回本。

MCP 服务器方面，几乎每个人第一天就该配置两个：一个文件系统服务器（作用域限定在仓库内）、一个 git 服务器。其他的？只在你真的需要的时候再加。

模型经济学：GPT-5.5 什么时候是浪费#

Codex CLI 支持会话中切换模型（/model），但大部分人的默认模型是 GPT-5.5——这是最贵的选项。

模型输入/输出 ($/M)什么时候用
GPT-5.5$5 / $30Plan 模式、多文件重构、调试陌生代码
GPT-5.4 Mini$0.75 / $4.5批量重命名、格式化、脚手架、「就做个显而易见的事」
GPT-5.3 Codex$1.75 / $14代码专用变体，当你需要纯粹的代码生成质量
GPT-5.4 Nano$0.20 / $1.25快速解释一段代码、生成 commit message

心法：如果开了 /plan，就该用 GPT-5.5。如果没开，大概率可以降一档。

Reddit 上的共识也印证了这一点：廉价模型在多文件上下文中明显退步，但在小而清晰的任务上几乎看不出差别。

账单爆炸的三大元凶：

  1. 所有任务都开 Plan 模式。Plan 模式会大量读取仓库信息，有用的时候值钱，没用的时候纯烧。
  2. 一刀切用 GPT-5.5。做一个简单编辑，你付了 6–7 倍的 Token 费用，质量完全没必要。
  3. 长会话不 /clear。上下文会累积，六个小时不清上下文，相当于为同一批文件读了十次。

第一周最容易踩的七个坑#

这些都是实战中用血泪换来的教训：

  1. 跳过 AGENTS.md，觉得「这只是给大项目用的」。恰恰相反，小项目每行规则撬动的杠杆更大。
  2. 所有任务都开 Plan 模式。烧 Token、拖慢节奏，对清晰的任务毫无增益。
  3. 一个仓库只用一个 worktree。频繁切分支导致缓存失效、反复重建。
  4. 生产仓库用 Full Access 权限。降到 Auto（允许工作区写入，但需网络/越界操作先确认）或 Read-only。
  5. 长会话不 /clear。上下文膨胀 → 成本上升 → 模型注意力衰退。恶性循环。
  6. 简单任务默认 GPT-5.5。参看上文模型选择。
  7. 把 Skills 当成进阶玩法。一个 10 行的代码审查 Skill，两天就能回本。

Codex CLI 的边界#

公允地说，Codex CLI 不是万能药。它在以下场景会吃力：

  • 重框架魔法的仓库（大量装饰器、代码生成、运行时元编程）。它不一定能追踪谁调用了谁。
  • 「设计一个新系统」。Codex 执行方案的能力很强，但在你真的不知道要什么的时候，它选方案的能力一般。
  • 需要给非开发者使用的漂亮 UI。Codex CLI 从设计上就是一个终端工具，不会变成 Figma。

它不是银弹，但在一万行到十万行的项目里，它能做的事已经足够震撼。

从第一周到第二周#

真相是这样的：

第一周你会觉得 Codex CLI 是一个「Prompt 游戏」。你会花大量时间琢磨措辞，调整描述，反复试。

第二周的某个时刻，你突然意识到：真正在起作用的是你第一天写的那四个文件——AGENTS.md、两个 SKILL.md、一个 MCP 配置。从那之后，你基本就不太想 Prompt 的事了。

工具在变，模型在进化，团队在加更多 Skills。但核心的日常循环——开 worktree、决定 plan 还是直接干、确认 diff、resume --last、把重复纠正写入规则——这个循环的形状是不变的。

而正是这个循环，把那些真正在交付的人，从那些永远在调 Prompt 的人里，分了出来。

一个真实的早晨#

假设你在维护一个五万行的后端，用 GPT-5.5：

  • 9:00 — git worktree add ../app-feat-billing feat/billing && cd ../app-feat-billing && codex
  • 9:01 — /plan "给 Stripe webhook 加 invoice.paid 的处理，用 event_id 做幂等"
  • 9:08 — Plan 看起来没问题，批准，切回执行模式
  • 9:30 — 6 个文件的 diff，/review 快速过一遍，提交
  • 9:35 — 打开第二个终端、第二个 worktree，/model gpt-5.4-mini，批量重命名一个废弃模块
  • 14:00 — codex resume --last 恢复早上会话，修掉遗漏的测试
  • 17:00 — 给明天的队列迁移探索留一个 /goal，让它活过这个周末

参考来源：Ofox.ai — Codex CLI Real-World Coding Workflow: The Setup Senior Devs Use in 2026