-goal 理论和实践全解 - 让 Codex 和 Claude Code 连续跑数小时直到完成目标的自主任务模式怎么用好？

公众号名称：AI 启蒙小伙伴

作者名称：邵猛

发布时间：2026-05-13 08:06

OpenAI Codex 前几天推出了 /goal，让 Codex 自主循环数小时直至达成目标，中间完全不间断不需要人介入，很多朋友包括我自己也在尝试，睡前把复杂任务交给 /goal，睡醒发现任务居然真的顺利且正确的完成了！

https://developers.openai.com/codex/use-cases/follow-goals

而一直被认为是 Coding Agent 标杆的 Claude Code 也紧随其后推出了 /goal！

https://code.claude.com/docs/en/goal

OpenAI 和 Anthropic 两个最顶级 AI 团队和最强竞争对手，又一次同时选择了 /goal，这个完全自主 Agent 方向，今天咱们一起看看他们对 /goal 的不同定义和最佳实践。

Codex 官方对 /goal 的定义与用法
Claude Code 官方对 /goal 的定义与机制
Codex 和 Claude Code 两家差异对比
OpenAI 工程师 Chris Hayduk 的实战案例与落地方法论

Codex `/goal`：契约式的长跑任务

1.1 功能定位

/goal 让 Codex 持续朝一个目标推进，而不是在一轮对话后停下。启用后，Codex 可以独立运行数小时，无需用户介入每一步。

当前为 Codex 的实验性功能，需要显式开启：

在 /experimental 中启用，或
在 config.toml 中添加 goals = true 至 [features]

1.2 控制命令

命令	作用
`/goal <目标>`	设定目标并开始执行
`/goal`	查看当前目标状态
`/goal pause`	暂停
`/goal resume`	恢复
`/goal clear`	清除目标

1.3 适合的工作类型

官方明确给出标准：比单条 prompt 更大，但比开放式 backlog 更小。

适合：

代码迁移：目标技术栈、对等性检查、约束都明确
大型重构：每个 checkpoint 后都能跑测试
原型 / 游戏 / 实验：Codex 可以持续打磨一个能跑的产物

不适合：一堆相互无关的零散任务清单。

1.4 设置循环的六步法

命名一个目标和一个停止条件
指明 Codex 必须先读哪些文件、文档、issue、日志或计划
定义”能证明进度”的命令或产物
要求 Codex 按 checkpoint 工作并维护一份简短的进度日志
用 /goal 检查运行状态
在完成、阻塞或方向变更时，用 pause / resume / clear 控制

1.5 核心思想：契约思维

Codex 必须在开始前就知道”完成”意味着什么。

一个目标契约要回答四个问题：

要达成什么
不能改动什么
如何验证进度
何时停止

举例：

迁移类目标：“新路径通过契约测试，旧路径仍保留可回滚方案”
原型类目标：“应用能构建、能启动，并匹配输入参考或预期行为”

1.6 长跑期间的协作方式

运行过程中应向 Codex 索要精简进度报告：当前 checkpoint、已验证什么、还剩什么、是否阻塞。

如果状态报告开始变得空泛，应该收紧目标本身，而不是叠加临时指令。

把 /goal 当成后台任务对待——Codex 在合理确信达成停止条件时才停。

1.7 三类典型案例

迁移：游戏迁移到新栈、移动应用迁移到新平台、代码库迁移到新框架
原型创建：新应用、新游戏、新功能从零做出抛光的初版（推荐用 PLAN.md 描述目标）
Prompt 优化：基于 eval 套件迭代——检查失败用例、改 prompt、重跑 eval，直到分数达标

Claude Code `/goal`：可验证的完成条件

2.1 功能定位

/goal <条件> 设定一个完成条件。Claude Code 持续工作直到条件满足；条件达成后目标自动清除。

适用场景示例：

把模块迁移到新 API，直到所有调用点编译通过且测试通过
实现 design doc，直到所有验收标准成立
拆分大文件，直到每个模块低于规模预算
处理 issue 队列，直到清空

2.2 评估机制（关键设计）

每一轮结束后：

当前条件 + 已有对话内容被发送给一个小型快速模型（默认 Haiku）
评估器返回一个 yes/no 判断和简短理由
No → 把理由作为下一轮的指引，让 Claude Code 继续
Yes → 清除目标，在 transcript 中记录”已达成”

执行模型与评判模型分离——避免”自己评自己”的偏差。

评估器不会主动调用工具，只能依据对话中已经出现的内容做判断。这意味着：条件必须是 Claude 自己的输出能证明的东西。比如”test/auth 下所有测试通过”——Claude Code 跑了测试、结果落进了 transcript，评估器就能判断。

2.3 写出有效条件的三要素

一个可度量的终止状态：测试结果、构建退出码、文件数量、空队列
明确的证明方式：例如 npm test 退出码为 0、git status clean
过程中不可违反的约束：例如”不修改其他测试文件”

补充约定：

条件最长 4000 字符
可加入兜底子句，例如”或在 20 轮后停止”，防止无限循环

2.4 与其他自主工作流的区别

方式	下一轮何时启动	何时停止
`/goal`	上一轮结束后立即	评估模型确认条件达成
`/loop`	时间间隔到达	用户停止，或 Claude 判断完成
Stop hook	上一轮结束后	用户的脚本或 prompt 决定
Auto mode	（不启动新轮）	Claude 自己判断完成

