Codex使用技巧：深度解析 Plan Mode 与 Goal Mode

1. 引言：为什么你该关注两种模式
1. 先厘清概念：两种模式到底解决什么问题
- 2.1 Plan Mode：先看清地形，再动手
- 2.2 Goal Mode：盯住终点，持续验证
- 2.3 一张速查表建立直觉
1. Plan Mode 深度解析
- 3.1 工作机制：调研与执行分离
- 3.2 何时应该开启 Plan Mode
- 3.3 使用技巧一：把"约束"写进计划请求
- 3.4 使用技巧二：给计划设置"交付格式"
1. Goal Mode 深度解析
- 4.1 工作机制：目标驱动、循环验证
- 4.2 何时应该使用 Goal Mode
- 4.3 使用技巧三：写下清晰的"完成定义"
- 4.4 使用技巧四：把"验证命令"显式提供给模型
1. Plan Mode 与 Goal Mode 对比
1. 实战：两种模式如何配合使用
- 6.1 一个具体案例：把硬编码配置迁移到环境变量
1. 避坑指南：常见误区与应对
- 7.1 误区一：所有任务都开 Plan Mode
- 7.2 误区二：Goal Mode 下不设边界
- 7.3 误区三：把验证全部交给模型
- 7.4 误区四：一次说不清，反复追加修改
- 7.5 误区五：计划确认后就不再看过程
1. 总结

1. 引言：为什么你该关注两种模式

用过 OpenAI Codex 的开发者大多有共同的感受：让模型"直接写代码"往往简单粗暴，但一旦任务变复杂，比如跨多个文件重构、引入新的第三方依赖、或者需要先理解一个陌生仓库，模型就容易跑偏。它可能生成一个看似完整、实则无法运行的方案，或者在中途悄悄改变技术路线，让最后的输出与预期大相径庭。

造成这种现象的根本原因，并不只是"模型不够聪明"，而是复杂任务通常同时具备三类特征：

信息不完备：模型在动手前并不清楚仓库结构、调用关系、历史约定与约束条件。
路径不确定：同一个目标可能存在多种实现路径，选错方向后越走越偏。
反馈滞后：错误往往要等到编译、测试或人工审查时才暴露，纠错成本高。

Codex 在交互设计上把任务拆成了两种关键模式：Plan Mode（规划模式） 与 Goal Mode（目标模式）。前者强调"先想清楚再动手"，由一个子智能体负责调研、产出分步计划；后者则强调"盯住目标持续推进"，在执行过程中不断拆解任务、验证结果。两者并不是"哪个更高级"的问题，而是分别回应了上述三类困难中的不同侧面。

理解这两种模式的工作机制、适用边界、触发方式与配合方法，是从"碰运气式使用"进阶到"工程化使用" Codex 的关键一步。本文将从原理拆解、实操技巧、适用场景、组合实战与避坑经验五个维度，对 Plan Mode 与 Goal Mode 做一次深度解析。读完本文后，你应当能够：

准确判断一个任务是否需要先规划；
写出包含目标、边界与完成定义的高质量提示词；
在复杂任务中让 Plan Mode 与 Goal Mode 接力协作；
识别并规避使用中的常见误区。

2. 先厘清概念：两种模式到底解决什么问题

在深入技巧之前，需要先建立一个清晰的认知框架。Codex 的 Plan Mode 和 Goal Mode 不是简单的"快慢开关"，也不是"自动档与手动档"的区别，而是针对不同任务形态设计的两种工作范式。

2.1 Plan Mode：先看清地形，再动手

Plan Mode 适合"调研型"任务。当任务包含较多未知信息，例如需要探索代码库结构、确认某个功能当前的实现方式、评估迁移方案的影响面时，先规划可以显著降低返工成本。它由一个专职的子智能体（subagent）负责检索仓库、阅读相关文件，并输出一份可供人工审核的计划。

