Skip to content

Auto-generated English stub on 2026-04-24. Replace with a proper translation.

title: "Codex Plan 模式完全指南 | 用 Plan→Execute 终结失控" description: "Codex Plan 模式（准确说是 Collaboration mode β 的 Plan 体验）实战指南：最快启用、基本操作、Plan 模板、Plan→Execute 工作流、常见坑点全解析。" date: 2026-01-28 categories: - AI开发 - 开发效率 tags: - codex - codex-cli - plan - plan-mode - collaboration-mode - agentic-coding - dev-workflow - tui keywords: - Codex Plan - Codex Plan 模式 - codex plan mode - collaboration_modes - Plan Execute

Codex Plan 模式完全指南 | 用 Plan→Execute 终结失控

Codex CLI 完全指南

"Codex 也该有 Plan 了"——Claude Code 的 Plan 工作流在实务中已经证明了价值，而 Codex 这边一直有人在问"什么时候出？" 现在，Codex 也引入了 Plan→Execute 分离体验（最初为 β，v0.96 起已较稳定），减少失控和事故的路径正在成形。

重要：本文所说的"Plan 模式"指 Collaboration mode 提供的 Plan 体验。早期为 β，当前版本仍可能调整 UI 标签、模式名、操作方式、标志名——如果发现不一致，请先确认 codex --version。

本文内容概览

  • 在 Codex 中启用 Plan 模式（Plan 体验） 的最快步骤
  • 用 Plan→Execute "单轨"运营模板终结失控
  • 常见坑点（β 功能特有行为）及规避方案
  • （附录）从 Claude Code Plan 工作流"移植"的要点

先说结论：Plan 的价值不是"写得好"，而是"工程分离"

Plan 模式的本质：

  • Plan（设计）：先锁定做什么、不做什么、步骤、验证
  • Execute（实现/执行）：在不破坏 Plan 的前提下推进实现
  • 遇到犹豫，回到 Plan 写明变更理由（不擅自改方向）

LLM 编码事故大多源于"边写边跑偏"，工程分离能有效防止这一点。

10 分钟上手：启用 Codex Plan 模式（Plan 体验）

2026 年 2 月，已在 CLI v0.104.0 验证。Plan 模式自 v0.96+ 默认开启。v0.93〜0.95 需手动启用 collaboration_modes 标志。

1) 确认版本（第一步）

codex --version

2) 仅当前会话启用（最快）

codex --enable collaboration_modes

3) 永久启用（不想每次都敲）

在 ~/.codex/config.toml 中添加：

[features]
collaboration_modes = true

这是 β/实验性功能，启动时可能会看到类似 "Under-development features enabled … may behave unpredictably" 的警告。 有时还会提示抑制警告的配置（例如 suppress_unstable_features_warning = true），请根据运营策略自行决定。

4) 会话内切换与确认（最快）

/plan         # 直接切换；/collab 只是打开菜单
/status       # 查看是否显示：Collaboration mode: Plan

也可以用 Shift+Tab 在 Plan / Pair / Execute 间循环。/collab 会弹出同样的菜单，但 /plan 是最稳的快捷方式。

屏幕显示

  • 右上角模式指示或 /status 输出的 Collaboration mode: 行能看到当前模式。
  • 底部状态栏可能出现 ? for shortcuts · Plan mode (shift+tab to cycle) 提示（不同版本表述略有差异）。
  • 完成 Plan 时可能弹出 CTA，如 Implement this plan? 1) Yes, implement this plan → Switch to Default and start coding. 2) No, stay in Plan mode。按提示编号即可回到编码；若未出现或错过，可用 Shift+Tab 或 /collab 选择 Default/Pair/Execute。

基本操作：/status 和模式切换（主操作路径是 UI/快捷键）

/status（查看状态）

开始 Plan 体验前，先查看当前状态：

/status

模式切换（UI/快捷键）

社区实例中有用 Shift+Tab 等切换模式的介绍。 而 /collab 等命令可能尚未正式文档化，因此在公开文章中建议以 UI/快捷键操作为主。

模式名称差异（Plan / Coding / Pair / Execute）

模式标签在不同版本间存在差异。从概念上这样理解即可：

  • Plan：创建设计的场所（目标、步骤、验证）
  • Coding / Pair Programming：对话式实现的常规模式
  • Execute：基于 Plan 推进执行和应用

即使显示名不同，"明确 Plan→Execute 交接"的设计理念是一致的。

