Codex 三种工作模式使用指南
公众号名称：科技巫师的魔法书
作者名称：科技巫师的魔法书
发布时间：2026-06-20 13:49
一句话结论
普通模式适合一次性问题和明确的小任务。
Plan 模式适合需求不清、风险较高、需要先拆解方案的任务。
Goal 模式适合多步骤、长时间、需要 Codex 持续推进并判断是否完成的任务。
三种模式对比
| 模式 | 主要用途 | 适合任务 | 不适合任务 |
|---|---|---|---|
| 普通模式 | 直接回答或直接执行当前请求 | 问答、解释、简单修改、运行一个命令、查一个错误 | 目标模糊、范围很大、需要长时间持续推进 |
| Plan 模式 | 先理解问题、收集上下文、制定计划 | 需求澄清、技术选型、重构方案、迁移方案、复杂 bug 排查前的分析 | 已经很明确的小任务 |
| Goal 模式 | 绑定一个持续目标，推进到完成、暂停或需要更多信息 | 项目迁移、批量修复、完整功能交付、长链路验证、持续多轮工作 | 普通问答、没有完成标准的问题、临时闲聊 |
普通模式什么时候用
当你希望 Codex 直接处理当前消息，用普通模式最合适。
典型例子：
• “解释一下这个函数在做什么。”
• “帮我把这个错误信息翻译成中文。”
• “运行测试并告诉我失败原因。”
• “把这个按钮文案改成 Submit。”
• “这段 SQL 有没有明显问题？”
普通模式的优势是快、轻、边界清楚。Codex 不会额外维护一个长期目标，也不会把一次性问题包装成项目。
普通模式的限制也很明显。如果任务本身很大，比如“全面优化这个项目的性能”，普通模式可能会缺少明确边界。Codex 可能需要先问范围、指标和验收标准。
Plan 模式什么时候用
当你还没完全确定怎么做，或者希望 Codex 先想清楚再动手，用 Plan 模式。
典型例子：
• “这个项目要从 REST API 迁到 GraphQL，先给我方案。”
• “我想重构鉴权模块，但不确定风险在哪里。”
• “帮我看这个 bug 可能从哪些路径排查。”
• “先别改代码，比较三种缓存方案。”
• “把这个模糊需求问清楚，再写实现计划。”
Plan 模式的重点不是交付代码，而是降低误判。它适合让 Codex 读取上下文、提出问题、识别风险、拆步骤。
Plan 模式适合在这些情况下先用：
• 需求里有多个可能解释。
• 任务会影响多个模块。
• 技术路线有明显取舍。
• 需要先定义验收标准。
• 你担心 Codex 过早改代码。
Plan 模式不适合已经很明确的小任务。比如“把标题从 A 改成 B”，没有必要先规划。
Goal 模式什么时候用
当你要把一件事交给 Codex 持续推进，用 Goal 模式。
Goal 模式需要一个清楚的目标。这个目标既是起点，也是完成标准。Codex 会围绕它决定下一步做什么，并反复检查是否已经完成。
典型例子：
• “把这个 JavaScript 项目迁到 TypeScript，要求 npm test 和 npm run build 都通过。”
• “修复登录流程中的 3 个已知 bug，并补充回归测试。”
• “实现导入 CSV 的完整功能，包括解析、错误提示、测试和文档。”
• “把所有 ESLint 错误修完，但不要改业务逻辑。”
• “完成这份报告，要求包含数据来源、图表、结论和不确定点。”
好的 Goal 应该包含三类信息：
• 具体结果。比如“迁到 TypeScript”，不要只写“优化项目”。
• 验收标准。比如“测试通过”“构建通过”“页面在移动端不溢出”。
• 限制条件。比如“不要引入新框架”“只改 src/auth 目录”。
一个好的 Goal 示例：
把当前 React 项目的登录页改成响应式布局。桌面端宽度 1440px、平板 768px、手机 390px 都不能出现文本重叠或横向滚动。完成后运行现有测试，并用浏览器截图检查三个视口。
一个不好的 Goal 示例：
优化一下这个项目。
这个目标太宽。Codex 不知道优化性能、代码质量、视觉设计、依赖体积，还是构建速度。
为什么不把所有问题都默认用 Goal 模式
Goal 模式不是普通模式的加强版。它是长期任务控制机制。
不默认使用 Goal，主要有四个原因。
第一，很多问题没有可验证的完成条件。比如“解释一下 Plan 模式”，回答完就结束，没有持续目标。
第二，Goal 模式会增强 Codex 的自主推进倾向。对迁移、修复、完整交付有用。对简单问答可能过重。
第三，Goal 模式会占用更多上下文。目标文本和进度判断会持续影响后续对话。
第四，显式开启 Goal 可以保持授权边界清楚。你是在明确告诉 Codex：“这件事可以持续推进，直到达到这个完成标准。”
推荐决策流程
可以按下面四个问题判断。
1. 这只是一个问题或小改动吗？ 用普通模式。
2. 需求、范围或方案还不清楚吗？ 用 Plan 模式。
3. 已经有明确目标和验收标准，并且需要多步执行吗？ 用 Goal 模式。
4. Goal 还写不清楚吗？ 先用 Plan 模式，让 Codex 帮你把目标整理成可执行、可验收的 Goal。
常见场景建议
| 场景 | 推荐模式 | 原因 |
|---|---|---|
| 问一个概念 | 普通模式 | 一次性回答即可 |
| 让 Codex 解释一段代码 | 普通模式 | 输入和输出都清楚 |
| 修改一处文案 | 普通模式 | 范围很小 |
| 调查一个复杂 bug | Plan 模式起步 | 先确定复现路径和排查顺序 |
| 做技术选型 | Plan 模式 | 需要比较约束、成本和风险 |
| 迁移一个项目 | Goal 模式 | 多步骤，验收标准明确 |
| 完整实现一个功能 | Goal 模式 | 需要编码、测试、验证和收尾 |
| 长时间持续检查某件事 | Goal 模式或自动化 | 如果需要定期触发，应考虑 automation |
实用写法
普通模式可以直接问：
解释一下这个错误为什么出现。
Plan 模式可以这样写：
/plan 先不要改代码。请阅读认证相关模块，找出把 session 存储从 cookie 改成 Redis 的实施方案、风险和测试点。
Goal 模式可以这样写：
/goal 完成 session 存储从 cookie 到 Redis 的迁移。要求现有登录、登出、刷新登录态测试通过；新增 Redis 不可用时的错误处理测试；不要改变公开 API。
最短建议
不确定时，先用普通模式问一句。
任务变复杂时，切到 Plan。
目标和验收标准清楚后，再开 Goal。
内容效果不满意？点此反馈