/goal 与 Auto mode 互补：Auto mode 免去逐工具调用确认，/goal 免去逐轮人工触发。

2.5 工程化细节

会话级：一个 session 同时只允许一个 active goal
可恢复：--resume / --continue 时活跃目标会被恢复，但计时和 token 计数重置

可无头运行：

claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

状态可见：界面有 ◎ /goal active 指示器；/goal 无参数即查看条件、运行时长、轮数、token 花费、最近一次评估理由
成本可控：评估走小型快速模型，相对主循环开销基本可忽略
安全边界：需要 workspace trust；如果策略禁用了 hooks，命令会显式提示而非静默失效

2.6 常用命令

命令	作用
`/goal <条件>`	设置/替换目标，立即开始执行
`/goal`	查看当前状态
`/goal clear`	提前清除目标（别名：`stop` / `off` / `reset` / `none` / `cancel`）

Codex 与 Claude Code 的差异

维度	Codex `/goal`	Claude Code `/goal`
评估机制	未公开细节，强调”合理确信”	显式小模型评估器 + Stop hook
控制命令	`pause` / `resume` / `clear`	`clear`（含多种别名）
文档侧重	契约思维、checkpoint、长时独立运行	评估器架构、可恢复、headless
上限/边界	强调用 `PLAN.md` 引导	单条件 4000 字符；可加轮数兜底
典型案例	迁移、原型、prompt 优化	测试通过、规格落地、队列清空

共同点远大于差异：两者都是同一抽象——带终止条件的自主循环：

执行 → 验证 → 判断是否达标 → 达标则停，否则继续

差异主要在评估实现的透明度和交互式控制粒度上。

实战案例：Chris Hayduk 的 `/goal` 落地经验

OpenAI 工程师 Chris Hayduk 在 Codex 内部和个人项目中大量使用 /goal，沉淀出一套可直接套用的方法论。这些经验把官方文档里的”应该怎么做”翻译成了”具体怎么做才不翻车”。

4.1 案例一：NeurIPS 论文转 ICML 格式

背景：ICML 有数百条格式与风格约束，分散在 LaTeX 模板里，难以直接评分。

做法：

先让 Codex 把所有规则抽取为一份 200+ 条目的 checklist.md
设定目标：

“根据 checklist.md 把 NeurIPS 论文改为 ICML 格式，且不改变任何技术内容。”
要求 Codex 在完成每条时勾选 checklist，把进度持久化到文件系统

关键洞察：把”整体合规”拆成”逐项勾选”——单条规则的判断比整体判断容易得多。这是连接”模糊愿望”和”可验证条件”的通用桥梁。

4.2 案例二：搜索改进的蛋白质结构模型架构

背景：完整训练一次要数天，循环根本跑不动。

做法：用 NanoFold（小型但充分采样的数据集）做实验，把单轮评分耗时从”数天”压缩到”数分钟”。

关键洞察：在不损害评分质量的前提下，用一切手段压缩单轮反馈耗时。反馈回路越紧，循环越有效。

4.3 模糊目标的两种死法

模糊指令	失败模式
让我的代码变得更好	过早放弃：跑几分钟就停
改进我的算法	永不停止：盲目反复修改，追逐无法满足的目标

改写后：

将 specific_file 中代码的运行时间减少 20%，且不引入任何单元测试和集成测试的回归。

包含两要素：量化指标（runtime −20%）+ 约束条件（测试不回归）。

4.4 三份 Markdown 文件作为外部记忆

即便有上下文压缩，模型也难以在数小时甚至数天的跨度上保持思路连贯。把”思考状态”外化到文件系统是最便宜可靠的解法：

文件	作用	写作风格
`PLAN.md`	高层计划，可预先写入种子思路	结构化大纲
`EXPERIMENTS.md`	最关键——结构化的尝试记录	标题 / 做了什么 / 结果
`EXPERIMENT_NOTES.md`	实时草稿本	按时间顺序的思考流水

EXPERIMENTS.md 是最重要的一份：它让人和 Agent 都能复盘”试过什么、为什么成功或失败”，防止长循环中反复尝试同一个失败方案。

4.5 落地三原则

把官方文档与上述经验合并，可以提炼为三条硬性要求：

目标可度量 —— 让循环知道何时该停
验证可执行 —— 让循环跑得快且可信
状态可外化 —— 让循环跑得久也不丢失上下文

满足这三条，Codex 与 Claude Code 就能在硬问题上稳定地”独自磨”数小时甚至数天；不满足，循环要么提前放弃，要么永不收敛。

总结

/goal 不是让人少打字的快捷键，而是把人类从”逐轮审阅”中解放出来、要求在起跑前把”什么是完成”定义清楚的协作契约。

它对提示词工程提出了根本性转变：

日常 Chat 像聊天 —— 依赖模型善意理解
/goal 模式像写验收标准书 —— 依赖人自己的需求工程能力

下次准备启动一个长跑任务前，先停下来问自己三个问题：

怎样算完成？（能用一个命令、一个数字、一份 checklist 来表达吗？）
每轮怎么验证？（这个验证够快、够可信吗？）
进度记在哪？（断了上下文之后，模型还能接着干吗？）

三个问题都答得出来，再敲下 /goal。

Codex ​/goal：契约式的长跑任务