别再把你的 agent 当成需要逐字脚本的实习生来用。

大多数人使用 Codex 的方式，其实是在盯着 agent 干活：写 prompt、检查结果、再写 prompt、纠偏，然后重复。

这只是披着自动化外衣的手工劳动。

/goal 会改变这种关系。

你不再告诉 Codex 下一步该做什么，而是定义最终结果。你不再管理每一条 prompt，而是定义什么叫“完成”。

一旦 goal 被设定，Codex 就能跨多轮持续朝着一个可验证的停止条件工作：检查、编辑、测试，并围绕目标不断重新校准。它不只是回答下一条指令，而是持续检查这个 goal 是否真的已经达成。

成功条件，而不是操作指令

普通 prompt 给 Codex 的是指令。/goal 给 Codex 的是成功条件。

如果你说：“修复登录流程里的 bug。”Codex 可能会修掉最明显的问题，然后停下来。它不一定会检查 edge cases、更新测试，或者注意到文档现在已经过时。它只被限定在下一步动作里。

但如果你这样说：

/goal Make the login flow reliable for new users, cover the failure cases with tests, and explain any remaining risk.

Codex 的工作就变了。它必须验证现实状态。要让这件事成立，它需要：

  • 定义在你当前技术栈里，“可靠”到底意味着什么。
  • 检查代码库里每一个相关文件。
  • 执行修复，并用自动化测试验证。
  • 重新校准工作，直到你要求的结果真的成立。

prompt 是让 Codex 做一件事。/goal 是让 Codex 让某件事变成事实。

意图的持续性

AI 开发里真正的瓶颈，是意图衰减。

真实工程工作是一场由几十个步骤组成的马拉松。在普通聊天里，最初的任务会被后续工作逐渐淹没。随着上下文窗口被填满，agent 会丢掉那个“为什么”。

/goal 就像一个持续存在的锚点。它不是历史记录里的另一条消息，而是一个会话级别的持续目标。

即使会话跑了好几个小时，或者经历了大量上下文压缩，Codex 仍然会锁定那颗“北极星”。它不是因为执行完某条 prompt 才停止，而是因为它验证了 goal 已经成为现实。

这是走向更长时间编码会话的一部分路径。

我们已经看到有开发者在跑 10 小时、20 小时的 Codex 会话。

不只是我一个人注意到了这种变化。

如何设置 /goal

在你能直接指挥结果之前，终端里需要先有正确的工具。/goal 目前存在于 Codex CLI 中。

1. 安装，以及“保持最新”规则

如果你还没有 CLI，现在就装。如果已经装了，更新它。/goal 引擎每周都在打磨，你不会想调试一个已经过时的版本。

使用 npm：

广告媒流
# 全新安装
npm i -g @openai/codex

# 更新到最新版本（对 /goal 很关键）
npm i -g @openai/codex@latest

使用 Homebrew：

# 全新安装
brew install codex

# 更新到最新版本
brew upgrade codex

安装后，在终端里输入 codex 就可以初始化。如果这是你第一次使用 Codex，它会提示你进行认证。进入之后，就可以开始用了。

命令工具箱

  • /goal ：设置或替换任务目标
  • /goal：查看当前状态
  • /goal pause：暂停
  • /goal resume：恢复
  • /goal clear：在开始无关任务前重置
  • Shift + Tab：执行前用它退出 Plan Mode
  • codex resume ：恢复长时间会话

状态解码器

  • PURSUING / ACTIVE：循环正在运行。
  • PAUSED：agent 正在等你调整约束或清除阻塞。
  • ACHIEVED / COMPLETE：任务已完成。
  • UNMET：agent 停止了，因为它找不到达成结果的路径。
  • BUDGET_LIMITED：你触达了 token 上限。

什么时候使用 /goal

如果一个任务比一条 prompt 更大，但又不是开放式愿望清单，就用 /goal。

适合的场景：

  • 修复需要测试和风险审查的 bug
  • 为仓库上线做准备
  • 同步文档、示例、脚本和测试
  • 在边界清晰的前提下执行迁移或重构
  • 实现一份 spec
  • 端到端审计一个 workflow
  • 把源材料转成可长期使用的笔记和索引

不适合的场景：

  • 单行问题
  • 很小的编辑
  • “把所有东西都改好”这类模糊请求
  • 需要你个人品味参与的产品决策
  • 应该要求人工确认的破坏性操作
  • 你无法描述“完成”意味着什么的任务

如何写一个好的 /goal

大多数人的错误，是把 goal 写得像普通 prompt。

不好的写法：

/goal Improve onboarding.

这太模糊了。

好的 goal 会给 Codex 一个可以审计的目标。

使用这个结构：

/goal Make [final outcome] true.  
Scope: [what Codex can touch]  

Constraints: 
- [what must not change] 
- [what rules must be followed]  

Done when: 
1. [verifiable condition] 
2. [test, command, file, or output that proves progress] 
3. [final evidence]  

