# 🚀开发者必看!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