🚀开发者必看！Codex /goal命令你真用对了吗？goal命令高级技巧保姆级教程，Plan模式+Spec-Driven+自研Skill，三大高级技巧组合让

/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 内部新增了一整套目标生命周期管理机制。它由四个层面共同构成：

持久化层 --- 把目标作为一个独立于对话历史的状态存起来，带状态机（active / paused / achieved / unmet / budget_limited）
App-server RPC --- thread/goal/{get, set, clear} 三个接口，让客户端可以读写目标状态
模型工具 --- get_goal、create_goal、update_goal 三个工具，让模型可以查询和声明完成，但不能自己暂停/清空/篡改
运行时延续（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，加上下面这段：

ini 复制代码

[features]
goals = true

如果你想完整体验所有相关功能（尤其是 /plan 配合 /goal），可以把协作模式也打开：

ini 复制代码

[features]
goals = true
collaboration_modes = true

保存，然后重启 Codex ，/goal 就可用了。

方法 2：让 Codex 自己改

如果你不熟悉配置文件的位置和写法，可以直接在 Codex 里用自然语言描述，比如：

ini 复制代码

请帮我开启 Codex 0.128 新增的 /goal 命令。
配置文件位置：~/.codex/config.toml
需要在 [features] 段下加上 goals = true。
如果文件不存在请创建，如果 [features] 段不存在请新增。

Codex 会自动帮你完成。改完别忘了重启。

验证

启动后输入 /，如果在斜杠命令补全列表里能看到 /goal，说明已经启用。也可以直接输入 /goal 回车，如果显示"暂无目标"或者类似的状态摘要，就是好了。

五、`/goal` 提示词的核心心法

我在最初使用 /goal 的时候，踩过一个最典型的坑：直接 /goal 加一句简短描述就回车走人。结果几个小时回来一看，Codex 跑了一堆事情，但跑的根本不是我要的；甚至有时候会陷入静默卡死状态。

后来我把这个事情想清楚了： /goal 对提示词的要求，比普通对话高一个数量级 。原因是它的内置审计机制 ------ continuation.md 要把你的目标映射成一份"提示词到产物"的清单，如果你用的是模糊词（"全部"、"所有"、"彻底"、"清理一下"、"提升一下"），清单根本建不起来，审计就会退化成"测试跑过了就算完成"这种代理信号 ------ 然后你就得到一个声称完成、实际跑偏的结果。

所以 /goal 真正发挥威力的前提，是你要能写出可被映射成清单的目标。

五段式黄金模板

经过这段时间的实践，我固定下来一套五段式模板，几乎所有 /goal 我都按这个写：

xml 复制代码

/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。

一个具体例子

markdown 复制代码

/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 把方案讨论清楚。

完整流程：

进入 Plan 模式（/plan 或者 Shift+Tab 切换）
输入相对模糊的需求，比如"把这个 APP 做成可商业化的水平"
Codex 会和你互动，问关键决策（变现方式、差异化主线、目标用户等），它会基于你的回答生成完整计划
计划生成后，Codex 会给你三个选项：立即执行 / 清空上下文再执行 / 保持在 Plan 模式
选第三项 ，然后用 Shift+Tab 退出 Plan 模式
这时再输入 /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），它的工作方式是这样的：

bash 复制代码

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+。安装命令：

css 复制代码

npm install -g @fission-ai/openspec@latest

进入项目目录，初始化：

bash 复制代码

cd your-project
openspec init

OpenSpec 会在项目里生成 openspec/ 目录，并把适配你 AI 工具的指令写到对应的位置（它支持 20+ 种 AI 工具，Codex 也在里面）。

2. 用 OpenSpec 生成规格文档

在 Codex 里直接输入（/opsx:propose 是 OpenSpec 安装后注册的斜杠命令）：

bash 复制代码

/opsx:propose 为这个项目新增 Cohere Rerank 作为第五个 Rerank provider

Codex 会调用 OpenSpec，把你的需求拆解成 proposal.md、specs/、design.md、tasks.md。这一步不会动你任何源代码，只是把"要做什么"写清楚。

3. 用 `/goal` 执行规格

规格文档生成完后，在 Codex 里：

