Codex 与 Claude 的 /goal 模式对比（二）

(接上文)

最关键的差异

两者都叫 /goal，但产品语义并不完全一样。

维度	Codex Goals	Claude Code `/goal`
作用范围	当前线程的持久状态	当前会话的活跃条件
完成判断	对照线程中的具体证据做完成审计	每轮后由 small fast model 读取对话并判断 yes/no
工具访问	Codex 工作过程中可以运行命令、改文件、收集证据	评估器本身不调用工具，只看 Claude 已展示的 transcript

维度	Codex Goals	Claude Code `/goal`
生命周期	`pause`、`resume`、`clear`，并有 budget-limited 状态	`clear` 及多个别名；活跃 Goal 可随 `--resume` / `--continue` 恢复
预算控制	文档把预算作为 Goal 状态和调度边界的一部分	常通过条件文本约束，例如“or stop after 20 turns”
继续触发	线程空闲、Goal 活跃、预算允许、无排队用户输入等安全边界	上一轮结束后触发基于 Stop hook 的评估
自动化定位	更偏向工程任务中的多轮执行与证据沉淀	更偏向会话内轻量续跑，也能配合非交互模式

一句话概括：

Codex 更重视“工作线程里的证据和生命周期”；Claude Code 更重视“每轮之后由独立评估器决定是否继续”。

这会直接影响 Goal 的写法。

在 Codex 中，你应该把测试、benchmark、产物和阻塞报告写进 Goal，让 Codex 在同一个线程里围绕证据推进。

在 Claude Code 中，你还要额外注意：评估器只能读 transcript。因此你不仅要要求 Claude 运行检查，还要要求它把关键检查结果明确展示出来。否则它可能实际做了工作，但评估器看不到足够证据。

sequenceDiagram
    participant User as 用户
    participant Codex as Codex
    participant Claude as Claude Code
    participant Eval as Claude 评估器

    User->>Codex: /goal 设定目标
    Codex->>Codex: 保存线程级目标与状态
    Codex->>Codex: 执行、测试、收集证据
    Codex->>Codex: 对照证据判断是否完成

    User->>Claude: /goal 设定条件
    Claude->>Claude: 执行一轮任务
    Claude->>Eval: 条件 + transcript
    Eval-->>Claude: yes/no + reason
    Claude->>Claude: no 则继续，yes 则清除 Goal

和 `/loop`、Stop hook、auto mode 的关系

Claude Code 文档专门把 /goal 放到几个自动化方式里对比，这部分也有助于理解它的定位。

/goal：上一轮结束后触发评估，直到模型确认条件满足
/loop：按时间间隔重复运行，直到用户停止或 Claude 判断完成
Stop hook：上一轮结束后触发，由用户自己的脚本或提示词决定下一步

auto mode：自动批准单轮里的工具调用，但不会自动开启下一轮

也就是说，Claude Code 的 /goal 可以理解为一个会话级快捷方式：你不用写 Stop hook，也不用每轮手动发“继续”。但如果你需要确定性的检查，例如运行一个固定脚本来判断是否继续，Stop hook 仍然是更可控的选择。

Codex 的资料没有把 Goal 描述成 hook 快捷方式，而是把它放在线程状态、调度、预算和证据审计的框架里。它的重心不是“用一个评估器读 transcript”，而是“让当前线程围绕明确目标持续推进，并且只有证据支持时才完成”。

什么时候选谁

如果你已经在 Codex 里处理一个复杂工程任务，尤其是性能优化、测试修复、迁移、研究复现这类需要不断收集证据的工作，Codex Goals 更贴合。它的线程级状态、生命周期控制和预算边界更适合长任务。

如果你已经在 Claude Code 里工作，想让当前会话持续推进到一个可验证条件，Claude Code 的 /goal 上手更轻。它适合“把这组检查跑绿”“按验收条件实现完”“拆完这个文件并确保每个模块低于指定行数”这类能从 transcript 判断进度的任务。

如果你的完成条件非常机械、必须确定性判断，在 Claude Code 里不要强行让 /goal 猜。用 Stop hook 跑脚本会更稳；/goal 更适合让模型评估“对话里展示的证据是否足够”。

如果任务只是一次性修改、一段解释或一个很短的 code review，两边都不必开 Goal。普通 prompt 更干净。

写 Goal 的通用模板

无论用 Codex 还是 Claude Code，一个可用的 Goal 都应该包含完成条件和证据来源。可以从这个模板开始：

1
2
3
4
/goal <最终要成立的结果>，通过 <具体检查、测试、benchmark 或产物> 验证；
同时保持 <不能回退的约束>。
每轮结束时说明 <已经尝试什么、证据是什么、下一步是什么>。
如果 <预算、轮次、时间或证据条件> 不满足，则停止并报告阻塞。

对 Claude Code，可以再加一句：

1
After each check, summarize the concrete evidence in the transcript so the goal evaluator can judge it.

这句不是形式主义。Claude Code 的评估器不读文件、不跑命令，只读对话；让 Claude 把证据写出来，就是让评估器看得见。

对 Codex，可以更强调证据标准：

1
Only mark the goal complete when the result is supported by concrete evidence from changed files, command output, test results, benchmark output, or the final artifact.

这能减少“做了一部分就宣布完成”的风险。

结论

/goal 模式背后其实是 AI 编码工具的一次产品转向：从“回答下一步”走向“围绕结果持续执行”。

Codex 和 Claude Code 的共同点，是都把“继续直到完成”从用户口头催促变成显式机制。差异在于，Codex 把 Goal 做成线程级、带生命周期和预算边界的证据契约；Claude Code 把 /goal 做成会话级、基于 Stop hook 和 small fast model 的完成条件评估。

真正用好它们，关键不在于写一个更长的 prompt，而在于把“完成”定义清楚：什么结果算成功，用什么证据证明，什么约束不能破坏，什么时候应该承认阻塞。

Goal 不应该让 Agent 无限循环。它应该让 Agent 在证据足够前不停得太早，在证据不足时也不假装完成。

Codex 与 Claude 的 /goal 模式对比（二）

最关键的差异

和 /loop、Stop hook、auto mode 的关系

什么时候选谁

写 Goal 的通用模板

结论

和 `/loop`、Stop hook、auto mode 的关系