Codex /goal 被已有目标卡住？用 /goal clear 一秒清场

有个 Codex CLI 的小技巧，很多人可能真没注意到。

你经常用 /goal 的话，大概率遇到过这种情况：

你想让 agent 自己重新设定一个目标，继续往下推进。结果它不干了。

原因很简单：当前已经有目标了。

这时候别跟它掰扯，也别重新开一个会话。直接用：

/goal clear

旧目标清掉，再让 agent 重新规划就行。干净，利索。

这个问题通常出现在什么场景？

比如你正在让 Codex 帮你改一个项目。

一开始你给它的目标是：

修复登录页的样式问题

它开始按这个目标推进。

改着改着，你发现真正麻烦的不是样式，而是登录状态同步有 bug。

你想让 agent 自己判断下一步该怎么查、怎么修。

你可能会输入：

/goal

或者尝试让它重新设定目标。

结果它提醒你：当前已经存在目标，不能直接覆盖。

这就尴尬了。

你明明想换方向，它还抱着旧任务不撒手。像极了产品需求变了，开发文档还停留在上周五。😅

正确做法：先清空，再重新设定

直接执行：

/goal clear

这个命令的作用很明确：

• 清除当前已经设定的 goal
• 让 agent 摆脱旧目标约束
• 方便你重新指定方向
• 也方便 agent 自己规划新目标

清掉之后，你就可以继续说：

现在请你重新分析当前项目状态，并自己设定下一步目标。

或者更直接一点：

请基于当前代码状态，自主设定修复登录状态同步问题的目标，并继续推进。

这样 agent 就不会继续被旧目标卡住。

推荐用法：任务转向时立刻清 goal

/goal clear 最适合用在这些场景。

需求变了

你原本让它做页面样式。

后来发现要改接口逻辑。

这时候旧 goal 已经不适合继续用了，直接清掉。

/goal clear

然后告诉它新方向：

接下来重点排查接口返回数据和前端状态更新的问题。

agent 跑偏了

有时候 agent 会很执着。

你只是想让它看一眼配置，它却准备重构半个项目。

这时候别硬拉。

先清 goal，再重新收窄范围。

/goal clear

然后补一句：

只检查配置文件，不修改业务代码。

这样边界会清楚很多。

你想让 agent 自主推进

如果你正在做一个比较长的任务，比如：

• 整理项目结构
• 修复一组测试失败
• 排查构建报错
• 优化某个模块的实现

中途你可能不想一句句指挥。

你希望 agent 自己判断下一步。

那就先确保旧目标已经清掉，再让它重新规划。

/goal clear

接着说：

请你根据当前进展，自主设定下一个合理目标，并继续执行。

这招在长任务里很好用。

少一点来回确认，多一点自动推进。

一个完整示例

假设你正在修一个前端项目。

你一开始设了目标：

修复首页按钮样式错位问题。

Codex 改了一部分后，你发现控制台还有接口报错。

现在你想切到接口排查。

可以这么做：

/goal clear

然后输入：

当前重点从按钮样式切换到接口报错。请重新分析错误来源，设定新的修复目标，并继续推进。

这样 agent 的工作重心就切过去了。

不用重新开窗口。

不用把上下文再复制一遍。

也不用忍受它一直围着旧目标打转。

避坑清单

不要在旧 goal 还存在时硬塞新目标

你越硬塞，agent 越容易混乱。

它可能嘴上答应你，实际执行还带着旧目标的影子。

清掉再说，省心。

不要把 /goal clear 当成清空上下文

它清的是 goal，不是整个会话历史。

也就是说，agent 仍然能看到前面的上下文。

这点很关键。

你可以保留前面的分析，又能换一个新的执行方向。

挺香。

不要频繁乱清

如果当前目标还有效，就别手痒。

/goal clear 适合任务转向、目标过期、agent 跑偏这些情况。

如果只是补充要求，直接说清楚就行。

比如：

保持当前目标不变，但只修改登录相关文件。

没必要每次都清。

Codex 里这个提示不算显眼

有意思的是，Codex 对 clear 参数的提示并不算明显。

有些同类工具会把这个参数展示得更直白。

所以你如果没注意到，也很正常。

这就是典型的“知道了就很简单，不知道就卡半天”的命令。

开发工具里最气人的往往不是大问题，而是这种小开关藏得太深。

你可以直接记住这一句

当 Codex 的 /goal 被旧目标卡住时，用：

/goal clear

然后再让 agent 重新设定目标。

适合需求切换、任务跑偏、长任务重新规划。

下次 agent 抱着旧目标不放，你就别跟它讲道理了。

清场，重来。