很多人用 Codex 的方式，还是一句话丢过去：“帮我改一下这个 bug。”

这当然能用，但很浪费。OpenAI 在 Codex 最佳实践里给出的核心判断很明确：Codex 更适合被当成一个会随项目逐渐配置和改进的队友，而不要把它当成一次性问答助手。

这句话背后的意思是：你不能只给需求，还要给上下文、规则、环境和验收标准。

1. 提示词最少要交代四件事

OpenAI 建议，一个默认可用的 Codex 任务提示，至少包括四块：

• • 目标：你要改什么、做什么

• • 上下文：哪些文件、目录、文档、报错和例子相关

• • 约束：要遵守哪些架构、风格、安全或兼容约束

• • 完成标准：什么状态算完成，比如测试通过、行为改变、bug 不再复现

这四项很朴素，但能减少大量误判。

差的提示是：

这个页面有问题，修一下。

更好的提示是：

修复订单详情页在移动端底部按钮遮挡内容的问题。相关文件是 OrderDetail.tsx 和 order.css。不要改接口，不要影响桌面端布局。完成标准：移动端 375px 和 414px 宽度下按钮不遮挡正文，现有单测通过。

使用 Codex 时，如果你不给边界，它只能猜。

2. 复杂任务先计划，不要急着写代码

OpenAI 的建议是：复杂、模糊、难描述的任务，先让 Codex 计划，再实现。

计划阶段至少能做三件事：

• • 先读代码，确认真实入口

• • 把任务拆成可检查的小步骤

• • 提前暴露风险和需要确认的地方

Codex 里可以用 Plan mode。官方文档写到，Plan mode 会让 Codex 先收集上下文、提问、形成更强的计划，再进入实现；入口是 /plan 或 Shift + Tab。

如果你自己也没想清楚，甚至可以反过来让 Codex 采访你：让它先追问需求、挑战假设，把模糊想法压成可执行任务。

3. AGENTS.md 是项目说明书，不是装饰文件

一旦某套提示词反复用，就不要每次手写。OpenAI 建议把这类长期规则放进 AGENTS.md。

官方对它的定位很具体：AGENTS.md 是面向 agent 的开放格式 README，会自动进入上下文，适合写项目里希望 Codex 长期遵守的工作方式。

一个有用的 AGENTS.md 通常包括：

• • 项目目录结构和关键目录

• • 如何启动项目

• • build、test、lint 命令

• • 工程约定和 PR 要求

• • 禁止事项和边界

• • 什么叫完成，如何验证

CLI 里可以用 /init 生成一个初始 AGENTS.md，但官方也提醒：生成后应该按团队真实的构建、测试、评审和发布方式修改。

还有一个容易忽略的细节：AGENTS.md 可以分层。全局文件可以放在 ~/.codex，仓库根目录可以放共享规则，子目录也可以放更具体的规则；距离当前目录更近的规则优先。短、准、可执行，比长篇原则更有用。

4. 很多“AI 不靠谱”，其实是环境没配好

OpenAI 把配置单独列成一节，是有原因的。

Codex 的一致性，依赖项目环境：

• • 模型选择

• • reasoning effort

• • sandbox

• • approval policy

• • profiles

• • MCP 配置

以上这些都会影响它能做什么、做到哪一步、什么时候需要你确认。

官方建议的配置分层是：

• • 个人默认值放在 ~/.codex/config.toml

• • 仓库特定行为放在 .codex/config.toml

• • CLI 命令行覆盖只用于一次性场景

文档还特别提到，很多质量问题本质是 setup 问题：工作目录不对、缺写权限、模型默认值不对、缺工具或连接器。

这点很真实。你让 Codex “修好并验证”，但项目依赖装不起来、测试命令没告诉它、权限又不允许写文件，那它最多只能给你建议。

5. 让 Codex 跑完验证闭环

OpenAI 不建议仅仅使用“让 Codex 改代码”。更好的闭环是：

• • 必要时写测试或更新测试

• • 运行相关测试套件

• • 检查 lint、format、type check

• • 确认最终行为符合请求

• • review diff，找 bug、回归和风险模式

这也是 AGENTS.md 的价值所在：把“哪些检查必须跑”写进去，Codex 才知道什么叫完成。

Codex 还有 /review 命令，可以按 base branch、未提交改动、某个 commit 或自定义规则做 review。对团队来说，把 code_review.md 挂到 AGENTS.md 里，也能让评审标准更稳定。

一句话：让 Codex 解释、验证、审查自己的改动。

6. MCP、Skills、Automations 分别解决三类问题

这三个概念容易混在一起，但边界其实清楚。

MCP 解决“外部上下文”。

当 Codex 需要的信息不在仓库里，或者数据经常变化，就适合用 MCP。官方把 Model Context Protocol 定义为连接 Codex 与外部工具、系统的开放标准。Codex 支持 STDIO 和 Streamable HTTP server，并支持 OAuth。

Skills 解决“重复方法”。

当你反复使用同一段提示词、同一套流程、同一类检查，就应该沉淀成 Skill。Skill 用 SKILL.md 包装说明、上下文和必要逻辑，可在 CLI、IDE extension 和 Codex app 中使用。官方建议一个 Skill 只解决一个明确工作，先从 2 到 3 个具体用例开始。

Automations 解决“固定节奏”。

当一个流程已经稳定，可以让 Codex 在后台按计划跑。官方文档写到，Codex app 的 Automations 可以选择项目、prompt、运行频率和执行环境，也可以选择在独立 git worktree 或本地环境里运行。

一个简单判断是：Skills 定义方法，Automations 定义时间。

如果一个任务还需要你频繁纠偏，先别自动化。先把它做成稳定 Skill，再考虑定时跑。

7. 长任务要按任务开线程，不要按项目开线程

Codex 的会话是会累积上下文、决策和动作的工作线程。

官方建议是：一个清晰任务一个线程。不要把一个项目长期混在一个线程里，否则上下文会越来越膨胀，质量会下降。

CLI 里几个命令值得记：

• • /resume：恢复保存的会话

• • /fork：在保留原始 transcript 的前提下开新线程

• • /compact：长线程压缩上下文；Codex 也会自动 compact

• • /status：查看当前会话状态

如果任务分叉了，用 fork。任务还在同一个问题里，就留在原线程，保留推理轨迹。

最后给一个实用清单

下次开一个新任务，可以直接按这个顺序走：

1. 1. 写清目标、上下文、约束和完成标准的提示词。

2. 2. 复杂任务先 /plan，让 Codex 读代码和拆步骤。

3. 3. 把项目规则写进 AGENTS.md，包括测试和验收方式。

4. 4. 用 config.toml 配好个人默认值和仓库规则。

5. 5. 要求 Codex 跑测试、检查格式、review diff。

6. 6. 外部系统用 MCP，重复流程做 Skill，稳定周期任务再做 Automation。

7. 7. 一个任务一个线程，长任务必要时 fork 或 compact。

Codex 的上限不只取决于模型，也取决于你有没有把工程上下文、项目规则和验证路径交给它。

把它当许愿池，结果就看运气。

把它当队友，就要给任务、给规则、给环境，也要让它交付可验证的结果。

参考资料

• • OpenAI Developers：《Codex Best practices》
  https://developers.openai.com/codex/learn/best-practices