OpenAI Codex 官方发布了一篇最佳实践的文章，很好很实用，没有什么花里胡哨的东西，都是汇总的常见的流程和经验。使用 CodeX 或任何 AI 编程 Agents 都可以遵循这套流程。
下面是翻译👇
如果你刚开始使用 Codex 或各类 AI Agent，这份指南能帮助你更快获取到更好的结果。它涵盖了 Codex 在 CLI、IDE 插件和 Codex App 中所有更高效的核心用法，包含 Prompt 写法、Plan 模式使用、MCP、Skill 与自动化各个方面。
OpenAI 主张：不要把 CodeX 当作一次性助手，而是要把它当作自己的队友，随着时间的推移进行配置和改进。
总结下来的思路是：
- 先给到正确的任务上下文
- 用
AGENTS.md做长期指导，把 Codex 配置成贴合你的工作流 - 用 MCP 连接外部系统
- 把重复性工作抽成技能
- 把稳定流程做成自动化
首次上手的关键：上下文与提示词
Codex 的基础能力已经强到即便提示词不够完美，也能产出有用结果。你通常只需极少的设置就能让它处理一个难题。清晰的提示词并非获取价值的必要条件，但它确实能提高结果的可靠性，尤其是在大型代码库或高风险任务中。
如果你在一个大型或复杂仓库里工作，最大幅度的提升在于：给出正确的任务上下文，以及清晰的任务结构。
一段常用的优秀的提示应该包含四个部分：
- 目标：你想要改变什么或构建什么？
- 上下文： 哪些文件、文件夹、文档、示例或错误与此任务相关？你可以使用 @ 符号提及特定文件作为上下文。
- 约束：必须遵守的标准、架构规则、安全要求或约定。
- 完成条件：完成的判定标准，例如测试通过、Bug 不再复现、或某个行为发生变化。
这种结构能让任务更聚焦、减少臆测，也更便于审查。
除此之外，可以根据任务难度选择推理强度，并测试哪种级别最适合你的工作流程。（最强推理难度并不一定会达到最理想的结果）
- 低：快速、范围清晰的任务
- 中或高：复杂改动或调试
- 极高：长时间、需要主动思考和推理的任务
为了更快地提供上下文，尝试在 Codex 应用内使用语音功能来口述您希望执行的操作。
为困难的任务做好计划
当任务复杂、模糊或难以描述时，在开始编码之前请先进行规划。
常见做法：
使用 Plan 模式：对于大多数用户来说，这是最简单有效的选择。Plan 模式允许 Codex 先收集上下文、提出问题，并在实施前制定更完善的计划。通过 /plan 或 Shift + Tab 切换。
让 Codex 对你进行提问：如果你对想要实现的功能有一个大致的想法，但不确定如何准确描述，可以先请 Codex 向你提问。告诉它挑战你的假设，并在编写代码之前将模糊的想法转化为具体的概念。
使用 PLANS.md 模板：对于更高级的工作流，可以在 PLANS.md 中定义执行计划模板，从而处理耗时更长或包含复杂步骤的任务。
使用 AGENTS.md 进行重复指导
当某个 Prompt 奏效后，不要反复手动输入，而是把它写进 AGENTS.md 中。
AGENTS.md 相当于面向 Agents 的 README，它会自动加载进上下文，用来定义 Codex 在仓库中的工作方式。
一个实用的 AGENTS.md 通常包含：
- 仓库结构与关键目录
- 如何运行项目
- 构建、测试与 lint 命令
- 工程规范与 PR 期望
- 约束与禁止模式
- 完成标准与验证步骤
CLI 命令 /init 会在当前目录生成基础版 AGENTS.md，你可以根据团队实际构建、测试、审查和发布代码的方式对内容进行编辑。
AGENTS.md 可以在多层级目录中同时存在。你可以将 ~/.codex/AGENTS.md 作为个人默认设置，仓库根目录的用于仓库共享标准，子目录用于更具体的设置本地规则。
保持文件简洁。一份简短准确的 AGENTS.md 比一份充斥着模糊规则的长文件更有用。先从基础规则入手，在发现重复出现的错误后才添加新规则。随着项目推移，如果文件变得过大，也请保持主文件的精简。将细节和实现拆到单独的 Markdown 文档里。
如果 Codex 犯了两次同样的错误，你可以要求它进行回顾和更新
AGENTS.md。
配置 Codex 保持一致性
配置可以确保 Codex 在不同会话和界面上行为一致。常见配置项包括：
- 默认模型
- 推理强度
- 沙箱模式
- 审批策略
- MCP
一个实用的配置为：
~/.codex/config.toml：个人默认配置.codex/config.toml：仓库级配置- 命令行覆盖：仅用于临时场景
config.toml 定义持久性的偏好，例如 MCP 服务器、配置文件、多代理设置与实验特性。
Codex 具备操作级沙箱，包含两项关键控制：
- 审批模式：决定何时需要用户确认命令
- 沙箱模式：决定目录访问与文件权限
如果你是 AI Agent 的新手，请先保持权限偏紧，在明确需要后，仅对受信任的存储库或特定工作流程放宽权限。
尽早针对您的实际环境配置 Codex。许多质量问题实际上都是配置问题，例如工作目录错误、缺少写入权限、模型默认值错误或缺少工具和连接器。
通过测试和 code review 提升可靠性
使用 AI Agent 不要停留在生成代码这一步，还要要求它在需要时创建测试，运行检查，确认结果，并在接受更改之前审查更改内容。Codex 可以帮你完成这个循环，但前提是它知道“好”的标准是什么。这个标准可以来自提示词或 AGENTS.md。
常见验证步骤包括：
- 编写或更新测试
- 执行相关测试套件
- 检查 lint、格式化或类型检查
- 确认行为符合需求
- 评审 diff，排查回归或风险模式
斜杠命令 /review 支持多种评审模式：
- 针对 base 分支进行 PR 式审查
- review 未提交的变更
- review 指定提交
- 自定义 review 指令
如果你和你的团队有一个 code_review.md 文件，并在 AGENTS.md 中引用，Codex 可按该指南进行评审。对于希望在所有代码库和贡献者之间保持审查行为一致性的团队来说，这是一个非常有效的模式。
Codex 不应该仅仅生成代码。通过正确的指导，它还可以帮助测试、检查和审查代码。
使用 GitHub Cloud 可以设置 Codex 对 PR 进行代码审查。在 OpenAI 内部，Codex 会审查 100% 的 PR。你可以启用自动审查，也可以让 Codex 在您 @Codex 时进行响应式审查。
使用 MCP 了解外部环境
当所需的上下文信息位于代码库之外时，使用 MCP。它允许 Codex 连接到你已使用的工具和系统，这样您就无需不断地将实时信息复制粘贴到 Prompt 中。
使用 MCP 的场景：
- 所需的上下文信息存在于代码库之外
- 数据变化频繁
- 你希望 Codex 使用工具而不是依赖粘贴的指令
- 你需要跨用户或项目的可重复集成
Codex 同时支持 STDIO 和 Streamable HTTP 服务器以及 OAuth。
在 Codex 应用中，前往“设置”→“MCP 服务器”即可查看自定义服务器和推荐服务器。Codex 通常可以帮助你安装所需的服务器，你也可以在命令行界面 (CLI) 中使用 codex mcp add 命令配置自定义服务器。
将重复工作抽成技能
一旦工作流程变得可重复，就不要再依赖冗长的提示或反复的沟通。使用技能（Skill）将指令、上下文和逻辑打包到 SKILL.md 文件中。技能可在命令行界面 (CLI)、集成开发环境 (IDE) 扩展和 Codex 应用程序中使用。
每项技能都应限定于一项工作。首先列出 2 到 3 个具体的用例，明确定义输入和输出，并撰写描述，说明该技能的功能和适用场景。同时，也要包含用户实际会使用的触发短语。
不要试图一开始就考虑到所有极端情况。先从一个具有代表性的任务入手，确保它运行良好，然后将该工作流程培养成一项技能，并在此基础上不断改进。
一个很好的经验法则是：如果你不断重复使用相同的提示词或纠正相同的工作流程时，那么它很可能会成为一项技能。
技能适合的场景包括：
- 日志分类
- 起草写发布说明
- 按检查表进行 PR 评审
- 迁移规划
- 监控数据汇总
- 调试流程
$skill-creator 用于创建新技能，$skill-installer 用于本地安装。
技能存放位置：
- 个人技能：
$HOME/.agents/skills - 共享技能：仓库内
.agents/skills
用自动化处理重复性工作
对你来说当某个任务开始重复时，可以在 Codex 的 Automations 页创建自动化。你可以选择它运行的项目、执行时使用的 prompt（可以调用技能）以及执行节奏。也可以选择它在独立的 git worktree 还是本地环境运行。
适合做成自动化的任务包括：
- 总结最近提交
- 扫描潜在 bug
- 起草发布说明
- 检查 CI 故障
- 生成会议摘要
- 定期运行可重复的分析流程
一个有用的原则是：技能定义方法，自动化定义节奏。如果工作流程仍然需要大量人工干预，先做成技能，稳定后再自动化会更好。
利用自动化进行反思和维护，而不仅仅是执行。回顾最近的会话，总结反复出现的问题，并随着时间的推移改进提示、说明或工作流程设置。
用会话控制来组织长期工作
Codex 会话不仅是聊天记录，它们是随着时间推移积累上下文、决策和行动的工作线程，妥善管理它们对质量有着重大影响。
Codex 应用的 UI 让线程管理变得非常简单，因为你可以锁定线程并创建工作树。如果您使用的是 CLI，以下斜杠命令尤其有用：
/experimental：切换实验特性并写入config.toml/resume：恢复已保存的对话/fork：在保留原线程的情况下创建新线程/compact：当线程很长时做摘要（Codex 也会自动压缩）/agent：在多代理之间切换当前代理线程/theme：选择语法高亮主题/apps：在 Codex 内直接使用 ChatGPT apps/status：查看当前会话状态
每个连贯的工作单元都应保持一个线程。如果工作仍然是同一个问题的一部分，那么保持在同一个线程中通常更好，因为这样可以保留推理过程。只有当工作真正出现分支时才进行分叉。
用 Codex 的 multi-agent 工作流把边界清晰的任务从主线程拆出去。主代理专注核心问题，子代理负责探索、测试或分诊等工作。
常见错误
刚开始使用 Codex 时容易踩的坑：
- 把持久规则塞进提示里，而不是移到
AGENTS.md或 skill - 没让代理看到它该怎么运行构建和测试命令
- 多步骤或复杂任务不做规划
- 还没理解流程就给 Codex 全部权限
- 在同一文件上并行运行多个线程、但不使用 git worktree
- 流程还不稳定就做成自动化
- 把 Codex 当成需要逐步盯着执行的工具，而不是与你并行工作的队友
- 一个项目只用一个线程，而不是一个任务一个线程；这会让上下文膨胀、质量下滑