它的核心价值在于：把"理解问题"和"解决问题"两个阶段分开。在信息不足时，模型不再是边猜边改，而是先把相关信息收集完整，再给出可被评审的行动方案。

2.2 Goal Mode：盯住终点，持续验证

Goal Mode 适合"执行型"任务。当目标相对明确、需要多步骤完成时，Codex 会在子智能体与主智能体之间协作推进，每完成一个子任务就做一次验证，直到目标达成。它的价值在于让模型在长链条任务中保持方向感，并把验证环节前置。

如果说 Plan Mode 回答的是"我们该做什么、为什么这样做"，那么 Goal Mode 回答的则是"如何一步步把这件事做成，并在过程中确认没有走偏"。

2.3 一张速查表建立直觉

问题	答案
任务信息不透明，需要探索？	优先 Plan Mode
目标明确，但步骤多、要边做边验证？	优先 Goal Mode
复杂且影响面大，先出方案再评审？	Plan Mode 后接 Goal Mode
一行 bug、一个函数改名？	直接执行，不必规划

简单地说：Plan Mode 帮你避免"方向性错误"，Goal Mode 帮你减少"半途而废"的风险。

3. Plan Mode 深度解析

3.1 工作机制：调研与执行分离

Plan Mode 的核心是一个独立于主执行循环的规划子智能体。进入计划模式后，Codex 不会立即修改代码，而是进入"只读调研"阶段。它的完整工作链路通常如下：

理解任务意图：主智能体先解析用户请求，判断该任务是否需要规划，并把目标、边界与约束传递给规划子智能体。
探索与检索：规划子智能体扫描仓库结构，定位与任务相关的文件、目录与配置。
阅读与分析：阅读关键代码，理解现有实现、依赖关系、数据流与潜在风险点。
形成假设与方案：对比可能的实现路径，评估各自的成本、风险与兼容性。
产出结构化计划：输出分步计划，包括每一步要改什么、为什么改、涉及哪些文件、如何验证。
人工确认：计划返回给主智能体与用户，经确认后才进入执行阶段。

这一机制的关键在于调研与执行分离：模型可以花更多检索预算去"看清地形"，而不是边跑边猜。需要注意的是，Plan Mode 通常也会受上下文窗口与 token 预算的限制，因此调研范围并不是"无限大"。作为使用者，能清晰圈定搜索范围，往往比让模型"自己看着办"更有效。

3.2 何时应该开启 Plan Mode

并非所有任务都需要开启计划模式。根据实践经验，以下场景收益最大：

代码库陌生或规模较大：刚接手一个仓库，不知道核心逻辑散落在哪些文件里。
影响面不明的重构：例如替换某个公共 API，不确定所有调用点。
技术选型评估：要在多个方案之间做取舍，需要先盘点现有代码的约束条件。
多人协作前的方案对齐：希望先产出一份可以被评审的计划，而不是直接改代码。
涉及安全、权限、数据迁移等高风险改动：任何"错了代价很高"的修改，都值得先规划。
跨模块/跨服务的连锁修改：一处改动可能引发多处联动，需要先梳理依赖关系。

相反，如果只是一个函数改名、修复一行明显 bug、补一个单元测试，直接执行往往更快，规划反而增加等待时间。判断标准可以简化为一句话：如果你无法在 30 秒内说清楚"要改哪几个文件、为什么这样改"，就值得先开 Plan Mode。

3.3 使用技巧一：把"约束"写进计划请求

计划质量的上限取决于你提供的上下文。一个高效的规划请求应至少包含：

明确的目标：要解决什么问题，而不是"帮我优化一下"。最好说明"当前状态"和"期望状态"。
边界条件：哪些文件不要动、哪些依赖不能升级、哪些行为必须保持兼容。
验证方式：希望以什么标准判断计划是否可行，例如"计划应包含可运行的测试用例"。
优先级与取舍原则：当性能、可读性、工期发生冲突时，哪个优先。
已知约束：例如运行环境、框架版本、团队编码规范、历史遗留包袱。

