6 月 15 日，Codex App 和 Codex CLI 同时补强了 Goal（持续目标）工作流。

Codex App 增加了 Goal 的输入框快捷入口，暂停、恢复、编辑和清除也更顺手；Codex CLI 0.140.0 则解决了一个很实际的问题：大段文字、超长粘贴内容和图片附件，目前都能完整进入 Goal，远程 App Server 会话也能保留这些内容。

不过，我认为这次更新最值得讲的，并不是“Goal 能塞更多东西了”。

OpenAI 官方文档给出了一套更省力的用法：

先用普通话描述需求
→ 用 /plan 和 Codex 把问题聊清楚
→ 让 Codex 帮你起草 Goal
→ 检查 6 个关键条件
→ 再启动长期执行

以前我们担心自己不会写 Goal，怕漏掉验收标准、修改边界和停止条件。目前，用户只要先把真实需求说清楚，Codex 可以根据项目、讨论结果和附件，整理出一份更完整的任务合同。

这项能力真正减少的，是任务开始后来反复补一句“继续”“再试一次”“别忘了跑测试”的次数。

一、普通提示词和 Goal，差别在有没有“终点线”

普通提示词解决的是下一步。

列如：

检查登录功能为什么偶尔失败。

Codex 可能读取代码、运行一次测试、给出一个判断，然后停下来等你回复。

接下来你往往还要继续发：

把问题复现出来。
继续找根因。
试着修一下。
再跑测试。
还有失败就继续处理。

Goal 解决的是整段过程。

它会把一个持续目标挂在当前 Thread（线程）上。Codex 每完成一轮工作，就会重新检查证据：目标是否已经达到、测试是否通过、还有没有阻塞。如果条件没满足，Goal 依旧有效，而且预算允许，Codex 可以根据刚得到的结果选择下一步。

两种工作方式可以这样理解：

普通提示词：
提问 → 工作 → 返回结果 → 等待下一句话

Goal：
工作 → 检查证据 → 继续或完成

所以，Goal 特别适合这些任务：

• 难以一次找到根因的 Bug；
• 需要反复跑测试的框架升级；
• 必须达到某个数值的性能优化；
• 步骤会随着新证据变化的代码审查；
• 需要最终报告和证据清单的研究任务。

改一行文字、解释一个报错、做一次简单代码审查，继续用普通提示词更省事。

二、Codex 的确 能帮你写 Goal，但要先给它真实上下文

“自动写 Goal”需要说准确。

Codex 不会凭空替你决定项目目标。更可靠的流程是：用户先描述想完成什么，Codex 再根据当前项目、对话和附件起草 Goal。

例如，不要一上来硬写一大段复杂命令。先自然地告知它：

我想把这个旧项目升级到新版框架。

页面外观、公开 API 和数据库结构都不能变。
你先检查仓库，确认当前版本、主要依赖和测试情况。
遇到不清楚的地方先问我。

然后切到 Plan（规划）模式：

/plan

在 Plan 模式里，让 Codex 完成三件事：

• 读取项目，确认真实现状；
• 找出影响目标的依赖、测试和风险；
• 向用户询问少量必须回答的问题。

等讨论清楚后来，再发：

根据刚才的项目检查和讨论，
帮我起草一份强 Goal。

请补齐最终结果、验收依据、不能破坏的内容、
允许修改的范围、每轮失败后的处理方法，
以及什么情况下应该停止并向我报告。

先把 Goal 草稿给我检查，不要立即执行。

这一步很关键。

让 Codex 先给草稿，用户检查后再激活，比一句“帮我完成升级”直接放它长时间运行更稳。

三、一份强 Goal，最好补齐这 6 个关键条件

OpenAI 官方把高质量 Goal 拆成 6 个部分。为了方便记忆，可以把它们理解成一份任务合同。

以前许多 Goal 只写了第一项：

/goal 把项目升级到新版框架

这句话看似清楚，实际留下了许多空白：

• 升级到哪个具体版本？
• 怎样才算升级完成？
• 现有页面变样了算不算失败？
• 能不能顺手改数据库？
• 测试失败后可以尝试多少种方案？
• 依赖不兼容时是继续硬改，还是停止报告？

Codex 帮你写 Goal 的价值，就是根据项目和对话，把这些空白补出来。

四、从一句模糊需求，变成一份可执行 Goal

还是用“升级旧项目”做例子。

用户最开始只说：

把这个旧项目升级一下，功能不要坏。

经过项目检查和 Plan 讨论后，可以让 Codex 整理成这样的 Goal：

/goal 将当前项目升级到目标框架版本，
并保证现有公开功能正常运行。

最终结果：
项目能够完成依赖安装、构建和启动，
主要页面与升级前保持一致。

验收依据：
运行现有单元测试与集成测试；
执行生产构建；
使用浏览器检查登录、首页和核心业务流程；
输出升级前后的依赖变化与测试报告。

保护条件：
不修改公开 API；
不改变数据库结构；
不删除现有功能；
不为了通过测试而降低断言标准。

工作边界：
只修改应用源码、依赖配置、构建配置和相关测试；
不要修改生产数据、账号设置和外部服务配置。

