如果只记住一句话，可以记住：

Codex 的效率，不来自“装得更多”或“Prompt 写得更长”，而来自一个边界清晰、流程稳定、工具恰当、结果可验证的交付闭环。

一、Codex 的核心，不是 Prompt，而是工程闭环

整套方法论可以浓缩成一条链路：

项目边界 → 长期规则 → 任务契约 → 计划拆解 → 能力选择 → 隔离并行 → 执行 → 验证 → 证据交付 → 流程沉淀

对应到 Codex 中，就是：

Project → AGENTS.md → Task → Plan → Skill / Plugin / MCP → Subagents / Worktree → Execute → Verify → Evidence → Reuse

这比“写一个很厉害的 Prompt”重要得多。

真正高效地使用 Codex，本质上是在管理三件事：

也就是说，Codex 的工程化使用不是：

Prompt  ↓Answer

而是：

Context  ↓Rules  ↓Task Contract  ↓Plan  ↓Tools / Agents  ↓Execution  ↓Verification  ↓Evidence

二、第一原则：先缩小项目边界，再提升模型能力

很多人使用 Codex 的第一步是直接输入：

“帮我修改一下这个项目。”

这通常不是最优解。

更好的方式，是先给 Codex 一个清晰、独立、边界明确的工作空间，例如：

my-project/├── AGENTS.md├── README.md├── src/├── tests/├── docs/├── references/└── assets/

然后再开始任务。

为什么？

因为 Agent 面对一个项目时，首先要解决的并不是：

“代码应该怎么写？”

而是：

“哪些文件、规则和上下文真正属于这次任务？”

项目边界越清晰，Codex 的搜索空间越小，无关上下文越少，误修改和错误推断的概率也越低。

OpenAI 官方权限与沙箱设计同样强调项目边界的重要性：默认应尽量限制在当前项目范围内；如果需要并行开发或隔离修改，更适合使用独立项目或 Worktree。 (OpenAI Developers)

因此，使用 Codex 的第一原则可以总结为：

先减少搜索空间，再增加模型能力。

三、把 AGENTS.md 当成“项目级操作系统”

很多人会把项目规则一遍又一遍写进 Prompt。

更合理的做法是把信息拆成两类：

• 长期稳定、每次都必须遵守的规则 → AGENTS.md
• 本次任务特有的目标和限制 → Task Prompt

Codex 会读取项目中的 AGENTS.md，并可以通过不同层级的规则形成覆盖关系。 (OpenAI Developers)

一个高质量的 AGENTS.md，不应该是一篇冗长的项目介绍，而应该是一份高度可执行的 Project Policy。

最值得写进去的内容包括：

OpenAI 官方同样建议保持 AGENTS.md 精简，把它用于记录每次都需要遵守的仓库级规则，例如构建方式、测试要求、代码规范和 Review 约束。 (OpenAI Developers)

因此：

AGENTS.md 不是“大 Prompt”，而是 Codex 的项目级 Policy。

四、从“写 Prompt”升级为“定义任务契约”

这是整套方法论中最关键的一步。

一个高质量的 Codex 任务，不应该只是一个模糊需求，而应该尽量写成一个明确的 Task Contract：

GoalContextConstraintsAcceptance Criteria

四个字段分别回答：

例如，不要只写：

优化登录功能。

而应该写成：

Goal修复用户 Token 过期后页面不断触发 401 重试的问题。Context登录逻辑：src/auth/HTTP Client：src/api/client.tsConstraints1. 不修改后端 API。2. 不修改 Token 格式。3. 不新增第三方依赖。Acceptance Criteria1. Token 过期后最多只执行一次 refresh。2. refresh 失败后跳转 /login。3. 并发 401 不重复触发 refresh。4. 原有测试全部通过。5. 增加并发 401 场景测试。

当目标、边界和验收标准都明确以后，Codex 的决策空间会显著缩小。

所以：

好的 Prompt，不是写得足够长，而是让决策空间足够小。

五、复杂任务先 Plan，不要直接进入修改

对于简单任务，直接执行通常没有问题。

但只要任务涉及跨文件修改、架构调整、数据库迁移、新功能、多步骤排查或较高风险，就应该先进入 Plan。

OpenAI 官方 Best Practices 同样建议，对于复杂、多步骤或存在歧义的问题，先通过 Plan mode 收集上下文、形成实施方案，再进入执行阶段。 (OpenAI Developers)

可以使用一个简单判断：

正确流程不应该只是：

需求 ↓写代码

而应该是：

需求 ↓Inspect ↓Plan ↓Review Plan ↓Execute ↓Verify

一个非常实用的指令模板是：

先不要修改任何文件。先完成：1. 定位相关代码；2. 分析根因；3. 给出修改方案；4. 列出预计修改文件；5. 列出潜在风险；6. 给出测试与验收方案。Plan 完成后，再进入实施阶段。

这样可以显著减少一种典型浪费：

代码写到一半，才发现一开始的方向就是错的。

六、分清 AGENTS.md、Skill、Plugin、MCP、Subagent 和 Worktree

这是高级使用 Codex 时非常重要的一层认知。