示例：

请在 Plan Mode 下调研当前订单模块的支付回调逻辑，并产出一份重构计划。要求：不修改对外 API 签名，保持现有数据库表结构不变，优先保证兼容性与可回滚性，性能优化次之。计划中需包含每个改动点的风险说明、影响文件清单与验证方法，并说明为什么选择该方案而不是直接修改。

这样的提示词能让计划子智能体把检索预算花在正确的方向上，产出更接近"可评审、可执行"的方案。

3.4 使用技巧二：给计划设置"交付格式"

除了约束内容，还要约束计划的输出格式。没有格式约束的计划，可能变成大段散文，阅读和评审都很痛苦。可以参考以下模板：

背景与目标：一句话说清要解决的问题。
现状分析：当前实现的关键点与问题点。
方案对比：列出 2---3 个候选方案，各自优缺点。
推荐方案：明确选择哪一个、为什么。
分步实施：每步的改动文件、改动内容、风险与验证。
回滚方案：出问题后的退路。
待确认事项：需要人工拍板的问题清单。

示例提示词：

输出计划时使用以下结构：背景与目标、现状分析、方案对比、推荐方案、分步实施、回滚方案、待确认事项。不要直接修改代码。

格式约束能让子智能体的产出从"可以读"升级为"可以执行"。

4. Goal Mode 深度解析

4.1 工作机制：目标驱动、循环验证

Goal Mode 强调"目标驱动、持续验证"。与 Plan Mode 先产出完整计划不同，Goal Mode 允许主智能体在运行时动态拆解任务，并通过子智能体完成局部工作。其典型环路如下：

理解最终目标：主智能体解析用户目标，提炼出验收标准与硬约束。
建立任务清单：将目标拆解为若干可独立完成的子任务，并排定优先级。
派发子任务：将某个子任务交给子智能体执行，返回改动与结果。
验证结果：主智能体通过运行测试、执行命令、检查产物等方式核验结果。
动态调整：根据验证结果决定下一步------继续、修正、换方案，还是升级为需要人工介入的阻塞。
循环直至完成：重复上述过程，直到目标达成或遭遇无法自动解决的阻塞。

这种结构让 Codex 更适合处理"路径不完全确定"的任务：每一步都基于上一步的结果动态调整，而不是死板地按初始脚本执行到底。它把传统"写完再测"的大循环，拆成了多个"小步快跑"的短循环，从而让错误被更早发现。

4.2 何时应该使用 Goal Mode

以下场景是 Goal Mode 的典型应用：

多文件、多步骤的完整功能开发：例如从前端表单到后端接口再到持久化，涉及多个层次。
需要不断调试的任务：模型写完代码后运行测试、根据报错修复、再次运行。
目标明确但实现细节未知：例如"把项目中的硬编码配置迁移到环境变量"，具体改动点需要在执行中发现。
可自动验证的任务：存在清晰的测试、构建或 lint 命令作为"通过/不通过"的判定依据。
需要持续集成的改动：改一处、验证一处、沉淀一处，适合小步提交的工程流程。

需要警惕的是，Goal Mode 的自动性也意味着它可能在错误的方向上"一路狂奔"。如果任务本身方向不明、或者验收标准模糊，直接进入 Goal Mode 反而容易放大偏差。因此，明确验收标准非常重要。

4.3 使用技巧三：写下清晰的"完成定义"

Goal Mode 最容易失控的地方，是模型以为完成了，但你想要的还没做完。因此，强烈建议在任务开头就写明 Definition of Done（完成定义）。一个完整的完成定义至少包含三个层面：

功能层面：什么样的输入会产生什么样的输出，涉及哪些正常路径与异常路径。
质量层面：必须通过哪些测试、通过哪些 lint 检查、满足哪些性能或安全指标。
范围层面：哪些属于任务范围之外，明确排除，避免模型顺手"优化"无关代码。

