如果你总是在对 Codex 说“继续”，可以使用/goal保留完成条件。它适合先复现错误、再修复，并根据测试结果决定下一步的任务。这不只是一条要求长时间运行的指令：它会在同一个聊天中保留何时算完成的条件。

本文介绍适用场景、桌面应用与 CLI 的操作差异，以及工作停止后的排查顺序。同时说明为什么目标的 token 预算不能等同于套餐剩余额度或账单上限。

先确定这三件事

成果

要修复什么错误，或要做出什么

约束

可以改什么、必须保留哪些行为，以及允许执行哪些操作

验证

用哪些测试或实测结果判断工作已完成

规格核查日期：2026年10月7日。本文依据 OpenAI 官方文档说明。我们没有为本文运行 Goal mode，也没有实测持续时间、消耗量或它对成果的影响。

1. /goal 的作用：普通请求、/plan 与 dot

/goal会在 Codex 聊天中设置一个持续推进的目标。即使中途测试失败，Codex 也可以依据原来的完成条件选择下一项工作。OpenAI 列举了错误调查、性能优化、迁移和资料研究等用途；这些任务的下一步会随调查结果而变化。

围绕目标反复执行与验证

  1. 执行：查看代码或资料，修改并测量
  2. 核对：判断是否有证据表明已达成目标
  3. 决定：达成则完成，未达成则继续下一步，无法推进则说明原因

未完成的工作会在目标有效、预算未耗尽且满足自动继续条件时继续进行。

官方将目标描述为保存在当前聊天中的状态。它不是自动应用到其他聊天的全局记忆，也不是整个代码仓库的规则。所需代码、测试和文档仍须能从这个聊天访问。来源：OpenAI Cookbook：Using Goals in Codex。

方式适合的请求何时使用
普通请求单项修改、解释或简短核查希望通过一次请求获得结果时
/plan梳理要做什么、要修改多大范围目标还模糊，需要确定需求和验证条件时
/goal反复调查、修改和验证，直到满足完成条件终点明确，但还不知道具体步骤时
dot持续协助、委派开发代理与协调进度希望把多个任务的协调工作也交出去时

仅仅制定计划不会启动 Goal mode 的自动继续。/goal也不保证一定由另一个模型进行独立审查。与 dot 的区别可参考dot 的用法、费用与向 Codex 委派工作；如何提供信息可参考上下文工程。

2. 在桌面应用、CLI 和 IDE 中开始

虽然都使用/goal，但开始后的操作随界面而异。官方长时间工作指南介绍了桌面应用、CLI 和 IDE 扩展的启动方法。其网页部分说明的是如何向 ChatGPT Work 提供成果、约束和评估条件，不能据此认定网页也有相同的命令和操作。

桌面应用

  1. 打开相关项目和聊天
  2. 在输入框使用/goal并说明完成条件
  3. 查看输入框上方的目标进度行

通过这条进度行暂停、恢复、编辑或清除目标。

Codex CLI

  1. 在相关工作目录打开交互会话
  2. 输入/goal，随后写明目标
  3. 在同一会话中询问进度或提出修改指示

查询状态或暂停目标时，使用下文的 CLI 命令。

IDE 扩展

  1. 打开相关工作区
  2. 在扩展的聊天中使用/goal
  3. 在同一个聊天中提供补充信息

工作期间应让工作区保持可访问。

对于 CLI，OpenAI Cookbook 将 Codex 0.128.0 及以上列为支持版本。当前配置参考将features.goals描述为稳定且默认启用的功能。不要认为仍须把以前开启实验功能的步骤加入配置。如果找不到功能，请核对所用界面、版本和当前官方说明。

来源：长时间工作、桌面应用的斜杠命令和配置参考。本文的操作说明用于解释功能含义，并不是经过各版本实机核验的按钮名称清单。

3. 定义完成条件：让模糊目标可以验证

只说“做得高质量一点”或“一直做到完成”，很难判断何时算完成。完成条件应该描述可以验证的结果，例如界面宽度、保存后的行为、测试结果或要比较的资料。

难以判断的请求

“把这个待办应用改好，一直做到完成。”

外观、涉及的功能、检查方法和停止条件都没有确定。

结果可以核验的请求

“把一条已删除项目恢复到原位置和原完成状态。检查恢复后的持久保存，防止重复恢复，并提交结果。”

将所需行为与能够证明成功的证据对应起来。

在 CLI 中，目标文本必须非空，且不超过4,000个字符。与其塞入整份长规格，不如指定规格文件，并在目标中保留成果、关键约束和验证条件。提供文件不意味着会自动继承另一个聊天的历史。来源：Codex CLI 的斜杠命令。

如果规格尚未确定，可以先请求：“暂时不要实现，先梳理需求并拟一份/goal。”通过/plan讨论后，自己阅读提出的目标，检查约束与范围，再开始执行。

