跳转至

3.2 Codex 的操作模型

Codex 更适合作为工程执行型 Agent 来理解：给它明确目标、上下文指针、约束和完成标准，然后让它在仓库里执行。

它的强项不是替你“随便想想”，而是在约束清楚时把工程任务推进到可验证结果：读 repo、改文件、跑命令、解释失败、继续修复。

Codex 最重要的输入

Codex 任务最好包含四件事：

Goal
Context Pointers
Constraints
Done When

这也是 OpenAI Codex 课程中强调的委派方式。

AGENTS.md 的作用

AGENTS.md 是 Codex 的项目规范入口。它应该告诉 Codex：

  • 项目如何运行。
  • 如何测试。
  • 哪些目录重要。
  • 哪些规则必须遵守。
  • 什么算完成。
  • 哪些坑不要踩。

示例：

# AGENTS.md

## Commands
- Test: `pnpm test`
- Typecheck: `pnpm typecheck`
- Build: `pnpm build`

## Workflow
- Before editing, inspect existing implementations.
- For multi-file tasks, propose a plan first.
- Before completion, run relevant checks.

## Guardrails
- Do not change public API shape unless explicitly requested.
- Do not add dependencies without explaining why.

Codex 适合的任务

适合：

  • 明确 feature。
  • 后端逻辑。
  • Bug 修复。
  • 测试补齐。
  • CLI / 脚本。
  • 重构。
  • 文档同步。
  • 多 Agent / worktree 并行任务。
  • 代码审查和安全/边界风险检查。
  • 需要明确审批、沙盒或权限边界的任务。

不适合：

  • 需求完全不清楚。
  • 需要大量产品探索但没有边界。
  • 没有验收标准的“优化一下”。
  • 高风险生产操作。
  • 需要切换非 OpenAI 模型的工作流。
  • 主要诉求是本地模型或多供应商统一入口。

Codex 的典型优势和代价

维度 结论
代码质量 适合严谨实现、bugfix、测试补齐和 review
速度 复杂任务上可能更慢，但通常更愿意走完整推理和验证
生态 和 OpenAI、ChatGPT、Codex App / IDE / CLI、AGENTS.md、MCP、skills、subagents 等能力形成一套生态
灵活性 官方主线绑定 OpenAI 模型，模型选择自由度不如 OpenCode
安全 适合通过 sandbox、approval、最小权限和验证命令控制风险

你应该把 Codex 当成“工程执行同事”，而不是“灵感聊天对象”。任务越明确，它越有价值。

推荐操作流程

1. 用网页或人脑整理 Task Brief。
2. 让 Codex 先只读分析。
3. 要求 Codex 写计划和验证命令。
4. 确认计划。
5. 让 Codex 实现。
6. 让 Codex 运行验证。
7. 人审 diff。
8. 让 Codex 根据 review 修复。

Codex 使用提醒

  • 不要省略 Done When。
  • 不要让 Codex 在没有上下文指针时猜。
  • 不要让多个 Agent 改同一个文件范围。
  • 不要把高风险写入权限随便交给它。
  • 不要把“运行失败但推测没问题”当完成。
  • 不要用它替代代码审查。让它先自查，再由人审 diff。
  • 如果你需要多供应商或本地模型，把 OpenCode 放到工具链里。