示例：

目标：为文章模块新增草稿自动保存功能。完成定义：用户编辑超过 10 秒或内容发生变化时，自动保存到 localStorage；刷新页面后能恢复草稿；新增功能需通过现有单元测试，且不修改服务端接口。仓库已有的 eslint 检查必须通过，不新增运行时依赖。

这样，主智能体在每次子任务完成后都有明确的判断依据，而不是"看起来差不多就收工"。完成定义越可被机器判定，Goal Mode 的自律性就越强。

4.4 使用技巧四：把"验证命令"显式提供给模型

Goal Mode 的验证环节不是模型凭空想象的，它需要实实在在的可执行命令。建议在任务描述中显式给出验证方式：

单元测试：npm test、pytest、cargo test
静态检查：npm run lint、ruff check .
类型检查：tsc --noEmit、mypy
构建验证：npm run build、make

例如：

每完成一个子任务后，运行 npm test 和 npm run lint。两项都通过后才能继续下一步；若失败，请先修复并再次运行。

当模型知道"什么算通过"之后，Goal Mode 的循环才有明确的退出条件，否则它可能反复修改却始终无法收敛。

5. Plan Mode 与 Goal Mode 对比

下表从多个维度对比两种模式，帮助你在不同场景下快速决策。

维度	Plan Mode	Goal Mode
核心诉求	先调研、后执行	目标驱动、持续验证
工作重心	收集信息、形成方案	拆解任务、循环推进
修改代码时机	确认计划之后	执行过程中边做边验证
适合任务	探索、评估、重构方案	多步骤开发、调试、迁移
输出形态	结构化分步计划	逐步达成的最终结果
反馈周期	一般较长，先出计划	短循环，边做边验
优势	方向更稳、易评审	推进效率高、易纠偏
风险控制	前置审查，返工少	动态调整，但需明确验收标准
典型反例	一行 bug 修复不宜过度规划	方向不明的方案评估不宜直接执行
对验证的依赖	计划阶段以人工判断为主	执行阶段强依赖自动化验证

需要特别说明：这张表不是"谁更好"的评价表，而是"什么时候选谁"的决策表。多数真实项目里，两者常常先后出现，而不是互相替代。

6. 实战：两种模式如何配合使用

在实际工作中，Plan Mode 和 Goal Mode 并不是二选一，而是可以组合的。一个推荐的协作流程如下：

Plan Mode 产出计划：对于复杂任务，先让规划子智能体调研仓库、给出分步方案。
人工修正计划：你审阅计划，删掉不合理的步骤、补充遗漏的约束、调整优先级。
固化执行约束：把计划中的边界条件与验收标准，转化为 Goal Mode 的任务描述。
Goal Mode 执行计划：让主智能体逐步落地并持续验证，每完成一个子任务就运行验证命令。
阶段性人工检查：在关键节点抽查产物，而不是等到全部结束才 review。
回滚与收敛：若验证失败或方向偏移，回到 Plan Mode 重新评估，而不是盲目追加指令。

