2小时烧掉9亿token后，我发现了OpenAI和Anthropic在/goal上的本质区别

推荐语

烧掉9亿token后，我们看清了OpenAI与Anthropic在/goal设计上两条完全相反的技术路径。

核心内容：
1. /goal功能如何将“做一件事”变为“做到某个状态为止”
2. OpenAI与Anthropic在完成判定机制上的本质区别
3. 两种技术路径背后不同的设计哲学与潜在问题

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

4 月 30 日，Codex 0.128.0 发布，第一次带上了 /goal。社区里立刻有人用它跑了 21 个小时，烧掉 9 亿 token。OpenAI 总裁 Greg Brockman 在 X 上把它对标成 Ralph loop 的内置版本——他原话是「codex now has a built in Ralph loop++」。

两周后，Anthropic 在 Claude Code 也跟进了同名命令。

除了这两家，Hermes、OpenCode 也都陆续跟上。/goal 已经成了这一类工具的共识机制。

说实话，第一次看到这个命令的时候我没什么感觉——不就是一个循环吗？以前用脚本和钩子拼一拼也能做出来。

但读完两家的实现之后，我愣了一下。

表面看用法一样，骨子里走的是两条完全相反的路。

/goal 到底是干嘛的

以前你跟 Claude Code 或者 Codex 说「帮我把这堆测试跑通」，它跑一轮，停下来，你看一眼说「继续」，它再跑一轮。中间总得有个人在那盯着。

/goal 把这件事改了。你给一段任务，再给一个完成条件——比如所有测试通过、lint 没报错——回车一敲，AI 自己开始跑。每跑完一轮，它自己判断条件是否满足，没满足就再来一轮，满足了才停。

形式上像这样：

/goal 把 src/auth/ 下所有测试跑通，lint 没报错

不需要中间敲回车说「继续」。

prompt 的形态变了。以前是让 AI 做这件事，现在是让 AI 把这件事做到这个状态为止。

听起来挺美好的。

但你想想——AI 怎么知道自己真的做完了？

这就是整件事的核心问题。

Ralph Loop：AI 自己说做完，就退出

/goal 不是凭空冒出来的。在它之前，社区里流行过一个做法叫 Ralph Loop。

名字来自《辛普森一家》里那个屡战屡败的 Ralph Wiggum——一种锲而不舍的工作法。原始版本就是一段简单的循环：反复把同一段任务喂给 AI，直到它自己说「我做完了」。

Anthropic 官方仓库里有个示例插件，把这个套路工程化了。逻辑就两件事：

第一，每次 AI 想停下来，钩子拦住它，把原任务再喂一次。

第二，AI 输出一句特定的暗号（比如 DONE），就算完成，循环退出。

我第一次看到这个设计的时候，第一反应是——

这不就是让 AI 自己批改自己的试卷吗？

它愿意写出 DONE 就退出，不愿意就接着跑。完成判定权完全在 AI 自己手里。

Ralph Loop 的作者自己也清楚这事儿不靠谱，所以在文档里反复提示要配最大轮次兜底。注入给 AI 的提示词里甚至有一句话很说明问题：

ONLY when statement is TRUE - do not lie to exit

你别撒谎啊。

但让 AI 不撒谎这件事，靠提示词上一句话是兜不住的。

AI 说「我做完了」和真的做完了之间，差着一座独立验证的桥。

两种判卷法

Ralph Loop 验证了一件事——循环这套思路，工程上是可行的。

但完成判定不能靠模型自己说了算。这是它最大的瓶颈。

Codex 和 Claude Code 都重新设计了这一块。但两家选了完全不同的方向。

Codex 的方法：让 AI 自己审，但审得没那么舒服

Codex 没换判卷人。每次 AI 想停下来，运行时强行塞一段审计提示词给它——而且这段提示词写得相当狠。

我把这段提示词的核心意思翻译一下：

在你判定任务完成之前，先假设没完成。然后逐项核对——目标里每一条要求、每一个产物、每一个测试、每一道关卡，挨个找证据证明它已经做完了。证据强度不够？算没完成。

最关键的一句：审计必须证明做完了，不能仅以没找到没做的事作为完成依据。

而且它显式禁止凭印象、凭记忆、凭一个看起来合理的结论当证据。

我读到这段的时候有点佩服。这是把完成这件事，从模糊感受变成了一份逐项核对的清单。

更重要的是，这段提示词不是写在文档里建议你最好这么做——它是被运行时强行注入到 AI 每一轮的上下文里。你想跳过都跳不过去。

工作模型本身有跑命令、查文件、看测试结果的能力。所以它审的是真状态，不是凭脑补。

Claude Code 的方法：另外请一个小模型来判

Anthropic 走的是另一条路。

工作模型干完一轮活，停下来。Claude Code 把完成条件和对话记录打包，交给一个独立的小模型去看。这个小模型的工作只有一件事：读完对话，判断条件是不是真的满足了。

它返回的是一个简单的判断：是 / 否，配一段简短的理由。

是？退出循环。

否？把理由作为系统消息塞回去，让主模型接着干。

这个小模型有个关键约束——它没有工具。它跑不了测试、查不了文件，只能基于对话里已经写出来的文字做判断。

我看到这个设计第一反应是：这就是 Anthropic 一贯的思路——生成的人和判定的人，得是两个人。

VentureBeat 报道里有一句话挺到位的：