这些能力看起来都在“增强 Agent”，但它们实际上解决的是完全不同的问题。

OpenAI 官方的能力分层也基本遵循这一逻辑：AGENTS.md 提供持久项目指导，Skills 封装可复用流程，MCP 连接外部工具和上下文，Subagents 用于任务委派与并行。 (OpenAI Developers)

因此，不要问：

“能不能把所有能力都装上？”

更重要的问题是：

当前任务到底缺哪一层能力？

七、重复两三次的 Prompt，就应该考虑 Skill 化

如果某个流程经常重复，例如：

读取模型 benchmark CSV→ 数据清洗→ 计算指标→ 比较模型→ 筛选失败样本→ 错误分类→ 输出评估报告

第一次可以直接写 Prompt。

第二次可以优化 Prompt。

但如果第三次、第四次还在重复同样的操作，就应该考虑将其沉淀成 Skill：

model-evaluation/└── SKILL.md

以后只需要告诉 Codex：

对这批结果执行模型评估 Skill。

Skill 的价值，本质上就是把重复工作从“临时 Prompt”升级为“可复用工作流”。 (OpenAI Developers)

可以建立一个非常实用的规则：

重复两三次的 Prompt，就是 Skill 的候选人。

同时要区分两个概念：

Skill=如何做

Scheduled Task=什么时候做

也就是说：

Skill 负责流程，Schedule 负责时间。

一个稳定流程应该先被手工跑通、Skill 化，再考虑加入定时执行。

因此：

Skill + Schedule=稳定自动化

八、并行的本质不是“多开 Agent”，而是构建任务 DAG

复杂任务天然适合被拆成一个有依赖关系的任务图。

例如：

                     ┌─ 前端分析                     │需求 ─→ 架构分析 ────┼─ API 分析                     │                     └─ 测试分析                          ↓                       汇总方案                          ↓                       实施修改                          ↓                ┌─────────┼─────────┐                ↓         ↓         ↓              Test      Review   Security                └─────────┼─────────┘                          ↓                        交付

而不是让一个 Agent 从头串行做到尾：

查代码 ↓写代码 ↓测试 ↓Review ↓安全检查

OpenAI 官方的 Subagent 能力正是为了支持这类任务拆解：主 Agent 可以把相互独立的探索、分析、测试或 Review 工作委派出去，再统一收敛结果。 (OpenAI Developers)

例如：

Agent A：定位 Bug 根因Agent B：检查现有测试覆盖Agent C：分析 API 调用链Agent D：检查潜在安全风险

然后由主 Agent：

综合 A / B / C / D      ↓形成统一方案      ↓实施修改

Multi-Agent 的价值不是：

Agent 越多，速度越快。

而是：

只有不存在强依赖关系的任务，才值得并行。

九、Subagent 解决逻辑并行，Worktree 解决代码隔离

只并行 Agent 还不够。

如果两个 Agent 同时修改同一工作目录：

Agent A 修改 src/api.tsAgent B 同时修改 src/api.ts

就很容易产生文件污染、覆盖和冲突。

Worktree 解决的正是这个问题。

官方说明，Git Worktree 可以让同一仓库中的多个 Codex 会话在不同 checkout 中独立工作，从而实现并行修改而互不干扰。 (OpenAI Developers)

因此可以把两者理解为：

Subagent=逻辑并行

Worktree=文件系统隔离

组合起来：

             Main Agent                 │       ┌─────────┼─────────┐       ↓         ↓         ↓    Agent A   Agent B   Agent C       │         │         │ Worktree A Worktree B Worktree C

这才是一套真正可扩展的并行开发方式。

十、Plugin 不应“越多越好”，而应按 Workflow 组合

Plugin Marketplace 很容易让人产生一种错觉：

能力装得越多，Codex 就越强。

实际上，过多插件意味着更大的上下文、更复杂的权限面，以及更多不必要的工具选择。

更合理的流程应该是：

任务 ↓需要哪些能力？ ↓只加载对应 Plugin / Skill

例如：

Web 开发

Build Web Apps+GitHub+Browser / Playwright+Vercel+Codex Security

UI / 产品设计

Figma+Product Design+ImageGen+Build Web Apps

数据分析

Data Analytics+Google Drive+相关数据库 / SaaS

内容与市场

Notion+Google Drive+Semrush+Slack

OpenAI 对 Plugin 的定位，也是将 Skills、Connectors 等能力打包成可复用能力，而不是鼓励无差别堆叠。 (OpenAI Developers)

所以：

按 Workflow 装 Plugin，而不是按排行榜装 Plugin。

十一、MCP 的重点不是“能不能连”，而是“最小权限”

MCP 可以把 Codex 与很多外部系统连接起来，例如：

GitHubFigmaBrowserDatabaseNotion内部 API……

官方将 MCP 定义为连接模型与外部工具、数据和上下文的一种协议。 (OpenAI Developers)

但真正工程化的重点并不是：

“Codex 能不能访问这个系统？”

而是：

“Codex 为完成当前任务，最少需要什么权限？”

核心原则只有两个：

Need-to-know+Least privilege

例如：