markdown 复制代码

/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，仓库在：

github.com/win4r/goal-...（MIT 协议）

它解决什么

/goal 内置的 continuation.md 审计机制非常强，但前提是你的目标文本能被映射成清单。这个 skill 的核心目的就是：保证生成的目标文本一定可以被映射成审计清单。

它内部是怎么工作的

按 README 描述，skill 触发后会走 6 步：

选择交互模式 --- 步进式 / 完整描述式 / 混合式（默认）
自动检测项目类型 --- 通过看文件系统（package.json、Cargo.toml、*.xcodeproj 等）或者抓 GitHub README，顺便读 AGENTS.md / CLAUDE.md
挑选场景模板 --- 内置 7 套（refactor / SDD feature / batch / archaeology / UI audit / gatekeeper / custom）
收集 5 段输入 --- Objective / Scope / Constraints / Done when / Stop if
预测审计友好度 --- 内部打分，如果分数低于 70 直接拒绝渲染，要求你补充信息
渲染输出 --- 一段可以直接粘贴的 /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 里描述安装需求：

bash 复制代码

请帮我安装这个 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 的对话

最简单的用法是丢一个一句话需求进去，比如：

bash 复制代码

我想用 /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 真的能替你跑一整天"这件事，从一个需要外部脚本 + 反复试错的工程，变成了一条可以直接在终端里下的命令。剩下的事，是把目标写清楚。

Tags: AGI · AIGC · AI 编程 · Claude · Claude Code · Codex · goal · OpenAI · OpenSpec · Ralph Loop · Spec-Driven

Categories: LLMs

🚀开发者必看！Codex /goal命令你真用对了吗？goal命令高级技巧保姆级教程，Plan模式+Spec-Driven+自研Skill，三大高级技巧组合让

一、/goal 是什么，以及它为什么重要

二、/goal 解决了哪些以前解决不了的问题

1. 目标本身的持久化

2. 内置的"完成审计"

3. Token 预算的软停止

4. 完整的生命周期控制

三、什么场景适合用 /goal，什么场景不要用

✅ 适合用 /goal

❌ 不要用 /goal

四、启用 /goal

方法 1：改配置文件

方法 2：让 Codex 自己改

验证

五、/goal 提示词的核心心法

五段式黄金模板

一个具体例子

六、三种典型工作流

工作流 A：/goal 直接用 --- 适合中等任务

工作流 B：/plan + /goal --- 适合复杂任务

工作流 C：OpenSpec + /goal --- 适合规格驱动开发

1. 安装 OpenSpec

2. 用 OpenSpec 生成规格文档

3. 用 /goal 执行规格

七、用 goal-prompt-builder 把上面这些自动化

它解决什么

它内部是怎么工作的

怎么安装

方式 1：一行命令安装

方式 2：克隆并软链

方式 3：让 Codex 自己装（视频演示中用的方式）

怎么用

八、几个非常容易踩的坑

坑 1：Plan 模式下 /goal 不延续

坑 2：中途 /compact 把 goal 上下文搞丢

坑 3：第一条消息就发 /goal，之后 resume 列表里找不到这个会话

坑 4：目标里出现"全部 / 所有 / 彻底 / improve"

坑 5：不设 token 预算

坑 6：破坏性操作不加保护

九、控制命令速查

十、启动前 checklist

十一、一些更宏观的观察

一、`/goal` 是什么，以及它为什么重要

二、`/goal` 解决了哪些以前解决不了的问题

三、什么场景适合用 `/goal`，什么场景不要用

✅ 适合用 `/goal`

❌ 不要用 `/goal`

四、启用 `/goal`

五、`/goal` 提示词的核心心法

工作流 A：`/goal` 直接用 --- 适合中等任务

工作流 B：`/plan` + `/goal` --- 适合复杂任务

工作流 C：OpenSpec + `/goal` --- 适合规格驱动开发

3. 用 `/goal` 执行规格

七、用 `goal-prompt-builder` 把上面这些自动化

坑 1：Plan 模式下 `/goal` 不延续

坑 2：中途 `/compact` 把 goal 上下文搞丢

坑 3：第一条消息就发 `/goal`，之后 resume 列表里找不到这个会话