# 🚀开发者必看！Codex /goal命令高级技巧保姆级教程：Plan模式+Spec-Driven+自研Skill 三大技巧组合让效率倍增
作者：AI超元域
AI超元域万粉 up 主，擅长大模型微调、RAG、AI 应用开发。
`/goal` 是 OpenAI 在 Codex CLI 0.128.0（2026 年 4 月 30 日发布）中新增的一条命令。它不是又一个普通的提示词模板，而是 Codex 内部新增了一整套目标生命周期管理机制：给一个目标，Codex 会自己一轮接一轮往下推进，真正实现无人值守。社区里已经出现连续运行 21 小时、烧掉 9 亿 token 的案例。这篇笔记把我自己踩过的坑、固定下来的工作流、配套的 Skill 全都整理成保姆级教程。
本篇笔记所对应的视频：
👉👉👉 通过哔哩哔哩观看
## 一、/goal 是什么，以及它为什么重要
`/goal` 是 OpenAI 在 Codex CLI 0.128.0（2026 年 4 月 30 日发布）中新增的一条命令。官方更新日志的原话是：
> Added persisted /goal workflows with app-server APIs, model tools, runtime continuation, and TUI controls for create, pause, resume, and clear.
翻译成大白话就是：`/goal` 不是又一个普通的提示词模板，而是 Codex 内部新增了一整套目标生命周期管理机制。它由四个层面共同构成：
1. 持久化层：把目标作为一个独立于对话历史的状态存起来，带状态机（active / paused / achieved / unmet / budget_limited）
2. App-server RPC：`thread/goal/{get, set, clear}` 三个接口，让客户端可以读写目标状态
3. 模型工具：`get_goal`、`create_goal`、`update_goal` 三个工具，让模型可以查询和声明完成，但不能自己暂停、清空或篡改
4. 运行时延续（continuation）+ TUI：每一轮空闲时，Codex 会自动注入一段“延续提示词”让模型决定下一步，直到目标达成、被暂停、被清空或者烧到 token 上限才停
这套机制最直观的效果就是：给一个目标，Codex 会自己一轮接一轮往下推进，真正实现无人值守。社区里已经出现连续运行 21 小时、烧掉 9 亿 token 的案例；我自己测试中也跑过几个小时不间断的批量重构任务。
如果你之前听说过 Ralph Loop（用脚本反复让 agent 跑同一个目标的工作流），`/goal` 就是 OpenAI 把它做进了 Codex 内核里。OpenAI 总裁 Greg Brockman 在 X 上的原话是：“codex now has a built in Ralph loop++”。比起外部脚本驱动的 Ralph Loop，内置版本的优势在于：目标可以跨会话恢复、token 预算是一等公民、暂停/恢复是原生命令，而且不需要每轮重建上下文，产出质量明显更稳。
## 二、/goal 解决了哪些以前解决不了的问题
理解 `/goal` 价值的关键，是它到底解决了什么以前没办法解决的问题。我归纳为四点。
### 1. 目标本身的持久化
普通 prompt 是写在 Codex 的对话流里的。一旦上下文超过阈值触发 `/compact`，或者你切换会话，prompt 就可能被压缩、被覆盖、被丢失。`/goal` 不一样，它把“目标”作为独立的 thread 状态存起来，跟对话历史是两回事。所以：
- `/compact` 压缩对话历史，不会破坏 goal 状态
- 关掉终端，下次 `codex resume <id>` 还能续上之前的 goal
- 多天跨度的长任务也能撑住
注意一个已知问题：Issue #19910 报告，如果 `/compact` 发生在一轮模型调用执行的中间，延续提示词不会被重新注入，下一个 agent 可能丢掉目标和审计要求。如果你计划做超长任务，尽量让自动 compaction 落在轮次边界而不是手动压缩。
### 2. 内置的“完成审计”
这是 `/goal` 最低估的部分，但也是最关键的部分。
每一轮空闲后，Codex 会自动向模型注入一段叫 `continuation.md` 的提示词（源码在 `codex-rs/core/templates/goals/continuation.md`）。这段提示词的核心要求是这样的：
- 在判定目标已达成之前，执行一次“完成审计”
- 把目标重述为具体的交付物或成功标准
- 构建一份提示词到产物的清单，把每一条显式要求、每一个编号项、每一个具名文件、命令、测试、门禁、交付物映射到具体证据
- 检查相关文件、命令输出、测试结果、PR 状态等真实证据
- 不要把代理信号当成完成证据：测试通过、清单填满、verifier 跑成功、写了大量代码，这些只是辅助信号，不能单独作为完成依据
- 把不确定视作未达成；继续验证或继续工作
还有一段非常关键的反偷懒规则：
> 不要依赖你的意图、阶段性进度、已耗费精力、对早前工作的记忆、或一个看上去合理的最终答案，作为完成的证明。只有审计显示目标确实已达成、且没有遗留必需工作时，才能调用 update_goal 标记完成。
这套机制是在解决一个具体的痛点：模型在长任务中习惯“sandbag”（早早声称做完然后偷懒）。`/goal` 把这种倾向用机制压住了。但前提是你给的目标必须能被映射成一份清单。
### 3. Token 预算的软停止
`/goal` 支持设置 token 预算上限。一旦烧到上限，Codex 不会粗暴中断当前轮次，而是注入另一段提示词 `budget_limit.md`，让模型把当前任务收尾：总结已完成的进度、列出剩余工作、给出下一步建议，然后停下。
对于无人值守场景，这意味着即使你设错了预期或者目标比想象中复杂，你也能在第二天打开终端时拿到一份能看懂的进度报告，而不是一堆半成品和没了的 token。
### 4. 完整的生命周期控制
`/goal` 提供四类 TUI 命令：
| 命令 | 作用 |
|---|---|
| `/goal <objective>` | 创建或替换当前目标 |
| `/goal` | 显示当前目标摘要（状态、目标内容、耗时、token 用量） |
| `/goal pause` | 暂停延续 |
| `/goal resume` | 恢复暂停的目标（早期叫 `/goal unpause`，后来 PR #20082 改名了） |
| `/goal clear` | 清空当前目标 |
注意：暂停、恢复、清空、预算限制状态的转换，模型自己改不了，只能由用户或运行时触发。这是设计上的安全边界。模型唯一能自己做的状态变更是“标记完成”，而且这个动作还得通过完成审计。
## 三、什么场景适合用 /goal，什么场景不要用
`/goal` 很强，但不是所有任务都该用它。盲目用反而费 token、跑偏、卡死。我的判断标准是这样的。
### 适合用 /goal
- 重复性 + 持续性的批量任务：批量修 bug、批量重命名、批量生成测试用例、批量补文档
- 覆盖式任务：QA 一个完整流程、把整个 repo 的某个表面摸完（类型严格化、文档同步、安全扫描）
- 明确的工程任务：迁移一个模块、把一个 feature 从老仓库移植到新仓库、按规格文档实现一个完整功能
- 长程探索：代码考古、架构梳理（只生成报告，不动代码）
- 基于规格文档的实现：配合 OpenSpec 这类工具，把 spec 直接交给 `/goal` 跑
### 不要用 /goal
- 单轮就能完成的小任务，比如让 Codex 写个冒泡排序。直接用普通 prompt，杀鸡用牛刀只会更慢更费 token。
- 说不清“完成长什么样”的探索性任务，比如 `/goal 给我开发一个背单词 APP`。没有验收标准，Codex 会幻想出一个目标然后认真去实现，但实现出来的不是你要的。
- 需要用户不断决策的任务，比如产品决策、商业取舍、UX 偏好。这些必须人来拍板，Agent 替不了。
- 破坏性、不可回滚的操作，比如删数据库、删大量文件、做不可逆的迁移。`/goal` 的特点是会自己往下推进，这种场景下风险会被放大。
- 需要快速迭代的原型阶段。几分钟就能跑出来的原型，直接做就行，套上 `/goal` 反而徒增开销。
- Plan 模式下。Issue #20656 已经报告：在 `/plan` 模式下，即使你看到 UI 上显示 “Goal active”，Codex 实际上不会自动延续。源码里 `should_ignore_goal_for_mode` 函数在 Plan 模式下直接跳过 goal 延续。所以如果你要用 `/plan` 做规划，先退出 Plan 模式再启动或恢复 `/goal`。
## 四、启用 /goal
`/goal` 目前是实验性功能，默认关闭，需要手动开启。
### 方法 1：改配置文件
打开 `~/.codex/config.toml`，加上下面这段：
```toml
[features]
goals = true
```
如果你想完整体验所有相关功能（尤其是 `/plan` 配合 `/goal`），可以把协作模式也打开：
```toml
[features]
goals = true
collaboration_modes = true
```
保存，然后重启 Codex，`/goal` 就可用了。
### 方法 2：让 Codex 自己改
如果你不熟悉配置文件的位置和写法，可以直接在 Codex 里用自然语言描述：
```text
请帮我开启 Codex 0.128 新增的 /goal 命令。
配置文件位置：~/.codex/config.toml
需要在 [features] 段下加上 goals = true。
如果文件不存在请创建，如果 [features] 段不存在请新增。
```
Codex 会自动帮你完成。改完别忘了重启。
### 验证
启动后输入 `/`，如果在斜杠命令补全列表里能看到 `/goal`，说明已经启用。也可以直接输入 `/goal` 回车，如果显示“暂无目标”或者类似的状态摘要，就是好了。
## 五、/goal 提示词的核心心法
我在最初使用 `/goal` 的时候，踩过一个最典型的坑：直接 `/goal` 加一句简短描述就回车走人。结果几个小时回来一看，Codex 跑了一堆事情，但跑的根本不是我要的；甚至有时候会陷入静默卡死状态。
后来我把这个事情想清楚了：`/goal` 对提示词的要求，比普通对话高一个数量级。原因是它的内置审计机制。`continuation.md` 要把你的目标映射成一份“提示词到产物”的清单，如果你用的是模糊词，比如“全部”“所有”“彻底”“清理一下”“提升一下”，清单根本建不起来，审计就会退化成“测试跑过了就算完成”这种代理信号，然后你就得到一个声称完成、实际跑偏的结果。
所以 `/goal` 真正发挥威力的前提，是你要能写出可被映射成清单的目标。
### 五段式黄金模板
经过这段时间的实践，我固定下来一套五段式模板，几乎所有 `/goal` 我都按这个写：
```text
/goal <一句话描述目标>
Scope: <作用范围：改哪些文件/子系统/feature 区域，其他不要碰>
Constraints:
- <硬性约束 1，比如“不要修改数据库 schema”>
- <硬性约束 2，比如“保持现有公开 API 不变”>
- <硬性约束 3，项目类型相关的默认规则>
Done when:
1. <可验证的产物 1，引用具体文件名或命令>
2. <可验证的产物 2>
3. <可验证的产物 3>
Stop if:
- <机械可识别的停止条件 1，比如“需要新依赖”>
- <机械可识别的停止条件 2，比如“需要修改 MUST NOT 列表中的文件”>
Use a token budget of <N> tokens for this goal.
```
每一段的要点：
- Objective：一句话说清要做什么。避开虚词：全部、所有、彻底、improve、optimize、clean up，这些词无法映射成清单，会让审计失效。
- Scope：画一条边界。Codex 是会扩散的，你不画它就乱跑。
- Constraints：硬性规则，违反就停。约束一定要“可机械识别”，比如“不动 project.pbxproj”就比“不要破坏现有结构”好。
- Done when：验收清单。每一条最好引用一个具体文件路径或者一个具体命令（`npm test`、`pytest -q`、`tsc --noEmit` 都比“测试通过”明确）。
- Stop if：停止条件。这个比 Done when 更重要，它防止 Codex 钻牛角尖或越界。
- Token budget：必给。这是 Codex 唯一一个一等公民的成本治理机制。没设预算 = 没有软停止 = 万一跑飞就只能眼睁睁看着烧 token。
### 一个具体例子
```text
/goal 把 src/data/words.json 里的词库扩展到 1000 个唯一词条。
Scope: 只改 src/data/words.json，其他文件不要动。
Constraints:
- 词条 schema 保持不变（id / word / phonetic / meaning / example）
- 不允许重复词条（以 word 字段为准去重）
- 只能用真实的、常见的英语单词，不要生造
Done when:
1. words.json 包含恰好 1000 个唯一词条
2. 所有词条 schema 校验通过（用 tools/validate.js 跑一遍）
3. 在终端输出最终词条数和文件大小
Stop if:
- 需要修改 words.json 以外的任何文件
- 需要新增 npm 依赖
- 出现 schema 校验失败超过 3 次
Use a token budget of 80000 tokens.
```
这个目标可以被审计。每一条 Done when 都对应一个能跑的检查；每一条 Stop if 都是机械可识别的；Scope 把作用面锁死了。这种 goal Codex 跑起来准确率明显不一样。
## 六、三种典型工作流
下面是我目前固定下来的三种 `/goal` 用法。从简单到复杂，按任务规模选用。
### 工作流 A：/goal 直接用，适合中等任务
适合任务边界清楚、自己能写出五段式模板的场景。直接在 Codex 里输入完整的 `/goal <五段式提示词>`，回车，然后该干嘛干嘛去。
跑起来后，你随时可以：
- 用 `/goal`（不带参数）查看当前进度：状态、耗时、token 用量
- 用 `/goal pause` 暂停
- 用 `/goal resume` 恢复
- 用 `/goal clear` 中止
这是最常用的形态。70% 的任务我都是这样跑的。
### 工作流 B：/plan + /goal，适合复杂任务
如果任务复杂、需求还比较模糊、自己也没想清楚验收标准，直接 `/goal` 是不行的，要先用 `/plan` 把方案讨论清楚。
完整流程：
1. 进入 Plan 模式（`/plan` 或者 `Shift+Tab` 切换）
2. 输入相对模糊的需求，比如“把这个 APP 做成可商业化的水平”
3. Codex 会和你互动，问关键决策（变现方式、差异化主线、目标用户等），它会基于你的回答生成完整计划
4. 计划生成后，Codex 会给你三个选项：立即执行 / 清空上下文再执行 / 保持在 Plan 模式
5. 选第三项，然后用 `Shift+Tab` 退出 Plan 模式
6. 这时再输入 `/goal` 执行上面的开发计划，加上 Done when / Stop if / token budget
为什么要先选“保持 Plan 模式”再手动退出？因为前两个选项会立刻执行，但执行的不是 `/goal` 模式，享受不到延续和审计；而你直接在 Plan 模式里输入 `/goal`，会落入 Issue #20656 的坑：看上去激活了但其实不延续。所以必须先退出 Plan 模式，再下 `/goal`。
### 工作流 C：OpenSpec + /goal，适合规格驱动开发
这是最适合 `/goal` 的工作流之一。Spec-Driven Development（SDD） 的思路是：先把需求写成规格文档（包含 proposal、specs、design、tasks），然后让 AI 严格按规格实现。规格文档天然就是一份审计清单。把它喂给 `/goal`，完成审计能精准地工作。
OpenSpec 是 Fission-AI 团队开发的开源 SDD 工具（MIT 协议，GitHub 上 37k stars）。它的工作方式是这样的：
```text
You: /opsx:propose add-dark-mode
AI: Created openspec/changes/add-dark-mode/
✓ proposal.md — 为什么要做、改了什么
✓ specs/ — 需求和场景
✓ design.md — 技术方案
✓ tasks.md — 实现清单
Ready for implementation!
```
完整工作流：
### 1. 安装 OpenSpec
OpenSpec 需要 Node.js 20.19.0+。安装命令：
```bash
npm install -g @fission-ai/openspec@latest
```
进入项目目录，初始化：
```bash
cd your-project
openspec init
```
OpenSpec 会在项目里生成 `openspec/` 目录，并把适配你 AI 工具的指令写到对应的位置（它支持 20+ 种 AI 工具，Codex 也在里面）。
### 2. 用 OpenSpec 生成规格文档
在 Codex 里直接输入：
```text
/opsx:propose 为这个项目新增 Cohere Rerank 作为第五个 Rerank provider
```
Codex 会调用 OpenSpec，把你的需求拆解成 `proposal.md`、`specs/`、`design.md`、`tasks.md`。这一步不会动你任何源代码，只是把“要做什么”写清楚。
### 3. 用 /goal 执行规格
规格文档生成完后，在 Codex 里：
```text
/goal 严格实现 openspec/changes/add-cohere-rerank/ 中描述的变更。
First action: 先读 proposal.md / specs/ / design.md / tasks.md / AGENTS.md 这五个文件，
报告每个文件的字数和关键章节标题，等我确认后再开始实现。
Scope: design.md 里的 "MUST NOT modify" 列表严格遵守。
Constraints:
- AGENTS.md 中的所有 iron rules 不可违反
- 不允许新增 npm 依赖
- 镜像现有 4 个 Rerank provider 的代码风格
Done when:
1. tasks.md 中的每一项都打勾，引用对应文件路径
2. 每条 SHALL 都有对应的通过测试，引用测试名
3. 每个 GIVEN/WHEN/THEN 场景都有集成测试覆盖
4. `npx tsc --noEmit` 退出码 0
5. `npm test` 退出码 0，粘贴汇总输出
6. README.md 在 provider 表格里加上新一行
7. CHANGELOG.md 在 Unreleased 段加条目
Stop if:
- 任何任务需要修改 MUST NOT 列表中的文件
- SHALL 之间出现冲突（暂停，让我决定）
- 需要 npm install 新依赖
- 现有 Rerank provider 测试出现失败
Use a token budget of 120000 tokens.
```
注意第二行的 First action：这是个非常关键的小技巧。它强制 Codex 在动手前先把规格文件全部读一遍并向你报告确认，防止 Codex 用 `@filename` 等不可靠引用方式假装“知道”了规格，实际上没读全。
这种工作流跑出来的产物质量最稳。我自己测试中，中等规模的 feature（类似新增一个 provider 这种 200~400 行的改动）基本都能一次跑通，跑完直接是个能 review 的 PR。
## 七、用 goal-prompt-builder 把上面这些自动化
写好五段式提示词需要练习。如果不熟练，或者懒得每次手写，可以用我开发的 `goal-prompt-builder`：一个专门用来生成 `/goal` 提示词的 Claude Skill。
仓库地址：
```text
https://github.com/win4r/goal-prompt-builder
```
协议：MIT。
### 它解决什么
`/goal` 内置的 `continuation.md` 审计机制非常强，但前提是你的目标文本能被映射成清单。这个 skill 的核心目的就是：保证生成的目标文本一定可以被映射成审计清单。
### 它内部是怎么工作的
按 README 描述，skill 触发后会走 6 步：
1. 选择交互模式：步进式 / 完整描述式 / 混合式（默认）
2. 自动检测项目类型：通过看文件系统（`package.json`、`Cargo.toml`、`*.xcodeproj` 等）或者抓 GitHub README，顺便读 `AGENTS.md` / `CLAUDE.md`
3. 挑选场景模板：内置 7 套（refactor / SDD feature / batch / archaeology / UI audit / gatekeeper / custom）
4. 收集 5 段输入：Objective / Scope / Constraints / Done when / Stop if
5. 预测审计友好度：内部打分，如果分数低于 70 直接拒绝渲染，要求你补充信息
6. 渲染输出：一段可以直接粘贴的 `/goal` 提示词，加一段简短的设计说明
它内部有一组硬规则（从 `continuation.md` 倒推出来的）：
- 拒绝模糊动词：improve、optimize、clean up、all、everything、全部、彻底，这些词会触发反推，要求你换成可验证的描述
- 强制要求 token budget：没预算就没软停止，潜在跑飞
- 强制回归保护：任何动到测试覆盖代码的目标，自动加上“不许改测试让它通过”的 stop-if
- SDD 类目标强制 read+report 优先：防止 `@filename` 引用不准
- brownfield 项目强制探测 MUST NOT 列表：scope creep 第一大原因
- 审计友好度 < 70% 直接拒绝渲染
我用这个 skill 之后，日常写 `/goal` 的速度快了非常多。简单任务一两分钟就能从一句话需求走到一个可用的 5 段式提示词。
### 怎么安装
按 README，有三种方式。
方式 1：一行命令安装
```bash
curl -L -o /tmp/goal-prompt-builder.skill \
https://github.com/win4r/goal-prompt-builder/raw/main/goal-prompt-builder.skill
mkdir -p ~/.claude/skills
unzip -o /tmp/goal-prompt-builder.skill -d ~/.claude/skills/
rm /tmp/goal-prompt-builder.skill
```
方式 2：克隆并软链
```bash
git clone https://github.com/win4r/goal-prompt-builder.git
ln -s "$(pwd)/goal-prompt-builder/goal-prompt-builder" ~/.claude/skills/goal-prompt-builder
```
方式 3：让 Codex 自己装
如果你不熟命令行，直接在 Codex 里描述安装需求：
```text
请帮我安装这个 skill：https://github.com/win4r/goal-prompt-builder
按 README 的安装方式装到默认位置。
```
Codex 会自己执行下载、解压、放到对应目录。装完后重启 Codex，skill 就生效了。
注意：这个 skill 是用 Claude Skills 格式构建的，默认安装位置是 `~/.claude/skills/`。具体在哪个客户端能被识别，以你客户端文档为准。README 明确列出的兼容客户端是 Claude Code、Claude Desktop、以及支持 Skills 的 Claude.ai。
### 怎么用
安装重启后，skill 会被以下短语自动触发，不需要手动调：
- “help me write a /goal for …”
- “design a goal for X”
- “review my goal command”
- “我要用 /goal 来…”
- 任何提到长任务 + Codex 的对话
最简单的用法是丢一个一句话需求进去，比如：
```text
我想用 /goal 给这个项目增加 Cohere Rerank 作为第五个 Rerank provider
```
skill 会：
- 自动检测出这是 Node/TypeScript 项目（看 `package.json`）
- 读 `AGENTS.md` / `CLAUDE.md` 提取项目特定的规则
- 问你几个关键问题（token 预算、是否有 SDD 规格、是否有要保护的 MUST NOT 文件）
- 输出一段五段式 `/goal` + 一段设计说明，告诉你为什么这样写
把输出粘贴到 Codex 的输入框，回车，任务就跑起来了。
## 八、几个非常容易踩的坑
这些是我自己踩过、或者社区在 GitHub Issue 里报告过的坑。直接列出来，贴在显示器旁边比什么都管用。
### 坑 1：Plan 模式下 /goal 不延续
现象：UI 上显示 “Goal active”，但 Codex 不会自己往下推进，看上去像卡死了。
原因：Issue #20656。源码里 `should_ignore_goal_for_mode(mode) -> mode == ModeKind::Plan`。Plan 模式下 goal 延续被静默跳过。
对策：用 `/plan` 做规划时不要同时启动 `/goal`。规划完先退出 Plan 模式（`Shift+Tab`），再下 `/goal`。
### 坑 2：中途 /compact 把 goal 上下文搞丢
现象：跑了一段时间，模型突然好像“忘了”目标的细节，开始做不相关的事，或者过早声称完成。
原因：Issue #19910。如果 `/compact` 发生在一轮模型调用执行的中间，延续提示词不会被重新注入，后续 agent 丢掉目标和审计要求。
对策：长任务不要手动 `/compact`。设一个相对宽松的 token 预算，让自动 compaction 落在轮次边界上。
### 坑 3：第一条消息就发 /goal，之后 resume 列表里找不到这个会话
现象：`codex resume` 列表、Codex Desktop 的 recents 里都看不到这个 thread，但 thread 本身没丢，知道 ID 还能打开。
原因：Issue #20792。`/goal-first` 的 thread 在列表里被遗漏了。
对策：新 thread 第一条消息别用 `/goal`。先随便发一句话，比如 “Working on the OAuth migration goal”，再用 `/goal`。
### 坑 4：目标里出现“全部 / 所有 / 彻底 / improve”
现象：跑了几个小时回来，声称做完了，但你一看实际改动只是边边角角，核心问题没动。
原因：这些词没法被 `continuation.md` 映射成清单，审计退化成“测试跑过 = 完成”。
对策：换具体的数字或可验证的状态。“修 5 个真实可复现的 bug”“覆盖 README 列出的 3 条用户路径”“pytest 0 失败 0 跳过”，这些都比“修复所有 bug”强很多。
### 坑 5：不设 token 预算
现象：任务跑飞，token 烧光也没人提醒，等回来一看账单不对劲。
对策：永远设 token budget。`Use a token budget of <N> tokens for this goal.`。烧到上限会触发软停止，让模型把工作收尾，而不是裸停。
### 坑 6：破坏性操作不加保护
现象：让 Codex 做迁移，跑着跑着把数据库 schema 改了 / 把不该删的文件删了。
对策：破坏性操作不要用 `/goal`。必须用的话，Constraints 里明确写“不要执行 `rm -rf`”“不要修改数据库 schema”“任何 destructive migration 暂停问我”，并且把对应内容也写进 Stop if。
## 九、控制命令速查
| 操作 | 命令 |
|---|---|
| 创建/替换目标 | `/goal <objective>` |
| 查看当前目标摘要 | `/goal`（不带参数） |
| 暂停 | `/goal pause` |
| 恢复 | `/goal resume` |
| 清空 | `/goal clear` |
| 退出 Plan 模式 | `Shift+Tab` |
| 跨会话恢复 thread | `codex resume <id>` |
状态标识：
- `pursuing / active`：正在自主推进
- `paused`：被手动暂停
- `achieved / complete`：完成审计通过，目标达成
- `unmet`：未达成
- `budget_limited`：token 预算耗尽，软停止中
## 十、启动前 checklist
每次发 `/goal` 之前，过一遍这个清单：
- [ ] 对项目的上下文我先聊过一轮了吗？背景、关心的模块、已排除的方向、`AGENTS.md` / `CLAUDE.md` 是否已读
- [ ] 我的目标可以被映射成一份清单吗？
- [ ] 验收标准是具体数字 / 可验证状态，还是“全部 / 所有 / 彻底”这种虚词？
- [ ] Stop if 段写了吗？它能不能机械可识别？
- [ ] Token budget 设了吗？
- [ ] 这个任务真的需要 `/goal` 吗？单轮能干完的别用
- [ ] 我现在不在 Plan 模式吧？
- [ ] 这是 thread 的第一条消息吗？如果是，先发一条非 `/goal` 消息再说
跑起来之后：
- [ ] 第一轮输出对得上我的目标吗？对不上立刻 `/goal pause`，补上下文，再 `/goal resume`
- [ ] 中间需要的话用 `/goal` 查进度
- [ ] 长任务不要手动 `/compact`
- [ ] 重要节点考虑挂 hook，比如自动 commit、自动跑测试
## 十一、一些更宏观的观察
最近半年，prompt 写法明显在变化：
- 以前：一步一步指挥，比如“先做 A，再做 B，然后 C”
- 现在：声明结果，比如“我要这个，完成标准是 X、Y、Z，达到 X / Y / Z 才算完成”，然后让 Agent 自己规划
`/goal` 是这个方向走得最远的产物之一。它把“过程指挥”压到最低、把“结果声明”提到最高，然后用一套内置审计机制保证模型不偷懒。
但反过来，这也提高了对“会写需求”的要求。模型越来越能干，但它干得好不好，反过来更依赖你能不能把“到底要啥”说清楚。会写需求这件事，正在重新变成稀缺技能。
以前 prompt 糊一点没事，反正它也只跑几秒钟；现在它能跑一整天，你那条糊掉的 goal，换来的就是一整天的糊产出。
`/goal` 的真正价值不在于“它能跑一整天”，而在于它把“AI 真的能替你跑一整天”这件事，从一个需要外部脚本 + 反复试错的工程，变成了一条可以直接在终端里下的命令。剩下的事，是把目标写清楚。
---
来源：https://zhuanlan.zhihu.com/p/2035288538678288989
🚀开发者必看！Codex /goal命令高级技巧保姆级教程：Plan模式+Spec-Driven+自研Skill 三大技巧组合让效率倍增
管
管理员
Tags
Share
