夜雨聆风如果你刚开始使用 Codex，或刚接触编程智能体，这份官方建议能帮你更快取得稳定的结果。它覆盖了提示词、规划、验证、MCP、Skills 和定时任务等关键习惯，适用于 Codex CLI、IDE 扩展和 ChatGPT 桌面应用。
最重要的观念是：不要把 Codex 只当成一次性问答助手，而要把它当作一名可以持续配置、协作和改进的队友。
一个实用的路径是：先给任务足够的上下文，用 AGENTS.md 固化长期规则，再将 Codex 配置成符合你的工作方式；当需要外部信息时接入 MCP，把重复工作沉淀为 Skill，最后才把稳定流程交给自动化。
一、第一次高效使用：提供上下文与清晰提示
Codex 即使面对不完美的提示词，也能完成不少复杂工作。但提示越清楚，结果越可靠，尤其是在大型代码库或高风险任务中。
对于复杂项目，最大的提升往往不是写更长的提示词，而是让 Codex 看见正确的上下文，并明确你希望它如何完成任务。
一个好的默认提示词，通常包含四个部分：
目标：你要改什么，或要构建什么？ 上下文：哪些文件、目录、文档、示例或报错与任务有关？可用 @引用文件约束：需要遵守哪些标准、架构、安全要求或团队约定？ 完成标准：何时算完成？例如测试通过、行为发生变化，或 Bug 不再复现。
这样的结构能帮助 Codex 保持范围，减少不必要的假设，也让产出更容易审阅。
推理强度也应随任务难度调整：范围清楚、追求速度的任务可用低档；复杂改动或排障可用中档或高档；长时间、多步骤、重推理的任务再考虑更高档位。不同任务适合不同设置，值得在自己的工作流中测试。
二、困难任务，先规划再动手
当任务复杂、含糊，或你还不容易准确描述时，先要求 Codex 规划，再开始编码。
2.1 使用 Plan 模式
对大多数人来说，这是最直接有效的方式。Plan 模式会让 Codex 先收集上下文、提出澄清问题，并在实施前形成更扎实的方案。可通过 /plan 或 Shift + Tab 切换。
2.2 让 Codex 先采访你
如果你只有一个模糊想法，不确定如何表达，可以请 Codex 先提问、挑战你的假设，并在写代码之前把问题变得具体。
2.3 使用 PLANS.md 模板
更进阶的做法是，为长期或多步骤任务配置 PLANS.md 或执行计划模板，让工作过程保持一致。
三、用 AGENTS.md 让有效经验可复用
当某种提示方式已经证明有效，下一步就不该每次手动重复——把它写进 AGENTS.md。
你可以把 AGENTS.md 看作面向智能体的开放格式 README。它会自动进入上下文，适合记录你和团队希望 Codex 在仓库中遵守的工作方式。
一份好的 AGENTS.md 通常包括：
仓库结构和重要目录； 项目的运行方法； 构建、测试和 Lint 命令； 工程约定与 PR 预期； 约束和禁止事项； 完成标准与验证方式。
CLI 中的 /init 可以快速生成基础版 AGENTS.md，但它只是起点，之后应按团队真实的构建、测试、审查与发布方式来调整。
AGENTS.md 可以分层：个人默认规则放在 ~/.codex，仓库级规则放在项目根目录，更具体的子目录还可以有局部规则；离当前目录越近的规则优先级越高。
保持它短小、准确、实用。一份简洁而真实的文件，比堆满模糊要求的长文档更有价值。每当 Codex 重复犯同一种错误，就请它复盘，再把真正有效的新规则写进去；如果文件过长，则将专题规则拆到独立文档中引用。
四、配置 Codex，让体验保持一致
配置是让 Codex 跨会话、跨使用界面保持一致的重要方式。你可以设置模型选择、推理强度、沙盒模式、审批策略、配置档案和 MCP 等默认项。
一个常用的分层方式是：
个人默认配置放在 ~/.codex/config.toml；仓库专属配置放在 .codex/config.toml；命令行覆盖只用于一次性场景。
如果你是编程智能体的新用户，建议从默认权限开始：默认保持严格，只在可信仓库或明确需要的工作流中逐步放宽。许多质量问题其实是环境问题，例如工作目录不对、缺少写入权限、模型默认值不合适，或工具与连接器没有配置好。
五、用测试与审查提升可靠性
不要只让 Codex “改完代码”就结束。需要时，要求它补充测试、运行相关检查、确认最终行为，并在你接受前自行审查一遍。
但 Codex 必须知道什么叫“好”，这些标准可以写在提示词中，也可以固化在 AGENTS.md 中。常见的验证环节包括：
为改动新增或更新测试； 运行正确的测试集； 检查 Lint、格式化或类型检查； 确认最终行为符合原始需求； 审查 Diff，寻找 Bug、回归或高风险模式。
在 ChatGPT 桌面应用中，可打开 Diff 面板直接审阅本地改动，并对具体行提供反馈。/review 命令也可用于按基线分支、未提交改动、某个提交或自定义规则进行审查。
Codex 不应只生成代码；有了正确指令，它也能参与测试、检查和审查。
六、用 MCP 获取仓库外的上下文
当 Codex 需要的信息不在仓库内时，使用 MCP。它能把 Codex 连接到已有的工具和系统中，减少反复复制粘贴实时信息的工作。
MCP（Model Context Protocol，模型上下文协议）是一项用于连接外部工具与系统的开放标准。以下情况尤其适合使用：
所需上下文存在于仓库外； 数据经常变化； 希望 Codex 直接调用工具，而不是依赖粘贴说明； 需要让不同用户或项目复用同一集成。
不过，工具应当为真实工作流服务。不要一开始就接入所有工具；先选一两个能明显减少重复劳动的连接器，验证价值后再逐步扩展。
七、把重复工作沉淀为 Skills
当某项工作开始重复出现，就不要继续依赖冗长提示词或反复沟通。把它封装成一个 Skill：用 SKILL.md、必要的上下文和辅助逻辑，让 Codex 稳定地执行同一种工作方式。
每个 Skill 应聚焦一件事。可以从 2～3 个具体用例开始，明确输入和输出，并在描述中说清“它做什么、何时使用”，同时写入用户真正会说出的触发语句。
无需一开始覆盖所有边界情况。先选择一个有代表性的任务，把第一版跑通，再不断改进。只有在确实能提升可靠性时，才加入脚本或额外资源。
一个简单的判断标准是：如果你不断复用同一段提示词，或不断纠正同一种流程，这件事大概率应该成为一个 Skill。
八、稳定之后，再用定时任务自动化
当一条工作流已经稳定，就可以让 Codex 在后台定期运行。定时任务适合选择项目、提示词、执行频率和运行环境，并可调用 Skills。
常见场景包括：汇总最近提交、扫描潜在 Bug、起草发布说明、检查 CI 失败、生成站会摘要，以及按固定节奏进行分析。
一条有用的原则是：Skill 定义“方法”，定时任务定义“时间表”。如果一项工作仍需要大量人工引导，应先把它打磨成可预测的 Skill，再安排自动执行。定时任务也适合用于反思与维护：复盘近期对话、总结反复出现的摩擦，并持续优化提示词、规则与工作流。
九、管理长期对话，让上下文保持清晰
对话会累积上下文、决策和操作记录，因此管理方式会直接影响结果质量。
建议一项连贯的工作使用一个对话：同一问题中的工作留在同一对话，能保留完整的推理脉络；只有任务真正分叉时再 Fork。
对 CLI 用户，以下命令尤其有帮助：
/resume ：继续之前保存的对话/fork：在保留原始对话记录的同时，创建一个新的对话分支/compact：当对话变长时，将早期上下文压缩为摘要；Codex 也会自动压缩对话/agent：使用并行智能体时，在当前活动的智能体对话之间切换/status：查看当前会话状态
同时，可以把有边界的探索、测试或排查工作交给子智能体，让主智能体保持聚焦于核心问题。
十、常见误区
最后，官方特别提醒避免以下做法：
把长期规则全塞进提示词，而不写入 AGENTS.md或 Skill；不告诉智能体如何运行构建与测试，导致它无法验证自己的工作； 面对复杂、多步骤任务却跳过规划； 尚未理解工作流就给 Codex 整台电脑的完全权限； 不使用 Git worktree，却在同一批线上文件上同时运行任务； 工作流尚未手动跑稳定，就急着安排定时任务； 逐步盯着智能体的每个动作，而不是在它执行时并行处理自己的工作； 用一个对话承载整个项目，而非一个连贯成果，导致上下文膨胀、质量下降。
结语
Codex 的价值不只在于“帮你写一次代码”，而在于持续学习你的上下文、规则和工作方式。先从清晰提示、可靠验证和一份简洁的 AGENTS.md 开始；当工作逐渐稳定，再引入 MCP、Skills 与自动化。这样，Codex 才会从工具真正变成队友。
原文来源（OpenAI 官方）：https://learn.chatgpt.com/guides/best-practices