You can't trust a model to judge its own homework. The model doing the work is the worst judge of whether it's done.

意思是：你没法让一个模型自己批改自己的作业。干活的人，是最不该当判卷人的人。

自审 vs 他审，差在哪

你看出来了——一边是让 AI 自己审，一边是另请判卷人。

各有优劣。

自审路线（Codex）的优势是审的是真东西。它能调工具、能跑命令、能读真实文件。证据是硬的。但它有个上限——审计能力被工作模型本身的能力卡住。模型不行，再狠的提示词也只是走过场。

他审路线（Claude Code）的优势是独立。判卷人和干活的人完全解耦，思路上更干净。但它的局限也很明显：判卷人看不到现实，只能基于对话里说了什么做判断。如果工作模型在对话里写一句「测试全部通过了」，但实际没跑——判卷人看到的证据就成立了，它会放行。

Claude Code 的文档里写得很坦诚：

你要把条件写成 Claude 自己能在输出里证明的样子。比如 test/auth 下所有测试通过这种条件能用，是因为 Claude 会运行测试，结果会落到对话里，判卷人看得到。

潜台词是：你得相信干活的人不会编造命令输出。

两条路都不完美。

但你想一下——Codex 选了让 AI 自己审，但审得没那么舒服；Anthropic 选了另请一个看不见现实的判卷人。

这背后是两种工程哲学。

OpenAI 信约束可以工程化——只要审计提示词写得够狠，工具调用框得够死，就能逼出审计行为。

Anthropic 信分离比约束有效——你没法让一个人自己审自己，那就找另一个人来审。

两家都没默认把能调工具的他审 AI 做进 /goal，即使这条路从原理上完全做得到。为什么？每轮多跑一个模型，成本翻倍，还得给它独立的沙盒和权限，状态机也跟着复杂。

工程上有时候不是最完美的方案胜出，是成本和效果折中下来还能跑得动的方案胜出。

关键约束必须放在代码层

读完两家的设计，有一件事是相通的。

Codex 那段强约束审计提示词，本质上只是一段文字。它之所以能生效，是因为每一轮上下文都被运行时强行注入了这段文字——AI 不可能跳过。

这个强行注入的动作，写在代码里，模型没法改。

Claude Code 的判卷人也一样。判卷人能被每一轮无条件调用，是因为这是钩子协议在 Claude Code 内核里的强制契约。

两家用完全不同的代码结构，表达了同一件事——

那些模型可能不遵守的关键约束，必须从提示词层提升到代码层。

写在 CLAUDE.md 里的规则，模型可以选择性忽略。写在 prompt 里的「请你严格审计」，模型可以糊弄过去。但是写在代码里的「每一轮无条件做这件事」，模型没办法绕。

我之前在 Harness Engineering 那篇文章里写过：建议和约束，完全两回事。现在更确信了。

不过两家分离的位置不一样。Claude Code 是另起了一个独立权重的小模型，工作模型跟它没有共用的判断逻辑——分离发生在模型权重一层。Codex 没换模型，让工作模型自己审，但靠运行时强制注入的审计提示词把审计动作和生成动作隔离开——分离发生在上下文一层。

同样是分离，做法可以完全不同。

完成判定，是长任务质量的天花板

Ralph Loop 的瓶颈在哪？

字符串匹配判完成。AI 只要愿意输出 DONE，整个循环就失效。

Codex 和 Claude Code 都重新设计了完成判定。思路截然不同——一个加上强约束的审计提示词逼工作模型自审，一个干脆把审计责任挪给独立小模型。

但两家的本质都是承认了一件事：

完成判定是长任务质量的瓶颈。

如果一个 AI 跑了 21 个小时、烧了 9 亿 token，最后它说「我做完了」——你信吗？

不审计，就只能信。

但信不是工程。

社区里有人在 Claude Code 上拼了一套 Codex 风格的实现，用钩子拦截，自己持久化目标状态，用一段强约束的提示词包裹任务，要求模型在标记完成前做证据核对。

这说明什么？

这说明这两条路在内核层级是可以互相替换的。差别只是谁原生支持哪一种。

最后产出的质量好不好，还是看工作模型本身的能力。

/goal 是 prompt 的新形态

我自己用 Claude Code 大半年了，/goal 让我重新看了一眼怎么写 prompt 这件事。

以前 prompt 是做这件事。

现在 prompt 变成达到这个状态，按这个标准验证，期间不能违反这些约束。

prompt 变成了一份合约。

这种形态对写需求的人提出了更高的要求。/goal 一跑就是一整天——目标写得糊弄，就只能换回糊弄的产出。

如果你把一份结构化的 SPEC 文档喂给 /goal，完成审计才能精确工作。如果你只写一句把代码跑通，审计就只能退化成测试通过等于完成。

SDD（Spec-Driven Development）这种开发范式之所以会火，正是因为 /goal 这种自治循环的工具开始普及。

工具变了，写需求的方式也得跟着变。

最后

我想了一下 /goal 这件事。

它不是一个新功能。它是 AI 工具开始接管自我验证这一环的信号。

以前 AI 干完活，得有人盯着。

现在 AI 干完活，AI 自己（或者另一个 AI）判断它是不是真做完了。

人从盯着退了一步——退到定义合约这一步。

但合约能不能定义清楚，决定了这件事最后值不值。

工具越强，人的判断越重要。