轻松掌握目标设定！五步教你如何用好目标！

（

石臻说AI

编辑：石臻

导读：不少小伙伴在用 AI 写代码时，卡住的地方往往不是因为模型不够强，而是因为任务说明得不够清晰。你可能会说“帮我完成这个功能”，可是后面又不断补充、修正，搞得一团糟。

这套 `/goal` 的使用方法，关键不在于省几个字，而是要把“目标、拆解、验收”这几步先理清楚，再让不同的 agent 各自带着目标一起并行工作。

先弄明白这个用法

以前我们写提示时，常常把“需求、执行步骤、注意事项、验收标准”混在一起。短任务还行，一旦任务复杂了，Codex 很容易就只抓住了最显眼的部分，后面的要求全都被忽略了。

更为稳妥的做法是先让 Codex 写下自己的 /goal：将你的意图转化为清晰的目标，再列出范围、子任务、风险和验收标准。人给方向，agent 则负责将这一方向翻译成具体的任务。

这和普通的提示方式其实差别很大。

普通的提示就像是“我给你一堆指令，你照着做就行”。而这套方法更像是先召开一个小型项目会议：你说出想要的东西，Codex 先帮你定义任务、拆解方式、子任务边界和验收标准，然后再开始执行。

简单来说，/goal 不是什么魔法咒语，它更像是 agent 的工作协议。

真正有效的不是“让 AI 自主决定一切”，而是让 AI 先把你模糊的想法翻译成切实可行的计划。

可复制的 5 步工作流程

先看看这张流程图。如果你希望 Codex 处理较长的任务，可以按这个顺序来操作。

第一步：先写下“意图”，别急着写完整的计划。

比如你想做一个 Three.js 的过山车第一人称视角 demo，刚开始没必要把所有技术细节都写得死死的。你可以先清楚地表达出最终想要的体验、约束和交付物：

💡 提示词参考：

我想做一个 Three.js 第一视角的过山车 demo。需要包含循环轨道、下落、倾斜转弯、至少一次翻转、速度感、地形、天空盒和音效。最终交付一个单 HTML 文件。

第二步：让 Codex 先给自己写个 goal。

这一点是整个方法的关键。不要直接说“开始做”，而是让它先把任务转化为可执行的目标。

💡 提示词参考：

For this task, write yourself a new goal first. Turn my request into a concrete objective with scope, constraints, subtasks, and acceptance criteria. Then execute against that goal.

如果你喜欢中文，可以这样说：

请先不急于实现。为自己写一个新的 /goal：将我的需求转化为清晰目标，列出范围、约束、子任务、验收标准。确认这个 goal 后，再去执行。

第三步：如果任务大，可以让它派生子 agent。

这里有个很重要的点：让 Codex 并行生成 agents，把工作分成独立的部分，每个 agent 都要有自己专属的 /goal。

你可以加上这句话：

💡 提示词参考：

If this benefits from parallel work, spawn agents for independent pieces. Give each agent its own dedicated /goal, make their deliverables explicit, and synthesize the results when they return.

这句话的意义在于，它不仅仅是在说“多线程工作”。它要求每个子 agent 带着自己的任务边界去执行：谁负责研究，谁负责实现，谁负责测试，谁负责审查。

第四步：让主线程负责整合，而不是让子 agent 争夺方向。

并行的 agent 最大的问题就是，大家都在努力，但最终却无法整合。所以主线程必须承担“总协调”的角色：收集子结果，判断冲突，合并方案，决定下一步走向。

你可以明确写一句：

Keep the main path responsible for coordination. Subagents should return findings or patches, but the main agent must synthesize and make final decisions.

第五步：让它把 goal 当作可以更新的对象。

长任务最怕在执行过程中目标发生漂移。一个好的补充要求是：如果 Codex 发现原目标不够完整，可以更新 goal，但必须解释为什么要改。

If the goal needs to change, update it explicitly and explain what changed before continuing.

这样能让 agent 少点“偷偷换题”，多点可追踪的项目感。

什么时候适合用，什么时候不太适合

这套方法特别适合三类任务。

让Codex更高效：如何制定清晰目标

有些场合其实不太适合用这种方法，比如说简单的修修补补、单个文件改一行，或者你已经有了特别精准的解决方案。这种情况下，让Codex再去写目标，反而显得有点多余。

我个人的经验是：只要这个任务预计时间超过20分钟，或者你觉得中间可能会频繁修改需求，那就一定要让Codex先写个目标。

虽然这一过程看似拖慢了速度，实际上却能有效减少后面的重复工作。

直接用的模板

下面这一段模板可以直接保存哦。等你需要的时候，只需替换第一段的任务描述，后面的内容基本不需要改。

💡 模板

通用格式：

我想完成以下任务：

[在这里写上你的需求]

在实施之前，请为自己写一个新的/goal。把我的意图变成一个具体的目标，包含范围、限制、子任务、风险和验收标准。

如果任务可以并行处理，就为独立的部分派出多个agents。每个agent都要有自己专属的/goal和明确的交付内容。

主负责路径要负责协调和最终的整合。如果目标需要更改，记得明确说明变动的内容和原因，再继续。

如果你是处理代码任务，我建议再加三条：

首先，先阅读现有的代码库，遵循本地的编码规范。

不要进行无关的重构。

在结束前，务必通过相关的测试或检查验证结果。

这三条听起来简单，但非常有效。它们能让agent从“随意发挥”回到工程的实际场景中。

如果你想全程用中文，也有这个版本：

💡 模板

中文格式：

我想完成下面这个任务：

[在这里写你的真实需求]

开始实施前，请先为自己设定一个新的/goal。将我的意图整理成具体目标，明确范围、约束、子任务、风险和验收标准。

如果任务适合并行处理，请为每个独立部分派出agents。每个agent都要有自己的dedicated /goal，并说明需要交付什么。

主线程负责协调和最终汇总。如果在执行过程中需要调整goal，请先清晰说明改动内容及原因，然后再继续。

最后说几句实话

/goal 这种能力让agent更像是一个能理解上下文的合作者，但它不会自动为你思考产品的判断。

你依然需要负责意图：想做什么、为什么做、哪些部分不能碰、结果怎么算完成。

Codex的任务是整理这些意图并转化为工作目标，再把目标分配给合适的执行单元。人的角色并不是消失，而是从“逐字下指令”变成“定义方向和验收标准”。

可以把这套方法浓缩成一句话：不要只让Codex干活，先让它理清楚怎么干活。任务越复杂，`/goal` 的价值就越明显。