实战高效：3 种 Plan 模板（直接复制使用）

在 Plan 模式里只需要“贴上去并填空”，不在这里实施。Plan 定稿后再切回 Pair/Execute 去动手。

Plan 写太长反而拖慢节奏，要设定上限。

模板 A：极简（小改动 / 5~10 行）

  • 目的（1 行）
  • 变更点（最多 3 个）
  • 影响范围（文件/模块）
  • 验证（命令或检查点）

示例：

目的：将审计日志转为 JSON，稳定解析流程

变更点：锁定 logger 输出键 / 异常时也用同样格式 / 不兼容旧格式

影响：api/logger.ts、middleware/log.ts

验证：unit + e2e，用 jq 格式化示例日志

模板 B：稳健（中等规模 / 需求容易变动）

  • Goal / Non-goal
  • 步骤（Step 1..N）
  • 兼容性（是否有破坏性变更）
  • 回滚方案
  • 测试计划

填好后的示例（可直接替换）

Goal: 将支付 API 切到网关 v2
Non-goal: 不改结算页 UI
步骤: Step1 将 token 发行切到 v2 / Step2 增加 Webhook 校验 / Step3 删除 v1 代码
兼容性: 移动端 <1.8 不支持（提示错误）
回滚: 标志 PAYMENTS_V2=false 退回 v1
测试: unit(payments/*), e2e(卡/3DS/失败场景)

模板 C：防事故（基础设施/权限/监控/计费）

  • 风险（高/中/低）及理由
  • 受影响的利益相关方
  • 监控/告警/指标变更
  • 执行步骤（判断标准与恢复方案）

填好后的示例（基础设施场景）

风险: 中（权限升级配置错误可能泄漏数据）
利益相关方: SRE, 安全, 计费
监控/告警: 将 CloudWatch AuthzDenied 阈值 5→3
执行:
 1) 给 IAM 角色 billing-writer 应用策略 v3
 2) 在日志中确认 AssumeRole 成功
 3) 跑金丝雀账单 PDF；如失败，回滚到策略 v2

终结失控：Plan→Execute"单轨"运营

推荐做法是在运营层面固定"Plan 与实现的边界"。

  1. Plan 达成共识

    • 先确定成功条件（Done）
    • 用模板锁定步骤和验证

  2. 实现（Coding/Execute 侧）

    • 按 Plan 推进实现
    • 中途需求变化时，先回到 Plan 追加变更理由

  3. 验证后完成

    • 执行 Plan 中定义的验证，满足即完成

推荐口号：

"成功条件是 X。Step1→Step2。犹豫了就回到 Plan。"

常见坑点（β 功能，"不要下定论"才是正确态度）

1) 有报告称模型/推理设置会被预设覆盖

启用 collaboration_modes 时，有报告指出模式预设会覆盖 model / model_reasoning_effort 设置。 稳妥的对策：

  • 将设计（Plan）和实现（执行）分到不同会话
    • Plan 用：collaboration_modes ON
    • 实现用：普通模式锁定模型
  • 在 collaboration_modes 会话中，不要指望模型锁定能生效

2) Plan 写太长导致变慢

Plan 如果变成"为写而写"就会崩。坚持使用模板 A/B/C，遵守上限。

3) 交接模糊，变成"照旧执行"

每次 Plan→Execute 交接时都要加入桥接说明（成功条件、步骤、犹豫了就回到 Plan）。

附录 1：将 Claude Code 的 Plan 工作流移植到 Codex 的技巧

Claude Code 的 Plan 在实务中有效的三个核心原因：

  • 先写 Non-goal（锁定"不做什么"）
  • 先确定验证方式（Done 标准不会漂移）
  • 变更越多，越要在 Plan 中记录变更理由（成为决策日志）

直接移植到 Codex，Plan 的价值就能快速体现。

附录 2：Plan 的"恰到好处"粒度（判断标准）

  • 5 分钟搞定的修改：模板 A（简短）
  • 半天以上的变更：模板 B（兼容性与回滚）
  • 出事会很痛的领域：模板 C（运维视角）

附录 3：团队协作的最小规则

  • PR/Review 前先贴"Plan（至少模板 A）"
  • Plan 有变更时，先在 Plan 中追加"变更理由"再继续实现
  • Done 判定以 Plan 的验证项为准（不凭感觉结束）

相关 Codex CLI 指南

参考链接（一手资料与复现材料）