Stop if: 
- [condition where Codex should pause] 
- [anything risky or destructive]

示例：

/goal Make onboarding work from a fresh clone with one command.  
Scope: README.md, INSTALL_WITH_CODEX.md, scripts/, examples/.  

Constraints: 
- Do not change the public plugin manifest. 
- Do not remove existing examples. 
- Preserve the current vault folder structure.  

Done when: 
1. The README install path matches the actual scripts. 
2. The smoke test passes. 
3. The demo command generates a note pack. 
4. The docs explain where the generated notes appear.  

Stop if:
- A required command needs a new dependency. 
- Any install step requires manual credentials. 
- A test fails for a reason unrelated to onboarding.

始终先规划，再设置 goal

/goal 很强，但它不是魔法。如果你给 Codex 一个模糊目标，它就会花很长时间做模糊工作。

推荐模式：

  1. 规划，直到成功条件变清楚。
  2. 审计这个计划，确认它适合当前 repo。
  3. 用 /goal执行，把计划变成现实。

这就是架构师式交接：你提供策略，Codex 提供不知疲倦的执行。

/goal 失败的 6 种方式，以及我是怎么修的

过去几周我一直在学习 /goal。它很强，但如果你不尊重它的运行机制，它会烧掉你的 token，或者丢掉主线。下面是我识别出的 6 种模式，可以让你的会话保持在轨道上。

1. Plan Mode 陷阱

我见过有人，也包括我自己，试图在 /plan 里启动 goal。

  • 陷阱： 你会看到 “Goal active”，但 Codex 只是坐在那里看着你，不会动。
  • 我的修法： 用 /plan 规划策略，但在触发 /goal 命令前，先退出 Plan Mode（Shift+Tab）。Codex 需要处在“执行模式”里，才会真正启动循环。

2. 运行中的“失忆”

有时，一个长时间运行的 agent 会突然开始做随机工作，或者明明没完成却声称 “Mission Accomplished”。

  • 陷阱： 这通常发生在上下文达到上限，并在一轮中途自动压缩的时候。那颗“北极星”任务被挤出了上下文。
  • 我的修法： 不要在 goal 运行中手动触发 /compact。我会设置一个宽松的 token 预算，让系统自己处理边界。如果你注意到它开始漂移，就暂停并重新陈述 goal。

3. 幽灵会话

如果你在新 thread 的第一条消息就是 /goal，之后想在历史记录或 “Recents” 里找回来，祝你好运。

  • 陷阱： Codex 似乎会“隐藏”那些以命令开头、而不是以句子开头的 thread。
  • 我的修法： 我总是先发一句简短状态，例如：“Working on the UI migration.” 发送后，再输入 /goal。这样可以确保 thread 被保存并且可搜索。

4. 模糊形容词是毒药

“Improve”、“All”、“Thorough” 这类词，是最快制造 AI 粗糙输出的方式。

  • 陷阱： 如果你说 “Fix all bugs”，Codex 会修掉容易修的那些，然后因为“测试通过”就告诉你完成了。
  • 我的修法： 我使用可验证状态。不要说 “Improve everything”，而是说：“Match the README install path to the actual scripts and ensure the smoke test hits 100%.” 如果无法衡量，Codex 就无法审计。

5. 没有 kill switch 就开始跑

我曾经让任务失控并烧掉 token，因为我没有设上限。

  • 陷阱： goal-driven agent 是很“饥饿”的 agent。它会一直尝试解决问题，直到灯灭。
  • 我的修法：始终设置预算。 我会加一句：“Limit this run to 5,000 tokens.” 达到上限时，Codex 会收尾并停止，给我机会检查工作，再决定是否继续投入。

6. “大锤式处理”问题

如果你不小心，goal-driven agent 可能为了“清理干净”并达成目标，直接 rm -rf 一个文件夹，或者 drop 掉数据库 schema。

  • 陷阱： AI 不知道什么东西是“珍贵的”，除非你告诉它。
  • 我的修法： 我不会用 /goal 做破坏性迁移。如果必须这么做，我会在 “Stop If” 部分加一个硬性的安全锁：“Stop if you need to delete files or change the DB schema.” 我把它当成一位高级开发者来对待：给它能力，但同时定义红线。

更大的转向

过去与 AI 协作的方式是过程控制：

  • 做这一步。现在做这个。现在修掉你漏掉的东西。

新的方式是结果声明：

  • 这是目标。这是边界。这是证明方式。这是停止条件。

/goal 不会移除你的判断力；它会把你的判断力移动到更高层级。你不再把精力花在引导每一条 prompt 上，而是花在定义什么叫 “Finished” 上。

prompts 用于对话。goals 用于交付。

关注 @ziwenxu\_，获取更多技巧、workflow，以及支撑这个系统的每周综合 prompt。我每天都会发布。

📎 原文信息

原帖链接：https://x.com/ziwenxu\_/status/2054032316867989972