迭代规则：
每完成一个小阶段就运行相关测试；
失败时先记录证据，再选择影响范围最小的修复方案；
不要连续重复同一种失败方案。

停止条件：
测试、构建和核心页面检查全部通过时完成；
如果关键依赖没有兼容版本，或必须改变公开 API 才能继续，
停止执行并报告已尝试方案、证据、阻塞缘由和需要用户决定的事项。

这份 Goal 没有规定 Codex 每一步必须怎么做，却把结果、证据和边界规定清楚了。

Codex 可以根据实际情况调整路线，但不能用一句“应该已经好了”宣布完成。

五、0.140.0 让长文、截图和附件真正进入 Goal

过去复杂需求还有一个麻烦：Goal 输入过长，或者从需求文档复制了大段内容，部分信息可能没有完整进入持续目标；图片附件在某些会话里也容易丢失。

Codex CLI 0.140.0 专门补了这一块。

目前 /goal 可以保留：

• 超长 Goal 文本；
• 一次粘贴进来的大段需求；
• 图片和截图附件；
• 远程 App Server 会话里的 Goal 内容。

这让下面几种任务更适合 Goal：

产品需求文档 + 当前仓库
UI 截图 + 页面验收标准
错误日志 + 复现步骤
论文 PDF + 实验目标
迁移清单 + 不能破坏的接口列表

列如做页面改造时，可以把目标截图放进当前线程，再让 Codex 起草 Goal：

根据我上传的截图和当前页面代码，
起草一份页面改造 Goal。

最终页面需要对齐截图中的布局、间距和信息层级；
保留现有业务逻辑和接口；
验收时使用浏览器截图对比、构建结果和交互测试。

先给我草稿，不要立即执行。

截图不再只是第一轮的参考，它可以成为 Goal 的验收依据之一。

六、检查草稿后，再用 /goal 真正启动

Codex 给出草稿后，先检查 5 个地方：

• 完成标准是否能实际验证；
• 有没有写清不能破坏的内容；
• 修改范围是否过大；
• 失败后来是否会无限重复；
• 阻塞时是否知道应该停下来问人。

确认没问题后，把整理好的内容设置为 Goal。

直接输入：

/goal

然后粘贴最终版本，或者让 Codex 根据刚才确认的草稿设置 Goal 并开始执行。

如果命令列表里看不到 /goal，可以运行：

codex features enable goals

也可以在用户配置文件中开启：

[features]
goals = true

提议先更新 Codex：

npm install -g @openai/codex@latest
codex --version

使用 Homebrew 的朋友可以执行：

brew update
brew upgrade --cask codex
codex --version

Goal 从 Codex 0.128.0 开始提供；想要完整保留长文本、大段粘贴和图片附件，提议升级到 0.140.0 或更新版本。

七、运行中可以继续指导，也可以随时暂停

Goal 激活后来，不代表用户把控制权全部交出去了。

Codex App 会在输入框上方显示 Goal 进度，并提供暂停、恢复、编辑和清除入口。用户也可以继续发送消息，补充新证据或调整方向。

CLI 中常用的命令有：

/goal
/goal pause
/goal resume
/goal clear

它们分别用于查看当前 Goal、暂停、恢复和清除。

例如 Codex 正在反复修改测试，却忽略了真实页面，可以先暂停：

/goal pause

补充要求：

先不要继续修改代码。

我发现问题只在 Windows 上出现，
请把这个条件加入 Goal 的验收范围，
并补充 Windows 下的复现和验证步骤。

确认更新后的 Goal 没问题，再恢复：

/goal resume

需要注意，Goal 的自动继续很克制。

它只会在线程空闲、没有用户消息排队、没有其他工作等待，而且仍在预算内时继续。遇到中断、预算限制、重复阻塞或必须由用户决定的问题时，应该停止并汇报。

八、最后提炼：先让 Codex 写任务合同，再让它连续执行

这次 Goal 工作流可以浓缩成 6 步：

描述真实需求
→ /plan 检查项目并讨论
→ 让 Codex 起草 Goal
→ 检查 6 个关键条件
→ /goal 激活
→ 用证据决定继续还是完成

最值得直接复制的一句话是：

根据当前项目、刚才的讨论和我上传的附件，
帮我起草一份强 Goal。

请补齐最终结果、验收依据、保护条件、工作边界、
每轮失败后的迭代规则和阻塞停止条件。

先给我草稿检查，不要立即执行。

Goal 的作用不是让 Codex 无限制地自己跑。

它更像一份持续有效的任务合同：目标一直留在线程里，Codex 可以根据新证据继续选择下一步；是否完成，则要由测试、日志、基准、截图或最终文件来证明。

以前长任务最常见的交流方式，是用户隔几分钟补一句“继续”。

目前更稳的做法，是先让 Codex 根据项目和讨论写好 Goal，再由用户确认什么叫完成、什么不能动、什么时候必须停。

会不会写复杂 Goal，已经不再是使用门槛。真正重大的是，用户能不能把最终结果和验收证据说清楚。