Codex /goal 高阶实战技巧

Codex /goal 高阶实战技巧 Codex /goal 高阶实战技巧 Modified May 14 安装后，在终端里输入 codex 就可以初始化。如果这是你第一次使用 Codex，它会提示你进行认证。进入之后，就可以开始用了。 命令工具箱 • /goal <objective ：设置或替换任务目标 • /goal：查看当前状态 • /goal pause：暂停 • /goal resume：恢复 • /goal clear：在开始无关任务前重置 • Shift + Tab：执行前用它退出 Plan Mode • codex resume <id ：恢复长时间会话 状态解码器 • PURSUING / ACTIVE：循环正在运行。 • PAUSED：agent 正在等你调整约束或清除阻塞。 • ACHIEVED / COMPLETE：任务已完成。 • UNMET：agent 停止了，因为它找不到达成结果的路径。 • BUDGET LIMITED：你触达了 token 上限。 什么时候使用 /goal 如果一个任务比一条 prompt 更大，但又不是开放式愿望清单，就用 /goal。 适合的场景： • 修复需要测试和风险审查的 bug • 为仓库上线做准备 • 同步文档、示例、脚本和测试 • 在边界清晰的前提下执行迁移或重构 • 实现一份 spec • 端到端审计一个 workflow • 把源材料转成可长期使用的笔记和索引 不适合的场景： • 单行问题 • 很小的编辑 • “把所有东西都改好”这类模糊请求 • 需要你个人品味参与的产品决策 • 应该要求人工确认的破坏性操作 • 你无法描述“完成”意味着什么的任务 如何写一个好的 /goal 大多数人的错误，是把 goal 写得像普通 prompt。 不好的写法： Code block Plain Text Copy /goal Improve onboarding. 这太模糊了。 好的 goal 会给 Codex 一个可以审计的目标。 使用这个结构： Code block Plain Text Copy /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] 示例： Code block Plain Text Copy /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。我每天都会发布。 安装后，在终端里输入 codex 就可以初始化。如果这是你第一次使用 Codex，它会提示你进行认证。进入之后，就可以开始用了。 命令工具箱 • /goal <objective ：设置或替换任务目标 • /goal：查看当前状态 • /goal pause：暂停 • /goal resume：恢复 • /goal clear：在开始无关任务前重置 • Shift + Tab：执行前用它退出 Plan Mode • codex resume <id ：恢复长时间会话 状态解码器 • PURSUING / ACTIVE：循环正在运行。 • PAUSED：agent 正在等你调整约束或清除阻塞。 • ACHIEVED / COMPLETE：任务已完成。 • UNMET：agent 停止了，因为它找不到达成结果的路径。 • BUDGET LIMITED：你触达了 token 上限。 什么时候使用 /goal 如果一个任务比一条 prompt 更大，但又不是开放式愿望清单，就用 /goal。 适合的场景： • 修复需要测试和风险审查的 bug • 为仓库上线做准备 • 同步文档、示例、脚本和测试 • 在边界清晰的前提下执行迁移或重构 • 实现一份 spec • 端到端审计一个 workflow • 把源材料转成可长期使用的笔记和索引 不适合的场景： • 单行问题 • 很小的编辑 • “把所有东西都改好”这类模糊请求 • 需要你个人品味参与的产品决策 • 应该要求人工确认的破坏性操作 • 你无法描述“完成”意味着什么的任务 如何写一个好的 /goal 大多数人的错误，是把 goal 写得像普通 prompt。 不好的写法： 这太模糊了。 好的 goal 会给 Codex 一个可以审计的目标。 使用这个结构： 示例： 始终先规划，再设置 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 原帖链接：https://x.com/ziwenxu /status/2054032316867989972 别再把你的 agent 当成需要逐字脚本的实习生来用。 大多数人使用 Codex 的方式，其实是在盯着 agent 干活：写 prompt、检查结果、再写 prompt、纠偏，然后重复。 这只是披着自动化外衣的手工劳动。 /goal 会改变这种关系。 你不再告诉 Codex 下一步该做什么，而是定义最终结果。你不再管理每一条 prompt，而是定义什么叫“完成”。 一旦 goal 被设定，Codex 就能跨多轮持续朝着一个可验证的停止条件工作：检查、编辑、测试，并围绕目标不断重新校准。它不只是回答下一条指令，而是持续检查这个 goal 是否真的已经达成。 成功条件，而不是操作指令 普通 prompt 给 Codex 的是指令。/goal 给 Codex 的是成功条件。 如果你说：“修复登录流程里的 bug。”Codex 可能会修掉最明显的问题，然后停下来。它不一定会检查 edge cases、更新测试，或者注意到文档现在已经过时。它只被限定在下一步动作里。 但如果你这样说： Codex 的工作就变了。它必须验证现实状态。要让这件事成立，它需要： • 定义在你当前技术栈里，“可靠”到底意味着什么。 • 检查代码库里每一个相关文件。 • 执行修复，并用自动化测试验证。 • 重新校准工作，直到你要求的结果真的成立。 prompt 是让 Codex 做一件事。/goal 是让 Codex 让某件事变成事实。 意图的持续性 AI 开发里真正的瓶颈，是意图衰减。 真实工程工作是一场由几十个步骤组成的马拉松。在普通聊天里，最初的任务会被后续工作逐渐淹没。随着上下文窗口被填满，agent 会丢掉那个“为什么”。 /goal 就像一个持续存在的锚点。它不是历史记录里的另一条消息，而是一个会话级别的持续目标。 即使会话跑了好几个小时，或者经历了大量上下文压缩，Codex 仍然会锁定那颗“北极星”。它不是因为执行完某条 prompt 才停止，而是因为它验证了 goal 已经成为现实。 这是走向更长时间编码会话的一部分路径。 我们已经看到有开发者在跑 10 小时、20 小时的 Codex 会话。 不只是我一个人注意到了这种变化。 如何设置 /goal 在你能直接指挥结果之前，终端里需要先有正确的工具。/goal 目前存在于 Codex CLI 中。 1. 安装，以及“保持最新”规则 如果你还没有 CLI，现在就装。如果已经装了，更新它。/goal 引擎每周都在打磨，你不会想调试一个已经过时的版本。 使用 npm： 使用 Homebrew：