很多人用 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. 写清目标、上下文、约束和完成标准的提示词。
2. 复杂任务先
/plan，让 Codex 读代码和拆步骤。3. 把项目规则写进
AGENTS.md，包括测试和验收方式。4. 用
config.toml配好个人默认值和仓库规则。5. 要求 Codex 跑测试、检查格式、review diff。
6. 外部系统用 MCP，重复流程做 Skill，稳定周期任务再做 Automation。
7. 一个任务一个线程，长任务必要时 fork 或 compact。
Codex 的上限不只取决于模型，也取决于你有没有把工程上下文、项目规则和验证路径交给它。
把它当许愿池，结果就看运气。
把它当队友，就要给任务、给规则、给环境，也要让它交付可验证的结果。
参考资料
• OpenAI Developers：《Codex Best practices》
https://developers.openai.com/codex/learn/best-practices
413
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
