Codex /goal 在 0.128.0 版本线里是真实功能，但在使用前必须先确认你本机安装的 CLI 版本和当前界面是否真的暴露了这个命令。
截至 2026 年 5 月 4 日，OpenAI 公开的 CLI slash command 文档仍未列出 /goal；更强的可用性证据来自 0.128.0 release/source tree，以及标为 experimental 的 app-server goal API。
只有当目标可以写成交付物、文件范围、测试、预算和停止规则时，才适合使用 /goal；如果命令缺失，或目标还不能被审计，先用 /plan 拆清楚再继续。
快速判断：/goal 是真实功能，但不是所有界面都能直接用
/goal 不等于一段更长的提示词。它的用途是把一个长期目标固定在 Codex 线程里，让 Codex 在多轮执行、继续、暂停、预算限制和完成判断中都能围绕同一个目标工作。OpenAI Codex 的 0.128.0 release 提到 persisted /goal workflows，并把它和 app-server APIs、model tools、runtime continuation、TUI controls 联系在一起。
真正需要小心的是“功能存在”和“你现在能用”之间的差距。2026 年 5 月 4 日核对时，OpenAI Developers 的 CLI slash-command 页面 仍然列出 /plan、/status、/resume、/compact、/ps、/stop 等命令，却没有列出 /goal。IDE slash-command 页面 也没有把 /goal 当作 IDE 命令说明。结论不是“功能不存在”，而是：release/source、公开文档、本地 CLI 和不同 Codex 界面可能不同步。
先用这张表判断下一步：
| 你看到的情况 | 更可能的含义 | 下一步 |
|---|---|---|
codex --version 是 0.128.0 或更新，并且 CLI 命令面板能看到 /goal | 可以测试 goal workflow | 用一个小而可审计的目标开始 |
| 本地 Codex 低于 0.128.0 | 当前二进制可能不包含 /goal | 先更新，再重新检查命令面板 |
公开文档没写 /goal，但本地 CLI 有 | 文档滞后于 release/source 证据 | 可以使用，但所有可用性表述都要带日期 |
IDE、桌面应用或其他入口看不到 /goal | 该界面可能还没有同样的 slash command | 不要把 CLI 行为直接套到所有入口 |
| 目标无法写成范围、测试、证据和停止规则 | 目标还不适合持久运行 | 先用 /plan 或普通对话收敛需求 |
本次源研究中，本机 codex --version 返回的是 codex-cli 0.125.0，所以不能用本机直接证明 /goal 可用。这正是很多开发者会遇到的情况：功能已经进入新版本线，但终端里的旧安装还没有跟上。
0.128.0 证据说明 /goal 到底做什么
目前最可靠的用户侧最小语法是：
text/goal <objective>
0.128.0 的 slash command source 把 Goal 描述为“set or view the goal for a long-running task”。源码还显示它支持 inline args，并且在任务运行期间也可用。另一个 TUI action source 显示，在没有当前目标且没有传入目标文本时，界面会返回 Usage: /goal <objective>。
这意味着不要自己发明命令语法。不要假设 /goal set、/goal audit、/goal complete 这类形式存在，除非你的安装版本明确展示了这些命令。0.128.0 证据支持的是 /goal <objective> 这个最小形态，以及背后由 Codex 管理的 goal lifecycle。
从运行机制看，/goal 更像一个“持久任务合同”，而不是“请继续”的另一种说法。它把几个能力组合起来：
- 线程里存有一个当前目标。
- runtime continuation 可以围绕这个目标继续推进。
- token 和 wall-clock accounting 会参与预算判断。
- 达到预算限制时，系统应该收尾，而不是开启新的实质工作。
- app-server 里存在
thread/goal/set、thread/goal/get、thread/goal/clear。 - TUI 层有 create、pause、resume、clear 等状态控制。
更重要的是，continuation template 会把 objective 当作不可信用户数据处理，并要求 Codex 在宣布完成前检查真实交付物。budget-limit template 则要求在预算触顶时 wrap up。换句话说，/goal 的安全边界不是“自动完成一切”，而是“围绕一个目标持续工作，同时保留预算、证据和停止状态”。
为什么你的 Codex 看不到 /goal
缺失命令时，第一反应不该是换提示词，而是确认版本和界面。
bashcodex --version
如果版本低于 codex-cli 0.128.0，先不要纠结写法。旧安装很可能没有这条命令。更新后重新打开终端或 Codex 会话，再看 slash command 列表。
第二步是看当前界面暴露了什么。CLI、IDE、桌面应用、app-server integration 不是同一个东西。公开文档可以帮助判断趋势，但真正决定你能不能输入命令的是当前运行中的命令面板。
第三步是把 CLI slash command 和 app-server API 分开。app-server API overview 里有 thread/goal/set、thread/goal/get、thread/goal/clear，并且标在 capabilities.experimentalApi 后面。这说明 goal 是真实的 thread concept，但不代表普通用户应该绕过 CLI 去依赖 experimental API。
可以按这个顺序排查：
- 运行
codex --version。 - 进入 CLI 会话，打开 slash command 列表，看有没有
/goal。 - 确认你使用的是 CLI、IDE、桌面应用，还是 app-server 集成。
- 如果没有
/goal，先用/plan把目标拆到可审计，再更新或换回 CLI 检查。 - 如果团队要接 app-server goal API，先检查 experimental capability，不要把它当作稳定用户命令。
正确结论是“当前界面尚未确认”，不是“这个功能一定是假消息”。
目标应该怎么写才适合 /goal
/goal 能否帮上忙，取决于 objective 是否可以审计。模糊目标会让 agent 一直忙，但你很难判断它有没有做对。一个合格的目标至少要说明结果、文件范围、验证命令、证据和停止条件。
推荐结构如下：
text/goal 在 <文件或模块> 中完成 <具体结果>。 验收标准： - 用户可见行为：<必须改变什么> - 文件范围：<允许编辑哪些路径> - 验证方式：<测试、截图、日志、命令或人工检查> - 需要汇报的证据：<diff、测试输出、风险、未完成项> - 停止规则：<预算、缺少凭证、依赖失败、产品决策不清>
不适合的目标是：
text/goal 优化后台
更可用的目标是：
text/goal 给 billing usage table 增加 CSV 导出。 验收标准： - 导出按钮放在现有筛选器旁边。 - 只修改 app/billing 和共享 CSV 工具。 - CSV 包含 account id、period、model、tokens、cost、status。 - 运行 npm test -- billing 和 npm run lint。 - 如果 billing API 不返回原始行数据，停止并说明缺口。
第二种写法让 Codex 知道什么可以做、什么不能猜，也让你知道该看哪些证据。目标还写不到这个粒度时，先用 /plan。如果你的问题其实是登录路线、API key、订阅或账单归属，先看 Codex API Key 和 ChatGPT 订阅怎么选。如果担心长任务消耗和额度，配合 OpenAI Codex 用量限制指南。如果是在调本地配置，再看 Codex config.toml 指南。
长任务的安全使用流程
一个稳妥流程是：先计划，再设目标，再监控，再验证，最后清除或继续。不同 Codex 入口的按钮可能不同，但安全模型不应该变。
| 阶段 | 应做什么 | 需要留下的证据 |
|---|---|---|
| 计划 | 把需求转成文件范围、验收标准、验证和停止规则 | objective 文本和范围说明 |
| 设定 | 只有目标可审计后才运行 /goal <objective> | 版本、命令面板和目标记录 |
| 监控 | 观察 active、paused、resumed、budget-limited 等状态 | 进度说明、文件变更、命令输出 |
| 验证 | 按交付物逐项对照，而不是看 agent 说没说完成 | 测试、截图、日志、diff summary |
| 清除或继续 | 完成后清除目标；未完成时改写目标再继续 | 剩余风险和下一步 |
最危险的失败模式是“看起来跑了很久，所以应该完成了”。接受结果前，至少做一次完成审计：
- 改动文件是否仍在声明范围内？
- 承诺的测试是否运行，失败时是否解释原因？
- 结果是否有真实 artifact，而不只是文字总结？
- 是否避免了无关重构和隐藏产品决策？
- budget-limited 状态是否只做收尾，而不是继续开新任务？
- 继续执行是否有明确理由，还是应该清除目标？
任何一项答不上来，都不要把目标视为完成。/goal 的价值是让长任务更连续，不是降低验收标准。
什么时候不要用 /goal
问题还不清楚时，不要把 /goal 当第一步。它不适合开放式头脑风暴、不熟悉代码库且没有成功标准的探索、需要生产权限但尚未授权的操作，或无法预算的长时间执行。
避免在这些场景使用：
- 目标需要凭证、线上权限或策略决策，但这些边界还没确认。
- 任务跨越太多模块，review 成本已经不可控。
- 你说不出停止条件。
- 你自己也不知道怎样判断完成。
- 你试图用更长运行时间补偿一个模糊提示词。
小任务用普通提示就够。需要拆解时先用 /plan。只想延续上下文时看 /resume 或 /compact。/goal 最适合“足够大，需要连续推进；又足够具体，可以验证完成”的工作。
如果你还在比较不同 coding agent 的工作方式，可以看 Claude Code vs Codex。这里真正的分界不是谁更像“自动驾驶”，而是谁能把最终状态和验收标准对齐。
常见问题
Codex /goal 现在算正式可用吗？
它在 2026 年 5 月 4 日核对的 0.128.0 release/source 证据中存在。但公开 CLI/IDE slash-command 文档仍有滞后，所以必须先检查本机版本和命令面板。
/goal 的语法是什么？
当前可靠的最小形态是 /goal <objective>。不要假设额外子命令，除非你的安装版本明确展示。
为什么我的 CLI 没有 /goal？
常见原因是版本低于 0.128.0、当前界面不支持、或公开文档/命令发现滞后。先查 codex --version，再检查 CLI 内的 slash command 列表。
/goal 和 /plan 一样吗？
不一样。/plan 用来把问题拆清楚，/goal 应该在目标已经可以持久化、继续执行并审计时使用。
可以让 /goal 无人值守跑一整晚吗？
不要默认这样做。必须有预算限制、验收标准、文件范围和可回看的证据。达到预算限制后的收尾，不等于成功完成。
要不要直接使用 app-server goal API？
只有在你明确构建 experimental app-server integration，并且确认 capabilities.experimentalApi 时才考虑。普通使用者应先从 CLI 命令面板确认，而不是绕到低层 API。