Codex /goal 怎么用：开启目标模式、管理任务与验收结果
在支持 Goals 的 Codex 中，输入 /goal 加上具体目标，就能让任务围绕同一结果持续推进。命令缺失时先检查版本与 features.goals；完成与否要看测试和交付物，预算耗尽只是停止条件。
文章目录
Codex /goal 的用法是：在 Codex 对话输入框中输入 /goal <具体目标>，把希望达到的结果和验收方式交给当前对话持续推进。随后用 /goal 查看目标，用 /goal edit 修改目标，用 /goal pause、/goal resume 和 /goal clear 控制后续工作。当前 官方命令文档已经说明这些操作。
如果你看不到 /goal，先确认客户端支持 Goals，再按官方方法开启 features.goals。如果你已经能设置目标，下一步最重要的是写清楚“做到什么才算完成”：修复代码后测试通过、生成的文件符合要求，或调查结论有可核对的证据。运行时间长、Token 用完、助手说“已完成”，都不能单独替代验收。
下面的设置和行为说明依据 2026 年 10 月 7 日的官方资料；示例是为说明写法设计的项目场景，不是一次实际无人值守运行记录。
/goal 是什么，什么任务值得用
/goal 为当前对话保存一个持续目标。一次工作结束后，目标仍在；当任务还没完成且满足继续条件时，Codex 可以根据刚得到的结果选择下一步，不必等你反复发送“继续”。目标属于该对话，不是全局记忆，也不会自动变成项目的 AGENTS.md 规则。官方 Goals 说明对此区分得很清楚。
这种方式适合“终点明确，路线需要边做边查”的工作。例如，一组导入测试失败，你知道最终要恢复正确的导入行为，但还不知道问题出在解析、字段转换还是后续处理。Codex 需要先复现，再修复，再检查相关测试，可能不止一轮。
| 你的请求 | 更合适的起点 | 原因 |
|---|---|---|
| 解释一段代码、改一个按钮文案 | 普通对话 | 一次明确回答或修改就能交付 |
| 想改造模块，但还没确定应保留哪些行为 | 先讨论或规划 | 先确定结果，避免把模糊需求带入长任务 |
| 修好一组失败测试，并保持现有数据格式 | /goal | 可以用测试持续检查，下一步取决于失败原因 |
| 调查间歇性故障，交付复现条件与证据 | /goal | 即使最后不能修复，也能事先定义合格的调查结果 |
| “把整个项目都优化一下” | 先缩小任务 | 没有明确终点，难以判断何时停止 |
目标不需要列出每一步。你可以让 Codex 自己判断下一处该查什么，但不能省略成功标准。否则它可能做了很多改动，你却无法确认这些改动是否解决了原问题。
没有 /goal 命令时，先检查版本和功能开关
官方说明 Goals 从 Codex 0.128.0 开始提供。这个数字是功能引入版本，不是当前最新版，也不能单凭版本号证明桌面应用、IDE 扩展和 CLI 的实际入口完全一致。版本前提与安装说明提供了以下检查方式。
1. 确认你检查的是正在使用的客户端
CLI 用户在系统终端中检查版本：
codex --version低于 0.128.0 时，先更新原先使用的安装方式。通过 npm 安装的 CLI，官方示例是：
npm install -g @openai/codex@latest
codex --version通过 Homebrew cask 安装的，则使用对应方式：
brew update
brew upgrade --cask codex
codex --version选与你的原安装方式一致的一组即可。若你实际使用桌面应用或 IDE 扩展，终端中另一个 CLI 的版本不能证明那个客户端已经更新；还要检查该客户端的版本和命令列表。
2. 开启 features.goals
当前官方 Follow a goal明确给出了命令不显示时的处理方法：在 Codex 的 config.toml 中启用 Goals。
[features]
goals = true已有 [features] 时，把 goals = true 放进现有表中，不要再重复创建同名表。CLI 也提供了对应的启用命令，在系统终端中输入：
codex features enable goals这两种方式用于开启同一个功能，不必两种都做。这里不需要为了 Goals 另加 multi_agent = true，也不要把配置写进 config.yaml 或 settings.toml。开启后回到你正在用的 Codex 客户端，重新检查斜杠命令列表；仍不显示时，再核对当前会话是否读到了该配置。
3. 区分命令入口和系统终端
codex features enable goals 是终端命令；/goal 修复商品导入错误 则输入在Codex 的对话输入框中。不要在 shell 中直接运行 /goal ...，也不要拼成 codex /goal ...。
官方命令页当前也列出了桌面和 IDE 的 /goal 入口，但文档列出功能，不代表每个账户、安装包和版本都已在你的界面中可用。启用开关后仍没有入口时，保留客户端名称、版本、是否能看到其他斜杠命令，以及 Goals 配置；用这些信息继续定位，别直接把问题归结为提示词写得不好。
设置、查看、编辑、暂停、恢复和清除
支持 Goals 的客户端中，使用以下命令管理当前对话的目标。官方命令说明给出的操作包括：
| 要做的事 | 在 Codex 对话中输入 | 接下来确认什么 |
|---|---|---|
| 设置目标 | /goal <目标内容> | 当前目标记录是否包含你要完成的结果 |
| 查看目标 | /goal | 目标内容和当前状态是否仍符合本轮任务 |
| 修改目标 | /goal edit | 修改后的验收条件是否准确，再查看目标确认 |
| 暂停目标 | /goal pause | 目标进入暂停状态，等待你决定后续工作 |
| 恢复目标 | /goal resume | 恢复的是正确的目标，原有约束仍适用 |
| 移除目标 | /goal clear | 当前目标被移除，后续不再围绕它自动继续 |
目标内容必须非空，长度最多 4,000 个字符。详细需求太长时，可以放在项目中已有的需求文件里，让目标指向准确路径，并在短目标中保留核心结果与验收条件。这样既能控制目标长度，也方便检查细节是否发生变化。
第一次使用时，设置一个范围明确的小目标，再用 /goal 读回记录，比直接丢入整个项目的待办清单更容易检查。任务中途改变时，用 /goal edit 修订目标；不要只在普通消息里宣布一个新终点，却一直保留与之冲突的旧目标。
暂停与清除只控制目标的后续推进。它们不会撤销已经修改的文件，也不能追回已经发出的请求。需要保留当前工作、回退代码或处理外部操作时，要分别检查对应结果，不能把 /goal clear 当作撤销按钮。
一个能验收的目标：修复商品 CSV 导入
假设你的商品管理项目把货号 00127 导入成了 127，部分带逗号的商品名也被拆错了列。与其写“优化导入功能”，不如把目标落到实际行为和现有测试上。
下面假设项目已有 npm test -- <测试文件> 的运行方式；路径和测试脚本都只是示例前提。使用前替换成你项目里真实存在的文件和命令：
/goal 修复商品目录 CSV 导入，保留货号前导零，并正确读取带逗号或引号的商品名。
先阅读 src/catalog/import-csv.ts、tests/catalog/import-csv.test.ts 和 tests/fixtures/catalog/。
只修改导入实现、相关测试和测试样本，保持现有导入结果的字段名与返回类型。
补充回归测试，覆盖货号 00127、带逗号的商品名、字段内双引号，以及带 BOM 的 UTF-8 文件。
每次修改后运行 npm test -- tests/catalog/import-csv.test.ts，再运行项目原有的相关测试。
只有这些用例和原有相关测试均通过才算完成。交付改动文件、实际测试命令和结果、尚未覆盖的情况。
如果问题需要改变重复货号的处理规则，先说明冲突并等待产品决定；不要自行改变该规则。这个目标让 Codex 有足够空间调查原因，同时把终点固定下来。它可以先看解析库配置，也可以先追踪字段转换；但不能为了让测试通过，把货号字段改成数字，或者改变重复货号的业务规则。
可以把验收项进一步写成下面这样的输入输出对照，放进目标引用的需求文件中：
| 输入情形 | 应满足的结果 | 能证明什么 |
|---|---|---|
货号字段为 00127 | 导入后仍是字符串 00127 | 前导零被保留 |
商品名字段为 "杯子,蓝色" | 得到一个完整的商品名字段 | 引号内的逗号没有被当成分隔符 |
商品名字段为 "12"" 圆盘" | 字段值包含一个实际的双引号 | CSV 转义引号被正确解析 |
| 文件以 UTF-8 BOM 开头 | 首列表头正确识别，不夹带 BOM | 编码标记没有污染表头 |
这些是拟定的测试标准，不是已经通过的测试报告。最终仍要看项目中的测试是否实际执行、输出是否符合预期。只补一个“货号不为空”的断言，证明不了前导零是否保留；只测试普通商品名，也覆盖不了带逗号的字段。
如果你还不知道该改哪些文件，可以先让 Codex 检查失败用例和调用链，形成候选范围，再确认目标。目标里的路径应该帮助定位，不应迫使它无视已发现的真正原因；需要扩大范围时，先说明为什么原范围不足。
Codex 为什么会继续，什么时候会停
按 官方 Goals 机制说明，自动继续需要目标处于活动状态、预算允许，而且当前对话已经空闲。另一个回合还在运行、你有新消息等待处理，或对话还有未结束的工作时，不会简单地再启动一轮。
因此，/goal 不是一个固定周期的无限循环。官方还说明：仅做计划不会触发自动继续；中断会暂停目标；某次继续没有调用工具时，系统会抑制下一次自动继续，避免空转。这些行为说明了为什么“还没做完”不必然等于“马上又跑一轮”。
对长任务，重点看停止的原因，而不是只看它是否停止：
| 停止原因 | 你应如何理解 | 下一动作 |
|---|---|---|
| 目标已完成 | 应已有满足验收条件的结果 | 对照测试、文件或最终报告验收 |
| 你暂停或中断了目标 | 目标尚未必完成 | 查看当前进度，决定是否恢复 |
| 达到预算限制 | 本轮可用预算结束 | 核对已完成部分和剩余工作，再决定后续安排 |
| 缺少必要输入或遇到无法继续的阻碍 | 当前条件不足以达到目标 | 补充所需信息，或调整目标范围 |
| 目标被清除 | 持续目标记录已移除 | 如需新的任务，重新确定目标 |
例如，上面的 CSV 用例全部通过，但原有相关测试出现新的失败，目标仍未满足。反过来，已经查到问题原因却还没修复，也只能算调查取得进展。让 Codex 报告“哪些验收项有证据、哪些还没满足”，比只询问完成百分比更有用。
预算到了不等于完成，也不等于美元花费上限
Goal 的预算限制是继续工作的边界。官方要求预算达到限制后停止实质工作，说明进度、阻碍和下一步；不能因为预算用完就把目标标为成功。预算行为说明明确区分了这两件事。
还要区分三种看起来相似的要求：
- 目标指令：“同类失败尝试三次就停下来说明原因”，告诉 Codex 怎么安排工作。
- 客户端支持的目标预算：用于限制目标继续，并记录相关用量。
- 实际账单或套餐额度：由使用的计费账户、模型和用量规则决定。
写进目标的停止要求，并不会自动生成一个强制计费开关。当前这里引用的用户命令文档也没有提供 /goal budget 参数；不要根据 API 字段猜一个 CLI 命令。
如果担心长任务支出，先区分 ChatGPT 套餐用量与 API 按量计费，再设置适合自己的检查点。需要按模型和请求量估算费用时，参见 Codex CLI 长任务的每日 API 成本估算。Goal 的 Token 计数不能直接换算成确定的美元金额或订阅剩余任务数。
开发者接入：目标 API 和聊天命令的区别
自建 Codex 客户端时，官方 app-server 的目标管理接口提供 thread/goal/set、thread/goal/get 和 thread/goal/clear，管理与 TUI /goal 对应的持久目标。
其中 tokenBudget 是接口中的 Token 预算字段，tokensUsed 和 timeUsedSeconds 是用量记录。换成新目标会替换原目标并重置计数；使用当前尚未结束的目标内容，或省略 objective 来更新状态、预算时，会保留用量历史。接入方要先分清“开始另一件事”和“调整同一件事”，否则显示出来的进度可能失去原来的累计口径。
这些是开发者接口，不是需要粘贴到终端的斜杠命令。普通用户按前面的功能开关和对话命令使用 Goals，不需要先启动 app-server。
已有命令，但设置或读取目标失败怎么办
“找不到 /goal”和“命令存在但设置失败”需要分开处理。前者先检查版本、入口和 features.goals；后者不能只凭一句失败提示就断定是功能开关问题。
可以先整理下面几项信息：
- 客户端与版本：错误发生在 CLI、桌面应用、IDE，还是自建接入中？
- 失败动作：是新建目标、编辑现有目标，还是用
/goal读取？保留准确错误文字。 - 目标内容：是否非空、是否超过 4,000 个字符？这是官方明确要求，可先排除。
- 当前对话状态：已有目标吗？查看和编辑是否发生在同一个对话中？
- 相关日志：保留时间与涉及目标操作的片段，分享前去掉凭证、私人路径和私有目标内容。
能查看目标、但编辑失败时，先保留原目标及错误，不要急着清除；清除可能让你丢掉继续定位所需的状态。只在某个客户端失败时，也不要把另一个客户端成功读取当成问题已解决。以上是用于缩小排查范围的检查，不是对所有错误根因的统一诊断。
常见问题
Codex goal 模式怎么开启？
在支持 Goals 的版本中，命令不显示时，按官方方法在 config.toml 的 [features] 中加入 goals = true，或在终端运行 codex features enable goals。然后回到当前客户端检查 /goal 入口。版本、客户端及配置读取仍需要对应核对，开启开关不保证所有界面故障都会消失。依据：官方开启方法。
/goal edit 可以修改正在做的目标吗？
当前官方命令文档提供 /goal edit 用于修订目标。修改后再用 /goal 确认记录与新的要求一致。如果只是补充一个约束，说明它如何影响已有结果；如果任务方向已经改变，重新明确验收标准。依据：目标命令说明。
/goal 和计划模式有什么区别？
计划用于确定怎么做；Goal 把要达到的结果保存在当前对话中，支持围绕它继续工作。问题还不清楚时先规划，目标和验收方式明确后再设置 Goal。官方说明仅做计划不会触发目标自动继续。依据：Goals 的继续机制。
可以让 Codex 一直运行到第二天吗？
Goals 能用于需要多轮推进的长任务，但不能承诺固定运行一整晚。暂停、中断、预算限制、缺少输入等都可能让工作停止；本地电脑关机也不能凭 Goal 推断任务会在云端接着跑。先定义能检查的结果、可用资源和停止条件，再按实际状态决定是否继续。依据：官方生命周期说明。
清除目标会回退代码吗？
不会。/goal clear 用于移除当前目标，代码和其他已发生的操作要分别检查。想恢复到修改前的状态，需要查看实际差异并使用项目的版本管理流程；不要把“没有目标了”理解成“工作没有发生”。依据：目标管理命令。
