当Codex逐渐从“写代码工具”进化为“工程协作体”，真正的分水岭不在模型能力，而在你是否把它当成一个可以配置、复用、自动化的系统。
这份最佳实践，本质是在回答一个问题：
如何把一次性AI产出，变成持续稳定的工程生产力？
Codex并不依赖“完美Prompt”，但在复杂项目中，结构化输入决定稳定性。
一个高质量任务描述，至少包含四个维度：
@ 引用）示例（工程化版本）：
Goal: 修复登录失败问题
Context: @src/auth, 错误日志如下...
Constraints: 不使用mock，遵循现有session机制
Done when: 测试通过 + 用户登录成功
这类结构的价值在于：
把“模糊需求”转化为“可验证任务”。
Codex最大的误区之一，是让它直接动手写代码。
在复杂任务中，更优路径是：
当需求不清晰时：
先不要写代码，先问我问题，把需求问清楚
用于：
核心原则：
模糊的问题 → 明确的计划 → 再执行
如果说Prompt是一次性的，AGENTS.md就是长期记忆层。
它本质是：
Codex的“工程操作手册”
推荐包含：
一个关键实践：
当Codex犯同样的错误两次 → 写进AGENTS.md
同时注意两个原则：
Codex输出不稳定，很多时候不是模型问题，而是配置问题：
推荐配置策略：
~/.codex/config.toml.codex/config.toml安全建议：
初期保持严格权限，逐步放开，而不是一开始全开。
Codex的正确使用方式不是：
“写完我来检查”
而是：
“你写 → 你测 → 你验证 → 你复查”
可组合的验证方式包括：
/review 代码审查在团队中，可以进一步：
code_review.md 规范最终目标是：
把“人工review”变成“默认流程”。
当上下文不在代码库时，MCP成为关键基础设施。
适用场景：
使用原则：
本质上，MCP解决的是：
让Codex从“读代码”，变成“操作系统”。
当你发现自己：
说明该流程应该被“固化”。
Skill的设计原则：
典型场景：
进阶路径：
Prompt → Skill → Plugin（团队共享）
当一个流程：
就可以自动化。
典型自动化任务：
一个重要原则：
Skill定义“怎么做”，Automation定义“什么时候做”。
Codex不是聊天工具，而是状态机。
错误使用方式：
正确方式：
关键工具：
/fork：分支任务/compact：压缩上下文/resume：恢复会话核心原则：
上下文越干净，输出越稳定。
| 误区 | 本质问题 |
|---|---|
| Prompt写太多规则 | 没用AGENTS.md |
| 不提供测试方式 | 缺少验证闭环 |
| 复杂任务直接写代码 | 跳过Plan阶段 |
| 过早自动化 | 流程尚不稳定 |
| 多任务混在一个线程 | 上下文污染 |
| 给过高权限 | 缺乏安全控制 |
总结来看，Codex最佳实践可以压缩为一句话：
把AI从“工具”，变成“可配置的工程成员”。
关键转变包括：
当这些能力建立之后，Codex的角色就不再是“写代码”，而是：
参与构建整个软件工程系统。