让 Codex 做一个要跑很多轮的活，比如把老 React 项目里二十多个类组件全部改成函数组件加 hooks，很容易遇到这种情况：前几轮规规矩矩，改完两三个文件；到第七八轮，它开始"顺手优化"，把组件里的请求逻辑重构成另一套库，理由是更现代。等你发现时，改动已经超出范围，token 也烧了不少。
问题往往不在提示词写得不够清楚，而在于把一个多轮的长任务当成了单轮指令。约束只在第一轮说过一次，越往后，模型越容易偏离最初的要求。
Codex 有一个专门处理这种情况的斜杠命令：/goal。它给当前会话设一个贯穿全程的目标，Codex 后面每一轮都会带着这个目标继续推进，直到确认真正完成。
/goal 和普通提示词有什么不同
普通提示词只作用于当前这一轮。/goal 设下的目标会在会话里持续存在：每一轮结束后，只要目标还处于进行中，Codex 就会接着朝它推进，而不是停下来等你下一条指令。
按照 OpenAI 的 Codex 文档，目标适合用在"会跨越多轮、需要一个持久目标"的任务上，比如大型重构、跨多个文件的修复、迁移类工作。目标内容不能为空，最长 4,000 个字符。说明比较长的话，可以把详细要求写进一个文件，让目标指向这个文件。
6 个用法一次看全
/goal 的用法都很直观。
设定目标：在命令后面直接写目标描述。
/goal 把 src/components 下所有类组件改成函数组件加 hooks，保留现有 props 接口，不引入新依赖
查看目标：单独输入 /goal，不带参数，会显示当前目标的内容和状态。
/goal
修改目标：跑到一半发现要求需要调整，用 edit 改，不用清掉重来。
/goal edit
暂停和恢复：临时要切去处理别的事，先暂停，回来再恢复。
/goal pause
/goal resume
清除目标：任务结束或者目标不再需要时清掉。
/goal clear
上图展示了设定、查看、暂停、恢复、清除这条主线，另外还有上面提到的 /goal edit。如果用的是 Codex 桌面端，目标激活后输入框上方会出现一行进度条，暂停、恢复、编辑和清除都可以直接在那里点。
它靠什么把目标钉住
Codex 是开源的，/goal 的实现可以直接在 openai/codex 仓库里看到。仓库里有三个提示模板，对应三种时机。
continuation（持续推进）：每一轮继续时，Codex 会把目标原文连同一段行为要求一起放进上下文。核心意思是：目标跨轮持续存在，这一轮结束不代表要把目标缩小成这一轮能做完的部分；要保持完整目标，朝真正要求的最终状态推进，不能换成一个更小、更容易通过测试的方案。
这段模板里还有一个"完成审计"：在宣布完成之前，要把目标拆成具体要求，逐条找到能证明完成的证据，比如文件、命令输出、测试结果。证据不充分就继续做，不能凭"看起来差不多了"就收工。
objective_updated（目标被修改）：你用 /goal edit 改了目标后，Codex 会收到提示：新目标取代旧目标，当前这一轮要按新目标调整，只对旧目标有用的工作不要继续做。
budget_limit（预算用完）：如果目标设置了 token 预算并且已经用满，Codex 会被要求不再开始新的实质性工作，把这一轮收个尾：总结已有进展，说明剩余工作或阻碍，给你一个明确的下一步。
目标有哪几种状态
在 Codex 的协议定义里，目标一共有 6 种状态：
| 状态 | 含义 |
|---|---|
| active | 进行中，Codex 会持续推进 |
| paused | 已暂停，由你用 /goal pause 触发 |
| blocked | 卡住，需要你介入或外部条件变化 |
| usageLimited | 触及使用额度限制 |
| budgetLimited | 用满了为这个目标设置的 token 预算 |
| complete | 已完成，并通过了完成审计 |
其中"卡住"的判断很克制。模板要求：第一次遇到阻碍时不能直接标记 blocked；只有同一个阻碍条件在连续至少 3 轮里重复出现，并且确实没法在没有用户输入的情况下推进，才能标记为卡住。任务难、慢、不确定，都不算卡住的理由。暂停也只能由你主动要求，Codex 不会自己暂停。
关于 token 预算：目标数据里本身带有预算和已用 token 的字段，但 Codex 里名为 token_budget 的功能开关目前仍处于开发阶段，默认关闭。/goal 本身已经是稳定功能并默认开启，日常使用不依赖预算设置。可以用下面的命令查看当前版本里各项功能的阶段和开关状态：
codex features list
写好一个目标的几个要点
/goal 能不能发挥作用，很大程度取决于目标本身写得怎么样。下面几个场景可以直接参考。
大型重构：写清楚范围和不能动的东西。
/goal 把 src/components 下所有 React 类组件改成函数组件加 hooks，保留现有 props 接口和测试覆盖率，不引入新依赖
跨文件修复：写明兼容性约束和验收标准。
/goal 修复登录态丢失问题，保持现有 /api/v1 接口完全兼容，所有受影响的单元测试必须通过
迁移任务：写明哪些接口必须保持不变、用什么来验证。
/goal 把 services/auth 从 Python 迁移到 Go，保持现有 gRPC 接口签名不变，新代码通过现有集成测试
三个例子有一个共同点：都写了"什么算完成"。前面说过，Codex 宣布完成前要逐条拿证据，验收标准写得越具体，它越有据可查，也越不容易提前收工或者越做越多。
先 /plan，再 /goal
官方文档给的建议顺序是：任务比较复杂时，先用 /plan 让 Codex 出一份执行方案，你确认方案没问题后，再用 /goal 把目标设下去。/plan 负责把路想清楚，/goal 负责把路走完。
如果项目里还有长期有效的规范，比如代码风格、目录约定、禁止使用的依赖，更适合写进 AGENTS.md，而不是每次都塞进目标里。两者分工可以这样理解：AGENTS.md 是项目级的长期规则，/goal 是这一次会话要完成的具体任务。AGENTS.md 的写法可以看这篇 AGENTS.md，把项目规范写给 Codex。
什么时候值得用
- 预计要跑 5 轮以上的任务，开局先设目标，能明显减少中途跑偏；
- 有明确验收标准的任务，比如"测试全部通过""接口签名不变"，最适合交给目标去盯；
- 一两轮就能做完的小改动，直接写提示词就够了，没必要设目标。
如果你还没把 Codex CLI 接好，可以先按 Codex CLI 接入 AIGoCode 后，怎样确认配置真的生效 把配置核对一遍，再到 AIGoCode 模型页 查看 ChatGPT / Codex 分组下当前可用的模型。下一个长任务，可以从一句 /goal 开始。