如何让 Codex 像牛马一样不停工作！新手教程端上来了

最近 Codex 悄悄上线了一个很棒的新功能：Goal 模式。

很多朋友都在问我这个到底有什么用，这篇文章给大家系统性讲解。前半部分是使用方法，后面有一些原理分析，所以如果你只想看看怎么用，不用浪费时间，看完自己上手试试！

使用

以前你给 Codex 发 prompt，它更像一次性响应：你说“修这个 bug”，它修一轮，汇报结果，然后等下一句。Goal 模式不一样，你给它的内容不再只是一句“去做什么”，还包括“做到哪里算完”“拿什么证明”“中间别碰什么”“卡住了怎么说”。

所以我说让 Codex 像牛马一样不停工作，说的是一种可控的执行状态：目标挂着，活继续干，证据要回来，不能靠“我感觉差不多了”收工。

普通 prompt 解决的是“你现在做什么”，Goal 解决的是“你做到什么程度才算收工”。这个差别很要命，因为很多复杂任务麻烦的地方，从来不在第一步，而在第二步、第三步会随着现场变化。

你让 Codex 修一个测试，它可能先发现测试挂了，再发现依赖版本有问题，再发现 mock 写歪了，再发现修完以后另一个模块爆了。普通 prompt 到这里会变成你推一下它走一步，Goal 则让它沿着同一条完成线继续找路。

基本功能

用法很简单。如果你的 Codex Desktop 版本支持 Goal，你的右下角加号就应该有：

在 Goal 运行的过程中，还有如下便捷的功能：

• 编辑目标

在实现目标过程中，可以随时编辑目标

• 暂停

• /side

/side能打开一个侧边栏实时让你监控 Goal 实现的进度，你可以问它比如“目前目标完成到什么程度了？”，然后根据实际情况进行调整等

如何写Prompt

一个烂 Goal 长这样：

/goal 把这个项目优化好

强一点的 Goal，要钉住六件事：结果是什么，用什么验收，哪些东西不能退化，它能动哪些文件、命令、资料和工具，每次尝试以后怎么选下一步，什么时候应该停下来报阻塞

一个好的 Goal：

/goal 写一篇中文 X Article，主题是“我怎么用 Codex 清掉一个烂尾测试套件”。
读者是已经会用 AI 写代码、但经常被半成品气到的人。
开头从一次失败测试越修越多讲起，后面写清楚怎么拆目标、怎么验收、怎么处理跑不通的命令。
不要写成官方教程，不要夸 AI 神奇，要像一个人刚踩完坑回来记账。
完稿前自己挑出三处最像套话的地方改掉，并给出两张配图建议。

这里还有一个小技巧：如果你一开始不知道怎么写 Goal，先让 Codex 帮你把人话翻成工单。别让它直接开干，先让它反问缺口，比如最终状态够不够具体、验收能不能跑、边界有没有危险、阻塞时该找你要什么。

然后别急着启动，先审它的草稿：验收有没有写清，边界有没有太大，有没有把“感觉变好”这种玄学留在里面，阻塞时会不会老实停下来

原理

Goal 是当前线程的持久状态，它不会变成全局记忆，也不会自动污染整个项目，只跟这条线程里已经发生过的东西绑定：读过哪些文件，跑过哪些命令，改过哪些 diff，看过哪些日志，积累了哪些证据。Codex 能继续，也并没有获得无边界自主权。线程里只是多了一张长期可见的工单，工单上写着目标、生命周期、预算和进度，系统会在合适的时候检查：

目标还 active 吗，线程空闲吗，有没有用户输入排队，预算够吗，上一轮有没有真的调用工具做事。只有这些条件都合适，它才继续往下干。Goal 不会让 AI 自动循环到天荒地老，它更像一个保守调度器：能继续时继续，该等人时等人，被打断就停，预算到了就汇总，没产生实际动作就别空转。

这点不酷，反而好用。工作里困难的的，是那种不知道什么时候该停、不知道该用什么证明自己干完、还喜欢把半成品包装成胜利的 AI；Goal 把它往回拽到三件笨事上：什么时候停，拿什么交账，卡住了怎么说。

官方 Cookbook 里有个量化论文复现的例子，我觉得很适合理解这件事。复现一篇论文，跑不出来很正常，很多论文缺随机种子、训练路径、检查点、完整模拟状态；要命的是，你跑出了一点接近结果，就顺手写成“成功复现”。

一个好的研究 Goal，会要求 Codex 把结论分账：哪些机制重建了，哪些数值只是近似，哪些图表有证据支撑，哪些地方被源材料挡住了，哪些不确定性还留着。

这套账本思维放到写代码也一样。测试全绿是一种证据，benchmark 过线是一种证据，截图和人工检查是一种证据，日志里没有重复报错是一种证据，用户故事被覆盖、旧路径能回滚、文档能构建，也都是证据。

Goal 有用的地方就在这里：它不鼓励 Codex 更会吹，它逼 Codex 更会交账。

当然，Goal 也别滥用。改一行文案，解释一个报错，做一次简单 code review，或者只是想问一个答案，这些都不用把牛马牵出来上全套马具。

我一般这样判断：路要边走边看，终点又能验收，就可以考虑 Goal。迁移、调优、排查、重构、研究、长文、配图、原型、eval 调参，都属于这一类。第一步做完以后，后面会冒出新情况；中间怎么绕，到头来都得拿证据交差。

再粗一点分：一两轮对话能拿到答案，用普通 prompt；需要 Codex 自己读文件、跑命令、改东西、再根据结果决定下一步，而且你能写出验收条件，就用 Goal。别给所有任务都套规格，本来就会拖成多轮的活，才需要一条完成线。

还有一个很现实的场景：你要离开一会儿。让 Codex 跑一轮测试、修一组失败 case、整理一批资料、生成一套配图，普通模式下你回来可能只看到它做了一小段，然后停在“请确认下一步”。Goal 写得够清楚，它可以继续往下走，回头给你一张带证据的进度账。这个时候它就真的有点像牛马了：你不用一直盯着，它也能把可执行的部分往前拱。

让 Codex 像牛马一样不停工作，喊“加油”没用，把一句 prompt 写到两千字也没用。你要告诉它：今天干什么，干到哪里收工，拿什么验收，哪些地方不许碰，卡住了怎么报，预算到了怎么结账。

人也没有完全退场，只是从“每十分钟催一次工”，换成了“先把活定义清楚，再看它有没有拿证据回来”。这就是现在跟 AI 干活绕不开的一段：模型可以连续执行，人得负责判断目标和验收。

没有 Goal 的 Codex，像一个反应很快的临时工

有了 Goal，它才像一个愿意加班的牛马。

前提也很朴素：你得先把工单写明白。