如果只是分析数据库，就尽量只给：

SELECT

不要默认给：

INSERTUPDATEDELETEDROP

如果只是查看 GitHub Issue，就没必要直接开放 Merge 权限。

如果只是读取线上日志，也没必要直接提供服务器 root shell。

OpenAI 的 Agent 权限与审批设计同样强调，应优先授予足以完成任务的最窄权限范围。 (OpenAI Developers)

因此：

Agent 能力越强，权限设计就越重要。

十二、真正决定 Codex 可靠性的，是 Verification

很多人的工作流到这里就结束了：

写完代码 ↓Codex：Done

但“Agent 说完成了”并不等于“任务真的完成了”。

真正完整的流程应该是：

Implement ↓Build ↓Lint ↓Unit Test ↓Integration Test ↓Browser Test ↓Security ↓Diff Review ↓Evidence

这也是“代码、浏览器、数据验证 → 带证据交付”的真正含义。

任务完成的判断标准，不应该是：

Codex 说完成了。

而应该是：

Codex 能拿出证据证明任务已经完成。

因此，最终交付报告最好固定包含：

ChangesVerificationEvidenceRisksRemaining Issues

例如：

完成。Changes- 修改 src/auth/token.ts- 修改 src/api/client.ts- 新增 tests/token-refresh.test.tsVerification- npm test: 128/128 passed- npm run build: passed- npm run lint: passedEvidence- 并发 401 测试通过- Refresh failure 测试通过Risks- 尚未进行 Safari 浏览器测试Remaining Issues- None

这比一句：

“已经帮你改好了。”

可靠得多。

十三、把整套方法论抽象成 Codex「六层模型」

如果进一步抽象，可以把 Codex 工程化使用分成六层：

这六层之间存在明显的优先级关系：

• L1-L3 错了
  ：模型再强也容易跑偏；
• L4-L5 不合理
  ：任务可以完成，但效率很低；
• 缺少 L6
  ：即使任务看起来完成了，也无法确认结果是否可信。

因此，一个高质量 Codex 工作流的目标不是“让模型更自由”，而是：

让模型在明确边界内拥有足够能力，并且让结果可以被验证。

十四、Codex 的最佳实践正在从 Prompt Engineering 走向 Agent Engineering

传统 AI 使用方式通常是：

Prompt ↓Answer

而 Codex 更接近：

Context ↓Rules ↓Task Contract ↓Plan ↓Capabilities ↓Agents ↓Execution ↓Verification ↓Evidence

所以，评价一个人是否真正会使用 Codex，不应该只看：

Prompt 写得多复杂。

更应该看：

能不能构建一套稳定、可重复、可验证的 Agent 工作流。

这就是从 Prompt Engineering 到 Agent Engineering 的转变。

十五、Codex 黄金闭环：9 个阶段

整套方法论最终可以收敛成一个非常清晰的 Codex 黄金闭环：

                  Codex Golden Loop                     ① PROJECT                        │                  明确项目边界                        ↓                   ② AGENTS.md                        │                 固化长期项目规则                        ↓                    ③ TASK                        │        Goal / Context / Constraints / Acceptance                        ↓                    ④ PLAN                        │                 复杂任务先设计                        ↓                ⑤ CAPABILITIES                        │       Skill / Plugin / MCP / Subagents / Worktree                        ↓                    ⑥ EXECUTE                        │           Code / Browser / Data / Tools                        ↓                   ⑦ VERIFY                        │       Build / Test / Lint / Security / Diff                        ↓                  ⑧ EVIDENCE                        │             用证据证明任务完成                        ↓                   ⑨ REUSE                        │          重复任务 → Skill → Schedule                        │                        └──────────→ 下一轮任务

这 9 个阶段分别解决九个关键问题：

十六、最后只需要记住五个词

如果觉得九个阶段仍然太复杂，还可以再压缩成五个词：

Context → Plan → Execute → Verify → Reuse

它们分别代表：

• Context
  ：先控制上下文和任务边界；
• Plan
  ：复杂任务先设计，再执行；
• Execute
  ：选择最少但足够的工具和能力；
• Verify
  ：不相信“Done”，只相信验证结果；
• Reuse
  ：把稳定流程沉淀成 Skill 和自动化。

最终，Codex 的效率并不来自让 Agent “知道得更多”，而来自：

让它在更清楚的边界里，遵循稳定的规则和流程，调用恰当的能力，并交付一个能够被验证的结果。

如果要继续往工程化方向推进，最值得建设的不是再收集“50 个 Codex 技巧”，而是建立一套自己的：

AGENTS.md+Task 模板+Skill 目录+MCP 权限规范+Subagent / Worktree 并行规范+验收与 Evidence 模板

做到这一步，Codex 才真正从一个“AI 编程助手”，升级为一套 可复用、可扩展、可验证的 AI Agent 工程系统。

------------------------------------------------

为了方便这个方法论的使用，整理成了skill. 关注“快乐王子AI说", 回复关键词”codex-golden-loop-skill“可以下载。可以直接安装到小龙虾或curso,trae,codex,cloud code,opencode等等。具体的目录如下：