goal 是什么？
一个指令就能让 AI 自主持续工作几天！
Codex 桌面版 /goal 模式正式上线了。中文版codex 中叫做追求目标 /目标 可以唤出菜单，如果是英文版，则是 /goal。
以前我们用 Codex，大多还是一轮一轮对话：
- 你提一个要求，它做一步；
- 你发现问题，再继续追问；
- 它再修改一轮。
使用 /goal 不是这样，只要输入这一个指令并且设下目标，Codex 会自己持续拆步骤、回测、修正，并一直往前做，直到任务完成才停下来，复杂任务会持续工作几小时甚至几天。 这也是为什么很多人觉得 /goal 开始像一个真正的 agent workflow。
如何安装使用呢？
要使用这个功能，请把你的 Codex 更新到最新版本，然后你只要在对话框输入 "/goal"（中文版是 /目标），就能看见官方已经把这个功能正式登陆。
如果你更新后仍然看不见这个功能，可以在终端输入以下指令，重启 Codex，应该就能启动这个厉害的功能。
终端指令：
bash
codex features enable goals如何用好和案例
要使用好 /goal 这个功能，最重要的不是会开启这个功能，也不是会写提示词，而是要理解这个功能的核心是什么。
核心是：确定一个明确的目标。
所以要使用好 /goal 这个功能，核心不是说你的需求文档写得有多长，而是：
- 目标能不能明确地确定：这个目标在什么情况下算完成？
- 完成的条件：是不是明确、是不是可验证？
- 对 AI 的限制：有没有做出一些限制，比如它是基于哪些文件去进行工作的？
所以如果你只写"帮我优化一下代码"，那么它可能会一直执行，但是得到的结果未必是你想要的。因为 AI 会去猜，会不断地尝试。
那么这个功能就不再是一个能够完成你目标的功能，而是会成为一个巨量消耗你 token 的功能。
但如果你能明确：
- 什么才算完成
- 哪些不能改
- 如何验证结果
那 /goal 的效果会立刻提升一个等级。
以我的使用理解，/goal 真正厉害的地方，是它把 Codex 变成了一个会持续追目标的 agent。
你不用每一轮都盯着它下指令，而是先把终点定义清楚，让它自己往前推进、验证、修正。
这才是这个功能最强的地方。
因此只要你能够拆出来明确清晰的目标 - 限制 - 验收标准， goal 就很好用。
我给大家提供一些简单的模板，大家在使用的时候可以套用到自己的任务中：
text
/goal 完成「{任务目标}」。
完成标准：
- {验收条件1}
- {验收条件2}
限制：
- {限制1}
- {限制2}
要求：
自主拆解步骤并持续推进。
每完成关键阶段自行验证。
如果方案失败，先尝试低风险替代方案。
不要跳过验证，也不要过早结束。
最终只汇报：
1. 最终结果
2. 关键改动
3. 验证结果
4. 剩余风险甚至很多时候，我会直接用超短版：
text
/goal 完成「{任务}」，直到：
- {条件1}
- {条件2}
执行期间请自主规划、执行、验证与修正。
优先选择低风险、容易验证的方案。
不要提前结束。
最后仅汇报结果、验证结论与剩余风险。案例一：复刻网页效果
通过截图来复刻成网页，这个需求在我看来是非常适合使用 /goal 这个功能的，因为它的目标足够明确，而且可验证。
在我发布的开源项目 Claude FM 中，整体的 Web 效果就是我通过这个功能来进行 1:1 复刻的。只要一张截图，就能出现一个八九成相似的 HTML 页面。
复刻的效果：
案例二：实际开发中 先 plan 后 goal
在我实际的开发工作中，我也经常使用这个功能。但实际开发要更加复杂一点，因为面对的环境非常多样，尤其是企业的很多环境，AI 自动化测试实际上并不能很好地处理所有的环境调用。比如数据库的测试线连接可能非常复杂，因此在实际使用中。
在实际的使用中，我会通过三个部分的优化来使用这个功能：
-
人为对需求进行拆分：很多时候面对的需求需要一个星期甚至两周去开发，如果一次性全部交给 AI 实现，就很难控制，也很难说清楚事情的目标、限制以及最后的验证标准。因此，人为的拆分非常重要，我常规的拆分方式是按照功能点进行拆分。
-
先 Plan 后目标驱动：先做计划，不管是通过 Codex 的计划模式，还是第三方开源的技能（例如 Superpowers），先做计划可以让你明确这个功能点或内容的开发，是否具有清晰的目标、验证标准和过程。
-
适当降低验收标准：在实际开发中会遇到一些环境限制，比如测试数据很难创造，或者本地连接可能有问题等，很难严格走标准的测试流程。而 AI 倾向于编写尽可能全面的测试，在这种情况下，适当降低验收标准是非常有用的。
别忘一键三连呦
