Codex Goal 模式：你定目标，它自己干到做完

今天聊 Codex 一个很多人还没用起来的功能，Goal 模式。

你用 Codex 干过稍微大点的活吗？什么感觉？我的感觉是累。改个 bug、问个问题，一句就够。但遇到稍微复杂点的活，你给它一个指令，它干一会儿，停。你检查一下，说继续，它再干一会儿，又停。像打乒乓球，你打一下它回一下。人就变成了瓶颈：你得一直坐在那盯着，它停了你得赶紧敲下一句。活越大，你越没法走开。

Goal 模式就是来解决这个问题的。

你给它一个目标，一次性定义清楚「做完是什么样」「哪些不能动」「怎么验证」，然后你就可以走了。Codex 自己会规划步骤、干活、检查结果、决定要不要再来一轮，一直循环到目标达成或者被卡住。你不用坐在那敲下一句，该干嘛干嘛去，回来验收就行。

举个例子你就明白了。上个周末我整理一批技术文档，大概三十多个 Markdown 文件，要把里面的代码示例格式统一、过时的 API 引用替换掉、章节编号重新排。普通模式的话，改两个文件它就停了，我得看一眼说继续，再改三个又停，一整晚就耗在上面。开了 Goal 之后，我把要求一次讲清，下楼吃了个饭，回来它全改完了，还列了一张表告诉我哪些文件改了、哪些有疑问需要我确认。这种体验，跟普通提示词完全两回事。

OpenAI 官方对 /goal 有句话说得特别准：任务需要 Codex 跨回合持续工作、而且能用一个方法验证做没做完，这种情况就用 /goal。拆开来，关键词有三个：持续、可验证、停止条件。缺一个都不适合用 /goal。

把它跟普通提示词放一块比较，区别很明显。普通提示词是你让 Codex 做一件事，做完就停。你说「帮我把这篇文章翻译成英文」，它翻了，回来等你下一句。Goal 是你跟 Codex 签一份合同，定义好目标、边界、怎么验证、什么时候算完，然后它自己去推进。你说「把文件夹里所有合同 PDF 提取关键条款做成对比表，抽三份核对有无遗漏」，它自己跑。

这个区别背后，是 Codex 在本地用一套状态机追踪目标。每个 goal 有五个状态：pursuing，正在跑；paused，暂停了；achieved，已完成；unmet，无法完成；budget_limited，额度用完。它不是靠对话上下文记着的，关了终端再打开还能接着跑。

那什么时候该用 /goal，什么时候不该用？

有个很简单的判断标准：你能不能用手点几下就验证工作完成了？如果能，就适合。比如「打开三个文档检查格式对不对」「抽几条数据看分类有没有错」「网页能正常打开、主要按钮能点」。如果不能，像「排版更好看」「文案更吸引人」这种主观标准，就别用 /goal，普通提示词更合适。

具体来说，这几类活特别适合。

文档批处理。几十上百个文件要统一格式、提取信息、合并拆分、翻译。目标明确，抽几个验一下就知道了。

数据清洗整理。表格里的数据要分类、去重、补全、汇总。结果对不对，抽几条一查就清楚。

内容生成。按给定模板和素材，生成一批海报文案、产品描述、课程大纲。标准就是格式对、内容不跑题。

搭原型。不管是一个记账网页、一个客户管理小工具、还是一个自动发邮件的小脚本。标准就是能跑、功能通。

代码迁移和测试。这是程序员的活，但也是 Goal 最擅长的场景之一。把项目从旧版本搬到新版本，每搬完一批就验证有没有搬坏。

反过来，这些情况别用。需求还不清楚只是想讨论方向，用 /plan。改一行字或者翻译一篇文章，普通提示词就够。一堆不相关的待办事项，不适合捆成一个 goal。

怎么用好呢？核心就一件事：把目标写好。