4. 修复错误、改善界面和资料调查的请求示例

以下请求是为本文编写的，不是我们已执行的成功案例。先确认能否使用测试和浏览器，并要求将无法执行的检查报告为未执行。

修复错误：区分已复现的问题与回归检查

/goal 修复这个待办应用的“撤销删除”，使最近删除的一条项目能够恢复到原位置和原完成状态。
保留现有的新增、切换完成状态、删除和保存行为。
先复现问题。修复后检查恢复位置、完成状态、防止重复恢复、连续删除以及恢复后的持久保存。
只修改相关文件和测试。不要引入依赖、对外发布、执行 push 或购买。
如果无法检查，请报告原因及所需环境。完成报告须列出修改的文件、执行的命令与结果，以及未执行的检查。

只要求“通过测试”，可能让删除功能的改动看起来也达成目标。同时写明必须保留的行为和允许修改的范围，就能为选择修复方法提供依据。

改善界面：指定显示与操作条件

/goal 让这个界面在390px和1280px宽度下没有横向溢出，任务名称很长时仍能使用完成和删除按钮。
不要改变现有数据结构和存储格式。
在可用的真实浏览器中检查两种宽度，测试新增、切换完成状态、删除、重新加载后的持久保存和键盘操作。
如果无法进行浏览器检查，不要用图片或代码检查代替真实操作并判为通过。将这些检查报告为未执行。
不要发布、执行 push、购买或更改设备设置。

这些宽度是本次请求的检查条件，不是产品保证支持的屏幕宽度。还应区分真实浏览器操作的结果与仅查看代码或图片得出的结果。

资料调查：保留依据，不要猜填未知项目

/goal 根据公开的官方文档，比较指定的两个服务的数据保留、训练使用和删除条件。
为每项主张对应来源 URL 和所核查原文中的条件，并制作比较表和说明。
对搜索后仍找不到说明的项目，列出查阅的资料和缺失的信息。不要凭猜测填表。
不要登录、更改设置、连接应用、上传或购买。
结束时分别提交已确认的规格、解释，以及调查后仍未能确认的项目。

如果决定“直到找到所有答案才停止，无限继续”，调查就会失去终点。即使信息未公开，也可以将说明查阅范围和遗留疑问的报告定义为成果。

5. 暂停、恢复、编辑和清除目标

在桌面应用中，使用输入框上方的目标进度行。CLI 文档列出了以下命令。不要将这张 CLI 表直接理解成桌面应用的按钮操作清单。

在 CLI 中输入用途应核对的事项
/goal显示当前目标是否对应本次工作的完成条件？
/goal edit编辑目标新条件是否需要重新验证？
/goal pause暂停有效目标核对暂停后的状态
/goal resume恢复已暂停的目标工作环境或约束是否改变？
/goal clear清除当前目标避免把旧完成条件带到下一项工作

工作进行中，也可以在同一个聊天补充信息或约束。改变决定时要明确说明，例如“暂时不要发布”或“取消对这项功能的修改”。编辑目标后，还要确认原有测试结果是否足以证明满足新的完成条件。

暂停或清除不会撤销已经做出的修改

如需恢复代码或保存的数据，请另外检查差异和保存状态。CLI 命令/stop用于停止后台终端，不是/goal pause的别名。

操作依据：CLI 的目标命令与桌面应用的目标操作。

6. token 预算、使用额度与费用

对于持续工作，应区分何时停止目标工作与会消耗多少套餐额度。即使目标预算还有剩余，账户使用上限或执行环境问题也可能使工作无法继续。

项目管理的内容不能等同于
目标的 token 预算管理为该目标继续工作的预算和使用量套餐剩余额度或严格的账单上限
套餐使用额度与 credits用于 Work、Codex 等服务处理的共享额度和追加余额专属于某个目标的预算
上下文容量模型能够处理的上下文量持续工作全程的 token 总量或月费

使用 /goal 会额外收费吗？

在此次核查的官方费用资料中，我们没有找到每次启动/goal的单独费用。但反复进行模型处理会消耗普通 Codex 使用额度。开启 Goal mode 并不意味着测试、修复、核对的循环变成免费且无限。

OpenAI 说明 Work 与 Codex 共享使用额度，消耗量会随模型、任务等因素变化。用完套餐额度后使用追加 credits 继续，也应与使用 API 密钥单独计费区分。来源：Work、Codex 的费用与使用上限。套餐选择与重置可参考ChatGPT Pro 费用与使用额度比较。

预算数值能证明什么？

官方面向开发者的 App Server 文档列出了目标的tokenBudget、使用量字段tokensUsed和时间计量字段timeUsedSeconds。这可以确认存在在内部目标状态中记录预算与进度的机制，但不是要求将这些 RPC 字段名直接作为面向用户的 CLI 参数输入。