#mermaid-svg-vkNLVjxEeVmcG0Cx{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-vkNLVjxEeVmcG0Cx .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-vkNLVjxEeVmcG0Cx .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-vkNLVjxEeVmcG0Cx .error-icon{fill:#552222;}#mermaid-svg-vkNLVjxEeVmcG0Cx .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-vkNLVjxEeVmcG0Cx .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-vkNLVjxEeVmcG0Cx .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-vkNLVjxEeVmcG0Cx .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-vkNLVjxEeVmcG0Cx .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-vkNLVjxEeVmcG0Cx .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-vkNLVjxEeVmcG0Cx .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-vkNLVjxEeVmcG0Cx .marker{fill:#333333;stroke:#333333;}#mermaid-svg-vkNLVjxEeVmcG0Cx .marker.cross{stroke:#333333;}#mermaid-svg-vkNLVjxEeVmcG0Cx svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-vkNLVjxEeVmcG0Cx p{margin:0;}#mermaid-svg-vkNLVjxEeVmcG0Cx .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-vkNLVjxEeVmcG0Cx .cluster-label text{fill:#333;}#mermaid-svg-vkNLVjxEeVmcG0Cx .cluster-label span{color:#333;}#mermaid-svg-vkNLVjxEeVmcG0Cx .cluster-label span p{background-color:transparent;}#mermaid-svg-vkNLVjxEeVmcG0Cx .label text,#mermaid-svg-vkNLVjxEeVmcG0Cx span{fill:#333;color:#333;}#mermaid-svg-vkNLVjxEeVmcG0Cx .node rect,#mermaid-svg-vkNLVjxEeVmcG0Cx .node circle,#mermaid-svg-vkNLVjxEeVmcG0Cx .node ellipse,#mermaid-svg-vkNLVjxEeVmcG0Cx .node polygon,#mermaid-svg-vkNLVjxEeVmcG0Cx .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-vkNLVjxEeVmcG0Cx .rough-node .label text,#mermaid-svg-vkNLVjxEeVmcG0Cx .node .label text,#mermaid-svg-vkNLVjxEeVmcG0Cx .image-shape .label,#mermaid-svg-vkNLVjxEeVmcG0Cx .icon-shape .label{text-anchor:middle;}#mermaid-svg-vkNLVjxEeVmcG0Cx .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-vkNLVjxEeVmcG0Cx .rough-node .label,#mermaid-svg-vkNLVjxEeVmcG0Cx .node .label,#mermaid-svg-vkNLVjxEeVmcG0Cx .image-shape .label,#mermaid-svg-vkNLVjxEeVmcG0Cx .icon-shape .label{text-align:center;}#mermaid-svg-vkNLVjxEeVmcG0Cx .node.clickable{cursor:pointer;}#mermaid-svg-vkNLVjxEeVmcG0Cx .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-vkNLVjxEeVmcG0Cx .arrowheadPath{fill:#333333;}#mermaid-svg-vkNLVjxEeVmcG0Cx .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-vkNLVjxEeVmcG0Cx .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-vkNLVjxEeVmcG0Cx .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-vkNLVjxEeVmcG0Cx .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-vkNLVjxEeVmcG0Cx .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-vkNLVjxEeVmcG0Cx .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-vkNLVjxEeVmcG0Cx .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-vkNLVjxEeVmcG0Cx .cluster text{fill:#333;}#mermaid-svg-vkNLVjxEeVmcG0Cx .cluster span{color:#333;}#mermaid-svg-vkNLVjxEeVmcG0Cx div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-vkNLVjxEeVmcG0Cx .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-vkNLVjxEeVmcG0Cx rect.text{fill:none;stroke-width:0;}#mermaid-svg-vkNLVjxEeVmcG0Cx .icon-shape,#mermaid-svg-vkNLVjxEeVmcG0Cx .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-vkNLVjxEeVmcG0Cx .icon-shape p,#mermaid-svg-vkNLVjxEeVmcG0Cx .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-vkNLVjxEeVmcG0Cx .icon-shape .label rect,#mermaid-svg-vkNLVjxEeVmcG0Cx .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-vkNLVjxEeVmcG0Cx .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-vkNLVjxEeVmcG0Cx .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-vkNLVjxEeVmcG0Cx :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} 否
是
未达标
发现偏差
复杂任务输入
是否需要先调研
Goal Mode 逐步落地
Plan Mode 产出计划
人工审核并修正计划
按完成定义验证
任务完成
阶段性人工检查
交付与归档

这种"先规划、后执行、再验证"的组合方式，既能借助 Plan Mode 降低方向性风险，又能利用 Goal Mode 提高长链条任务的完成率。它本质上是一种"人在环中"的人机协作流程：人在关键决策点介入，机器在重复执行与验证中保持高效。

