Codex 使用最佳实践：把它当成工程队友，而不是代码生成器
很多人刚开始用 Codex，习惯把它当成更强大的代码聊天机器人：描述需求、等待生成、跑不通再追问。这种方式能跑通小任务，但在大项目里容易出现上下文缺失、修改范围失控、反复返工的问题。
更好的做法是，把 Codex 嵌入工程工作流：给它完整上下文、让它先规划再执行、最后沉淀经验。这样 Codex 才能像熟悉项目的工程队友一样稳定输出，而不是每次都从零开始的临时助手。
1. Prompt 不用花哨，但上下文要完整
Codex 不怕 prompt 写得朴素，最怕上下文缺失。一个稳定的任务描述通常包含四部分：目标、上下文、约束、完成标准。
不要只说“帮我修一下登录问题”，而应该写得更具体：
修复用户登录后偶尔跳回首页的问题。登录逻辑在 src/auth，路由守卫在 src/router。不要改数据库结构，不要重写登录流程。完成后补充测试，并确认登录后能回到原访问页面。
完整的信息能减少模型的猜测，让修改更可控。
2. 复杂任务先 Plan，再动手
遇到跨模块修改、架构调整或需求不清晰的任务时，建议先让 Codex 进入计划阶段，而不是直接写代码。可以这样提示：
先不要写代码。请先阅读相关文件，给出你的理解、修改计划、风险点和验证方式，等我确认后再实现。
这一步能提前暴露潜在问题，避免 Codex 大范围改动无关文件。
3. 把重复要求写进 AGENTS.md
如果你经常需要提醒 Codex“不要改无关文件”“改完要跑测试”“用 pnpm 不要用 npm”，这些内容就应该沉淀到 AGENTS.md。
AGENTS.md 相当于给 AI 看的项目说明书，可以记录命名规范、业务规则、依赖关系、已知问题等长期上下文，减少每次重新解释的成本。
4. 配置决定稳定性，也决定成本
Codex 的表现与开发环境密切相关。启动脚本、环境变量、测试命令、网络权限等信息越清晰，它越不容易卡在构建或依赖问题上。同时，简单任务可用轻量模型，复杂工程任务再切换到更强的模型，能在效果和成本之间取得平衡。
5. 不要只让 Codex 写代码，也要让它验证代码
让 Codex 完成修改后，主动要求它运行测试、检查 diff、确认行为是否符合预期。这样能把“生成代码”变成“交付可验证结果”，降低人工复核的压力。
6. 高频上下文用 MCP，重复流程做成 Skill
对于跨会话需要保留的信息，建议写入外部知识库，而不是只依赖聊天记录。常用规范和流程可以封装成 Skill，减少重复输入，让 Codex 更高效地复用经验。
7. 长任务要管理 session
大任务容易超过单次上下文限制，建议拆分成阶段性目标，配合任务队列推进。每次完成一个阶段后再进入下一阶段，避免上下文丢失或方向偏移。
把 Codex 当成工程队友，核心在于给它结构化的上下文、清晰的验证标准，以及可沉淀的长期记忆。这样它才能真正参与项目迭代，而不是每次都从头开始。