已调查但未能从官方说明中确定的问题
  • 普通用户设置预算的语法，以及在各界面的输入方式
  • 目标计数器的详细计算方式，包括缓存输入与委派工作
  • 预算边界的超出量及其与最终账单的精确关系

因此，我们不提供未经核实的命令，也不保证设置预算就能把账单控制在某个金额之下。

同一份文档说明，以新目标替换旧目标会重置目标使用量记录。这不意味着套餐剩余额度会恢复。存在时间计量字段，也不能证明能保证两小时后停止。来源：App Server 的目标管理。

7. 工作中途停止时的排查顺序

目标有效不意味着它能自动跨过所有中断。先核对当前目标和最后一次结果，再依次排查。

① 目标状态

是已完成、暂停、清除，还是达到预算上限？如果已完成，请检查满足完成条件的证据。

② 等待用户输入或决定

是否正在等待批准或必要信息？如果有补充消息待处理，可能需要先处理它。

③ 预算、套餐额度与模型

分别检查目标预算上限、套餐使用上限和所选模型的错误。

④ 执行环境

所需文件、依赖、测试工具和连接是否可用？如果在本地电脑工作，还要确认电脑正在运行。

根据 Cookbook，自动继续需要聊天处于空闲状态、目标有效且预算未耗尽，同时没有其他待处理任务或用户输入。仅规划的工作不会触发继续，中断会暂停目标。如果某次继续回合没有调用任何工具，下一次自动继续会被抑制，以避免无效重复。

达到预算时，官方设计会停止实质性工作，并报告进度、障碍和下一步。耗尽预算与达成目标是两回事。恢复前请核对剩余工作和预计费用。

启动/goal不会扩大权限或增加连接资源。官方资料说明它遵循现有沙盒与批准策略，也不会自动将本地工作转移到云端。如果预计会失去连接，官方建议暂停，并在环境可用时恢复。来源：长时间工作的权限与继续条件。

如果出现“Selected model is at capacity”之类的模型端错误，应按消息内容排查。Codex 的 at capacity 错误调查与处理对它与使用上限作了分别说明。

8. 完成报告中应核对的证据

一句“完成了”不能证明要求的结果已经验证。应寻找与最初目标对应的证据。即使测试通过，未执行的操作检查也不能被视为通过。

完成条件应收到的证据不充分报告的例子
错误已修复复现条件、修改差异，以及修复后相同条件下的结果没有复现问题，只修改了可疑代码
现有行为已保留相关回归测试的命令与结果只检查新功能，没有检查原有保存行为
界面与操作可用指定宽度下的真实操作，包括输入与重新加载仅凭图片就将保存和按钮操作判为通过
有依据的调查已完成主张与原文的对应关系、条件和遗留问题只有链接清单，没有说明确认了什么

如果缺少证据，在同一个聊天给出具体后续请求，例如“检查重新加载后的持久保存”或“提供这项主张的原文与条件”。增加完成条件时，也要更新目标。如果希望另一个代理核查工作，请另外明确提出，并区分只阅读代理报告的审查与实际重新执行的检查。

普通 Codex 开发也可以要求梳理需求、实现和验证。Goal mode 的价值在于跨多个步骤保留完成条件，并据此选择下一步。产品与执行方式的差异可参考Claude Code 与 Codex 的比较。

9. 开始前的检查

  • 在目标文本中写入成果、约束和验证
  • 让执行工作的聊天能访问所需文件与检查环境
  • 桌面应用通过进度行管理目标，CLI 使用目标命令
  • 分开核对目标预算与套餐使用额度
  • 将完成报告与测试、差异、真实操作和来源进行核对

如果一次修改或解释就足够，普通请求更合适。如果下一步取决于调查结果，需要向同一完成条件反复推进，可以考虑/goal。应以可验证的成果为依据选择，而不是看运行了多久。

10. 常见问题

可以不用每次都说“继续”吗？

目标有效且符合自动继续条件时，一个回合结束后可以推进到下一步。但仍可能因等待批准、预算上限或障碍而停止。它不会消除人类决策的必要性。

/goal 只能在云端用吗？关闭电脑后还会运行吗？

它并非云端专用。文档介绍了桌面应用、Codex CLI 和 IDE 扩展的用法。继续工作所需环境取决于执行位置，仅设置目标不能证明任务会在已关机的本地电脑上继续运行。

token 预算能保证费用上限吗？

不能将其保证为严格的账单上限。目标预算与套餐额度、追加 credits、API 计费不同。在此次核查的官方资料中，我们没有找到目标计数器与计费金额精确对应关系的说明。

和使用 dot 一样吗？

/goal管理同一个 Codex 聊天内的目标与持续工作。dot 还处理持续协助、向其他任务委派和协调。小型开发任务直接请求 Codex 也可能足够。应根据目的以及希望由谁管理进度来选择。