阅读使用经验和实践建议

Codex 的稳定性不只来自模型能力，也来自工作流设计。好的上下文、清楚的规则、合适的权限、可运行的验证和可复用的 skills，都会直接影响结果质量。

OpenAI 的 best practices guide 覆盖 CLI、IDE、App 等入口。本页把核心建议整理成可执行步骤。

一条稳定工作链

flowchart LR
    Context["给上下文"] --> Plan["先规划"]
    Plan --> Rules["沉淀规则"]
    Rules --> Configure["配置行为"]
    Configure --> Validate["测试和审查"]
    Validate --> Tools["接入外部工具"]
    Tools --> Skills["沉淀 Skills"]
    Skills --> Automate["自动化重复任务"]

这条链路的重点是逐步加固，而不是一次性把所有能力打开。

先给任务上下文

一个可靠任务至少包含四件事：

• Goal：你要改变什么。
• Context：哪些文件、报错、设计、文档和任务相关。
• Constraints：哪些规则、边界、禁止事项必须遵守。
• Done when：什么算完成，怎么验证。

示例：

目标：修复设置页移动端按钮文字溢出。
上下文：问题发生在 375px 宽度，相关页面是 settings/profile。
约束：不改全局设计系统，不新增依赖。
完成标准：375px 不溢出，桌面布局不退化，types:check 通过。

上下文不一定长，但必须真实、相关、当前。

难任务先规划

复杂任务直接开改，通常会扩大范围。更稳的做法是先让 Codex 做只读计划：

请先只读分析，不要修改文件。
输出相关文件、风险点、建议修改范围、验证方式和不确定项。

Plan 阶段适合：

• 需求模糊。
• 改动跨多个模块。
• 你不确定文件位置。
• 任务需要设计取舍。
• 需要先估计风险。

计划不是仪式。它是防止 Codex 在错误方向上高效执行。

用 AGENTS.md 保存长期规则

当你反复在 prompt 里写同一类要求，就应该沉淀到 AGENTS.md。

适合写入：

• repo layout。
• 启动、测试、构建命令。
• 包管理器和禁止命令。
• 代码风格、PR 预期、验证标准。
• 敏感目录、密钥、部署和生产红线。
• 多 agent 协作时的文件边界。

维护原则：

• 短而准，比长而泛更有用。
• 只有反复发生的规则才写进去。
• 发现 Codex 第二次犯同类错误，就更新规则。
• 大型专项流程可以引用独立 markdown 或 skill。

用配置保持行为一致

config.toml 用来保存长期偏好，CLI 参数用来处理一次性覆盖。

常见配置维度：

• sandbox mode。
• approval policy。
• profiles。
• MCP servers。
• feature flags。
• model reasoning effort。

建议：

• 个人默认值放在 CODEX_HOME/config.toml。
• 项目规则放在 repo .codex/ 或 AGENTS.md。
• 临时实验使用 -c key=value。
• 常用模式沉淀为 profile。

配置不清楚时，很多质量问题会伪装成“模型不稳定”。

用验证建立反馈循环

不要只让 Codex 改完就停。让它验证、解释证据、说明未覆盖范围。

验证可以包括：

• 单元测试。
• 类型检查。
• lint。
• build。
• 截图或浏览器检查。
• diff review。
• 手动验收清单。

关键是验证必须对应任务目标。文档改动跑类型检查，UI 改动看截图，业务逻辑改动跑相关测试。

如果验证失败，Codex 应说明：

• 失败命令是什么。
• 失败是否由本次改动引入。
• 已经尝试了什么。
• 下一步需要什么环境或人工决策。

用 MCP 接入外部上下文

当上下文在 repo 外时，用 MCP，而不是反复复制粘贴。

适合接入：

• issue tracker。
• 日志和监控。
• 内部文档。
• 设计工具。
• 只读数据库查询。
• GitHub、Slack、Linear 等协作系统。

接入原则：

• 从 1-2 个高价值工具开始。
• 明确只读和写入权限。
• 避免把敏感 token 写入仓库。
• 把工具使用边界写进规则或 managed configuration。

MCP 的价值是减少上下文搬运，不是把所有系统无差别开放给 agent。

把重复流程变成 Skills

当一个 prompt 或流程反复出现，就应该变成 skill。

适合沉淀：

• PR 审查清单。
• release note 生成。
• 文档美化和质量检查。
• 日志分诊。
• migration planning。
• incident summary。

一个好 skill 应该包含：

• 清楚的触发描述。
• 输入和输出边界。
• 需要读取的文件或规则。
• 验证方式。
• 必要时的脚本或模板。

先做小而稳定的 skill，再逐步扩展，不要一开始覆盖所有边界情况。

自动化只处理稳定流程

Automations 适合已经稳定、可重复、低歧义的任务。

适合：

• 定期总结 commits。
• 扫描常见 bug 模式。
• 生成 standup summary。
• 检查 CI failures。
• 起草 release notes。

不适合：

• 需要频繁人工判断的任务。
• 权限高、影响生产的任务。
• 结果很难验证的任务。

实用原则：skill 定义方法，automation 定义时间表。

最小采用顺序

1. 先写清楚任务 prompt。
2. 对复杂任务先 plan。
3. 把重复规则写进 AGENTS.md。
4. 配置 sandbox、approval 和 profiles。
5. 每次改动都运行对应验证。
6. 接入最有价值的 MCP。
7. 把重复流程沉淀为 skills。
8. 最后再自动化稳定任务。

Codex 的最佳实践不是某一个技巧，而是这条链路能持续改进。

延长用量的 4 个杠杆

官方 Pricing 页给出 4 条延长 usage limits 的具体做法，可以直接套到日常工作里：

这 4 条不需要排队做。哪一条容易改、立即就改。

接下来去哪