用 Codex 的体感，以前是这样的：你给它一个任务，它做一步，然后停下来等你。你说「继续」，它再做一步，再停。
像一个需要被不停催着走的实习生。
你得全程盯着，稍微走开一会儿，它就在那待命，什么都不干。
用 vibe coding 做过稍微复杂点的项目的人应该懂这种感觉。你脑子里有个完整的目标，但每次只能给它推进一小步，然后确认，再推进一小步。你不是在创作，你是在督工。
4 月 30 日，Simon Willison 的博客提到了 Codex CLI 0.128.0 新增的 /goal 功能。一条很短的更新，但我觉得这个变化比看起来大多了。
具体是什么：你设定一个 /goal，Codex 会进入一个自循环，持续评估任务有没有完成，没完成就继续往下推，直到目标达成或 token 预算耗完。
用一句话说，就是它自己会盯着目标转圈，不需要你在旁边一直催。
这个模式有个名字，叫 Ralph Loop，目标驱动的自主循环。Codex 把这个概念正式落地了。
「一问一答」和「自主完成」到底差在哪
以前的 Codex 工作模式，用「一问一答」来形容很准确。
你问，它答，交互结束。下一步怎么走，还是你决定。它是个很好用的工具，但你得把它当工具用，主动去用，不用就闲着。
某种程度上，这和搜索引擎有点像。你不问，它不说。你问什么，它答什么，不多也不少。
/goal 之后，模式变了。
你设定目标，它自己判断「当前进展到哪了」「还差什么」「接下来做什么」。这个循环它自己走，不是你推着走。
区别在哪？在于谁在「持有任务」。
以前是你在持有任务，Codex 帮你执行某个具体步骤。你是项目经理，它是执行层。每一步做完，控制权还在你手里，下一步怎么走你说了算。
现在 Codex 开始持有任务了，你退到了审核位置。它去推进，遇到决策点再来问你，或者直接按自己的判断走下去。
这不是小事。
把「持有任务」的角色交出去，需要两件事：一是 AI 要真的有能力自主判断下一步，二是你得愿意放手。第一件事，/goal 循环提供了基础能力。第二件事，需要你适应一种新的工作方式。
OpenAI 内部已经在用，PR 交付量涨了 5 倍
这不是停留在功能介绍层面的事。有数据在背后支撑。
OpenAI 内部有一套叫 Symphony 的系统，工作原理跟 /goal 循环类似，就是 Agent 自主完成任务的那种模式。他们用这套系统之后，工程团队的 PR 交付量提升了 500%。
5 倍。
这个数字我第一次看到时有点不信。500% 提升，这太夸张了。但再想想，也合理。
以前人写代码，大量时间花在「记住任务状态」「决定下一步做什么」「回去检查之前的进展」这些事情上。这些工作本身不产出代码，但占了相当多的精力。软件工程师的一大块工作，其实不是在写代码，是在管理任务状态。
如果 Agent 能自己管这个循环，工程师就只需要在关键节点做判断，实际产出量当然会往上走。
/goal 功能就是把这个逻辑带到了 Codex CLI 这个层面。
还有一个角度。以前的 AI 工具，你得搞清楚怎么问问题，才能让它给出有用的输出。「prompt engineering」这门学问就是这么来的。但循环式 Agent 不一样，它的核心不是一次性给出好答案，而是持续评估目标有没有达成，然后调整策略继续走。
这两种能力，底层逻辑其实很不一样。
用的人需要调整工作方式
如果你现在在用 Codex 做 vibe coding，/goal 值得认真试一试。
以前你可能习惯了「盯着它走」的工作方式，一步一确认，生怕它跑偏。这种习惯不是没道理，早期的 AI 编程工具确实需要这样用。跑偏了，你不知道，等发现问题，前面做的东西得全部推倒重来。
但工具在变。
自循环能力落地之后，更好的工作方式可能是：把目标定清楚，然后让它去跑，你去做别的事，等它给你一个进展报告。
当然，「token 预算耗完」这个兜底机制提醒我们，它还没到完全不用管的程度。目标拆得太大，或者任务本身没给足够的上下文，它还是会跑偏或者卡住。自循环不是无限循环，预算用完就停。
所以真正要练的技能，从「怎么催着 AI 一步步走」变成了「怎么把目标描述清楚、边界定好」。
这两件事，表面上都是「和 AI 说话」，但思维模式很不一样。前者是在管执行，后者是在定方向。
前者你得懂流程，后者你得懂目标。
把目标说清楚，其实比催着走更难。但这也是值得花时间练的地方，因为这个能力会一直有用，不管工具怎么迭代。
数据来源：
引用链接
[1] https://simonwillison.net/2026/Apr/30/codex-goals/
在 云栈社区 ，我们关注 AI 编程工具的一手变化，鼓励开发者分享实踩新功能的经验。如果你也有这类踩坑或惊喜，欢迎来聊聊你的故事。
发表于 1 小时前
|
查看: 11|
回复: 0
