用过 Codex 的人应该都有同感这玩意儿和传统的 AI 补全工具完全是两种物种。它不只是帮你续写几行代码而是真正能自己打开项目、读文件、改代码、跑命令像个坐在你旁边的结对程序员。但能力越强翻车的可能性也越大——尤其是当你让它自主完成一整个任务时它可能兴致勃勃地改掉一堆不该动的文件或者在你还没想清楚方案的时候就冲了出去。我最初接触 Codex 的时候踩了不少坑。后来把它的工作模式理清楚尤其是把 Plan Mode 和 Goal Mode 用对地方之后效率才真正提上来。这篇文章就围绕这两个模式展开聊清楚它们分别在什么场景下用、怎么配、怎么玩以及我在实际项目中遇到过的报错和解决办法。不管你是刚安装好 Codex 的新手还是已经用它写过一阵子的老手这篇应该都能让你少走一些弯路。1. Plan Mode 与 Goal Mode 到底是什么1.1 一句话说清两种模式Plan Mode 直译过来就是“计划模式”。Codex 在接到你的任务后不会马上动手改代码而是先输出一份实现计划包括它准备改哪些文件、按什么顺序改、中途会遇到哪些风险然后停下来等你确认。你点击批准或回复确认之后它才真正进入执行阶段。换句话说Plan Mode 把“想”和“做”拆成了两个步骤中间加了一道人工审核关卡。Goal Mode 则相反。你只需要把最终目标描述清楚比如“把支付回调的签名校验补上并加日志”Codex 会自己拆任务、自己改代码、自己跑测试一路把活干完。整个过程中你可以看它的操作日志但它不会在每一步都征求你同意。Goal Mode 适合方向明确、风险可控、你不太关心中间路径的任务。这两种模式表面上只是“是否要审批”的区别但背后对应的使用心态完全不同。Plan Mode 是在做工程管理Goal Mode 是在做目标管理。我见过很多人只用其中一种然后抱怨 Codex 太啰嗦或者太激进其实问题往往不是 Codex 本身而是模式没选对。1.2 两种模式的背后逻辑先聊聊设计思路。Plan Mode 更像“先图纸、后施工”。这背后涉及大模型可靠性的问题大模型生成的代码不是百分百正确尤其在大型项目中如果一上来就改很可能会破坏既有逻辑。先做计划至少能让你在它动手之前发现方向性错误。比如它打算删掉一个公共函数而这个函数被三个模块引用这种问题在计划阶段一眼就能看出来。Goal Mode 则把模型当成了一个能自主推进的执行者。它更适合你充分信任模型能力的场景。既然 Codex 可以读代码、跑测试、根据报错自动修复那你只需要给它一个明确的定义“完成”的标准剩下的过程让它自己迭代。这种情况下如果你还是每一步都去截停反而会打断它的思路让它在上下文窗口里反复横跳最后改得四不像。还有一个容易被忽略的点上下文窗口是有限的。如果每个小步骤都要求 Codex 停下来汇报大量 token 会消耗在解释、等待、重新加载上下文上。Goal Mode 的连续执行模式其实也是在帮我们省 token、省时间。1.3 和普通 AI 对话式编码的差别传统的方式是你在 ChatGPT 或者编辑器的 AI 对话框里提问它给你一段代码你复制、粘贴、手动调试。这个过程里AI 只是一个“建议生成器”它看不到你项目的完整结构也不会去运行测试更不会自己去翻日志。Codex 的 Plan Mode 和 Goal Mode 之所以值得单独讲是因为它们都能直接落盘。Plan Mode 下它虽然不先改代码但它已经完成了一次“项目体检”——比如它知道你的项目用的是 FastAPI 还是 Flask配置文件在哪个路径测试框架是 pytest 还是 jest。这些信息会直接反映在它生成的计划里。Goal Mode 就更不用说了它是真正“动手干”的那个改完文件还会跑一遍命令来验证。所以如果你还在用复制粘贴的方式和 AI 协作那确实该试试这两种模式了。它们把 AI 从一个“问答工具”升级成了“能独立推进项目的执行者”。2. Plan Mode 实操要点2.1 什么时候切到 Plan Mode我的经验是下面这几类任务用 Plan Mode 的价值最大跨多文件的重构。比如把一个老模块拆成两个服务或者把公共函数抽到独立模块。这种改动影响面大必须先看全局方案。涉及接口协议、数据库结构、配置项调整。一旦改错线上就可能挂掉这类任务绝不能盲跑。你不熟悉某段代码。让 Codex 先梳理一遍逻辑、给出改动计划相当于免费帮你做了一次代码 review。任务描述有歧义。比如“优化一下列表页的加载速度”到底优化哪里前端渲染还是后端 SQL让 Codex 先给方案你就能在计划里看出它理解得对不对。相反如果是改一个文案、修一个明显的空指针判断、或者给函数补几行日志这种几分钟能搞定的小事用 Plan Mode 反而显得笨重。2.2 Plan Mode 的完整工作流在交互界面里把模式切到 Plan 之后正常输入任务描述即可。我给一个实际用过的例子我想给项目的商品列表接口加一层 Redis 缓存但不想让 Codex 直接动手于是我这样写在商品列表接口加 Redis 缓存key 的设计要包含分页参数和筛选条件注意缓存击穿和穿透处理。先给出计划不要直接改代码。Codex 在 Plan Mode 下会输出一份结构化的计划大致包括涉及到的文件goods/service.py、goods/router.py、config/settings.py具体改动点在 service 层加缓存读写逻辑在 config 中加 Redis 连接配置风险提示并发情况下可能出现缓存击穿需要加分布式锁测试方案用 pytest 模拟 Redis 不可用时的降级逻辑看到这个计划我就能判断它思路对不对。如果没问题直接回复“开始执行”它才会进入执行流程去改代码。如果中间某一步我不想按它的计划来我就在对话里指出来比如“把锁的实现改成原子操作再执行”。还有一个容易忽略的细节Plan Mode 下生成的计划是可以反复调整的。你可以像 review 同事的设计文档一样先让它改计划而不是让它直接改代码。计划满意了再放行这样能把返工成本压到最低。2.3 审批计划时的判断标准既然 Codex 把计划交到你手上了怎么判断这计划行不行我的标准是三条覆盖面够不够全。计划里有没有覆盖所有的调用方比如改一个函数签名它有没有顺带梳理出哪些地方调用了这个函数有没有考虑失败场景。比如加缓存时有没有考虑缓存过期、缓存穿透、Redis 挂了怎么办测试方案是否明确。它打算怎么验证改动是对的是跑特定测试用例还是启动服务手动验证如果三条都满足这个计划基本可以放心执行。如果计划比较含糊比如只写“修改 service 层”却不说具体怎么改我就会追问一句“具体打算怎么改列出代码级别的改动点”。Plan Mode 的意义就在这儿——它是给你提供了一个“干预窗口”别白白浪费。注意Plan Mode 下 Codex 会生成计划但不会自动执行也就不存在改坏代码的风险。所以遇到大任务我先切 Plan Mode 探路几乎已经成了肌肉记忆。3. Goal Mode 实操要点3.1 怎么给 Codex 设定目标Goal Mode 听起来很省心但前提是目标描述要合格。一个合格的目标至少包含三个要素做什么要完成的功能或要修复的问题是什么。交付标准达到什么程度算完成比如要有测试、要兼容旧参数、要保证不小于某个性能指标。边界约束哪些文件不要动哪些依赖不能升级哪些逻辑不要碰。我举一个常见的反面例子帮我把用户反馈页面优化一下。这种描述在 Goal Mode 下会非常危险因为“优化”的定义太宽泛了。Codex 可能去改字体、改布局、改接口甚至把整个前端依赖升级一遍。不是它不听话而是它确实不知道你的“优化”具体指什么。我通常这样写把用户反馈页面的移动端适配做完要求低于 768px 时表单单列展示按钮不要超出屏幕宽度不要改动后端接口和数据结构。这样“目标”“验收标准”“边界”都齐了Codex 跑偏的概率会小很多。3.2 一个真实的 Goal Mode 案例拿我最近做的一个内部管理后台来说需求是在订单管理页增加一个“按筛选条件导出 Excel”的功能。我在 Goal Mode 下写的是在订单管理页增加按筛选条件导出 Excel 的功能列头和现有表格一致导出文件名带日期金额字段保留两位小数。Codex 自己做了这么几件事选了openpyxl作为导出库读了现有的订单查询函数把筛选条件透传给了导出逻辑在后端路由层新增了一个导出接口在前端页面加了一个导出按钮还顺手写了一个校验导出格式的单元测试。整个过程里我没插手让它怎么改只在中途发现它把金额字段的精度处理错了就在对话里纠正了一句“金额格式化的时候保留两位小数别用浮点数直接拼接”。它马上修正了并且重新跑了测试。这个案例给我的感受是Goal Mode 并不是完全不需要人管而是把人的角色从“进程内干预”变成了“结果验收”。你盯着它的关键节点发现问题再纠偏其他时间让它自己跑就行。3.3 防止 Goal Mode 跑偏的方法跑偏是 Goal Mode 最让人头疼的问题。结合我的经验这几个方法比较有效明确写出“不要做什么”。比如“不要动公共配置”“不要修改现有数据库字段”相当于给 Codex 画了一条红线。中途看 diff而不是只等结果。Codex 改完一部分文件后我会立刻打开 git diff 看一眼发现它在动无关文件就马上喊停。让 Codex 每完成一个阶段就暂停汇报。虽然这叫 Goal Mode但你可以通过 prompt 要求它“每改完一个模块就停下来说明改动内容确认后再继续”。这个技巧实测很稳既保留了 Goal 模式的高效又加了必要的检查点。不要同时扔给它多个大目标。一次一个大目标完成验收后再给下一个。多个目标堆在一起Codex 在上下文里容易串线经常出现改完 A 忘了 B 的情况。经验跑偏的 Codex 就像话痨同事你不打断它它能哐哐改半小时。所以我在 Goal Mode 下依然会定期扫一眼日志和 diff只不过从“每个操作都确认”变成了“关键节点看一眼”。4. 模式配合与切换4.1 任务粒度决定模式选择用久了你会发现Plan Mode 和 Goal Mode 不是一个“更好”一个“更差”而是适合不同的任务粒度。场景推荐模式原因改文案、补日志、修小 bugGoal Mode效率高改完即走新增一个独立功能模块Goal Mode边界清晰可自主完成跨文件重构Plan Mode影响面大需要先看方案接口协议、数据库结构调整Plan Mode风险高必须人工卡一道写单元测试覆盖老代码Goal Mode目标明确Codex 自主能力强弄清楚某个旧模块的实现逻辑Plan Mode让它先输出理解再做后续安排简单来说任务越“局部”、越“明确”越适合 Goal Mode任务越“全局”、越“危险”越适合 Plan Mode。如果你拿不准那就先用 Plan Mode 探一次路成本低、容错高。4.2 Plan 分阶段 Goal 执行的混合打法我工作中最常用的其实是混合模式一句两句说不清楚但核心套路是先用 Plan Mode 把整体方案理出来。比如“把用户认证从 Session 换成 JWT”我让 Codex 先输出一份全量计划包含用户表改动、登录接口改动、中间件改动、前端登录态处理。计划审阅通过后我会把它拆成几个阶段比如第一阶段改造后端登录接口返回 JWT第二阶段新增鉴权中间件替换原有 Session 校验第三阶段改前端登录态存储方式然后每个阶段切到 Goal Mode 去执行。每执行完一个阶段我都会看一眼 git diff跑一遍相关测试确认没问题后再进入下一阶段。这种混合打法的好处是整体方向可控细节执行高效。Plan 阶段解决“要不要做、按什么顺序做”Goal 阶段负责“怎么做得更快”。如果中途发现新的问题只需要重新切回 Plan 模式让 Codex 出补充方案然后再回 Goal 模式执行。4.3 长期项目里的模式管理如果你在一个长期项目里天天用 Codex我强烈建议维护一个“项目上下文文档”。这个文档可以是CODEX.md或者AGENTS.md放在项目根目录。里面写清楚项目的技术栈、目录结构、常用命令、代码风格、以及哪些文件是“禁区”。Codex 在启动时会自动读取这类文件相当于一上岗就先看了一遍项目文档。有了这个基础Plan Mode 出的计划会更准确Goal Mode 跑偏的概率也会明显降低。我自己的项目上下文文档里一般包含这么几块项目简介和技术栈如何启动服务、如何跑测试常用命令和脚本后端 API 规范、数据库约定禁止自动修改的路径列表这个文档花不了多少时间但长期收益非常大。它能让两种模式效率都上一个台阶尤其是减少 Plan Mode 里“我解释半天项目背景”的啰嗦环节。5. 常见报错与排查实录5.1 安装与启动问题Codex 的安装过程整体还算顺但 Windows 上偶尔会出现“安装未完成”的情况进度条走到一半就停住或者提示失败。我处理过的这类问题常见原因有三个安全软件拦截了安装脚本的启动行为安装程序需要管理员权限但当前用户没有提权缺少系统运行库比如某些 VC 运行库解决思路也比较直接先暂时关掉安全软件再安装安装时右键选择“以管理员身份运行”如果还不行就补装系统运行库。装完之后再到命令行敲codex --version确认版本号能正常打出来这样才算真正装好。还有一种是安装完之后登录有问题打开官网登录页面卡住或回跳。这种情况一般清一下浏览器缓存、确认登录账号状态换个浏览器大概率能解决。如果启动时提示登录失效直接重新登录即可。5.2 模型支持问题我在使用过程中遇到过一个报错内容大概是the gpt-5.6-sol model is not supported when using codex with a ...这个字面意思是你在 Codex 里配置了一个当前版本不支持的模型。常见于自己改了配置文件把model字段填成了某个新模型版本或第三方模型标识而当前 Codex 版本还没适配它。解决办法有两条把 Codex 更新到最新版本让官方模型列表同步更新打开config.toml把model字段改回官方支持的模型或者改成你要接入的 OpenAI 兼容接口所对应的模型名顺便提一句Codex 本身支持通过 OpenAI 兼容接口来接入第三方模型或自建网关这在社区里已经是很常见的玩法。如果你也这么配过一定要确认model字段和你的服务商实际提供的模型标识完全一致否则就会撞上这种“not supported”的报错。5.3 网络与接口异常另一个我见过的报错长这样cc switch local proxy failed while handling codex endpoint /responses这个错误字面上是Codex 在处理/responses接口时切换本地代理失败。它的本质是 Codex 到模型接口之间的网络链路出问题了。常见诱因可能包括本机残留了旧项目的代理配置环境变量里有指向无效地址的HTTP_PROXY或HTTPS_PROXY或者本地网络策略调整后没有重启应用。排查步骤我一般按这个顺序来检查系统环境变量看有没有遗留的代理配置有则清理检查 Codex 配置文件里是否设置了自定义base_url确认地址可正常访问重启 Codex重新登录一次如果改过本地网络配置先恢复正常再测试这里要特别说一句这种问题大多是环境配置残留导致的不是 Codex 本身坏了。我遇到过的几次基本都是环境变量里写着旧的代理地址把它清掉之后错误就消失了。如果你试了一圈还没解决最稳妥的做法是把项目的配置文件备份后重置再重新配置一遍。很多时候重新走一遍初始化流程比在错误配置上纠结半天要快得多。我用 Codex 这段时间最大的体会就是它确实像个有个性的结对开发者你给它越多约束和上下文它的表现就越稳定。Plan Mode 和 Goal Mode 的边界并不是死的我现在的工作流基本就是“大方向用 Plan小步骤用 Goal”中间配合 git diff 做人工校验。这套打法用顺了以后改代码的阻力会小很多。你也别急着把两种模式分个高下拿个中等规模的项目各试一遍你自己心里就会有答案。