6.1 一个具体案例：把硬编码配置迁移到环境变量

假设有一个任务："把项目中的硬编码配置迁移到环境变量"。直接进入 Goal Mode 的常见结果是：模型找到一两个文件就动手，结果漏掉了更多配置点，或者顺手改动了无关逻辑。

更稳妥的做法是：

Plan Mode 先排查：搜索项目中所有硬编码配置的位置，梳理配置项、用途、敏感程度，并产出一份迁移计划。
人工确认范围：标记哪些配置必须迁移、哪些可以有默认值、哪些需要保留兼容。
Goal Mode 执行：按文件或模块拆分子任务，逐批迁移配置，并在每批完成后运行测试与构建验证。
抽查与收尾：人工抽查敏感配置是否已从代码中移除，确认没有把密钥提交到版本库。

这个案例能清楚看到两种模式的分工：Plan Mode 负责"找全"，Goal Mode 负责"改对"。

7. 避坑指南：常见误区与应对

7.1 误区一：所有任务都开 Plan Mode

规划是有成本的。对简单任务过度规划，不仅拖慢节奏，还可能让模型产出一堆冗余的"计划性废话"。判断标准很简单：如果你自己闭着眼睛都知道该改哪个文件，就不必开 Plan Mode。 反之，当你需要先理解现状才能下手时，再让规划介入。

7.2 误区二：Goal Mode 下不设边界

Goal Mode 的自动拆解能力很强，但也可能修改超出范围的代码。必须在提示词中明确"不要动什么"，比如"不要重构无关模块""不要升级依赖版本""不要改动测试文件之外的公共接口"。越强的自主性，越需要明确的边界来约束。

7.3 误区三：把验证全部交给模型

无论是 Plan Mode 还是 Goal Mode，模型的自检都可能有盲区。涉及核心业务逻辑时，最好把验证拆成模型可执行的自动化检查（测试、类型检查、lint），而不是简单问一句"你确认对吗"。能被机器判定的标准，就不要用模型的主观判断代替。尤其对于安全相关改动，人工复核不可省略。

7.4 误区四：一次说不清，反复追加修改

如果发现模型反复在同一个地方打转，通常是初始目标不够清晰。此时应该停止追加零散指令，回到目标描述本身，重构约束和完成定义，再重新发起任务。反复追加"再改一下""还是不对"的零散指令，往往只会让上下文更混乱，让模型更难以收敛。

7.5 误区五：计划确认后就不再看过程

即使 Plan Mode 产出了高质量计划，也不意味着 Goal Mode 执行时可以完全放手。复杂的自动化执行仍可能偏航：错误积累、环境差异、遗漏边界都可能让最终结果偏离预期。正确做法是在关键节点留有人工检查点，尤其是在涉及数据、资金、权限的改动上，保持"信任但验证"的态度。

8. 总结

Plan Mode 和 Goal Mode 是 Codex 工程化使用的两个重要抓手：

Plan Mode 让复杂任务在动手前先"看清楚地雷在哪里"，用前置调研换取更低的返工成本。它适合信息不完备、方向不确定、影响面大的工作。
Goal Mode 让长链条任务在推进中"始终盯着终点"，用动态拆解与持续验证提高完成率。它适合目标相对明确、可以被自动化验证的多步骤任务。
两者并非对立，而是可以在真实项目中接力：先用 Plan Mode 看清全局、对齐方案，再用 Goal Mode 稳步落地、循环验证，人在关键节点介入把关。

真正的技巧不在于记住某个模式的名字，而在于根据任务性质做出正确选择：需要看清地形时用 Plan Mode，需要跑完全程时用 Goal Mode，复杂任务则让两者接力配合。 落实到提示词层面，就是始终坚持三件事：写清目标、划清边界、定义完成标准。再叠加适度的自动化验证与人工检查，Codex 才会从"会写代码的助手"变成"靠得住的工程伙伴"。