我让 Codex 自己跑了一整夜：/goal 长跑实战，和我踩的那些坑

25 小时，1300 万 token，3 万行代码，中间没人管。这不是发布会数字，是 Codex 的 /goal 真能干出来的事。前提是，你得会喂它。

先看这组数字

25 小时。约 1300 万 token。约 3 万行代码。全程无人值守。

这是一个公开实验里的结果：把 GPT-5.3-Codex 开到 Extra High 推理档，丢给它一个空仓库，一句话：「从零搭一个设计工具」。然后它就自己跑起来了。规划、写代码、跑验证、撞了 bug 自己修，一路干了整整一天一夜。最离谱的是，跑到第 20 多个小时，它居然还没跑飞，还在 spec 上。

这背后是 Codex 的 /goal 模式，OpenAI 那帮人内部管它叫「Ralph loop」。我上周末照着试了一把，把一个拖了很久的小项目交给它跑了一晚。

结论是：这玩意是真能用，但它能不能跑出活，90% 取决于你前半小时怎么喂它，跟模型多聪明关系反而没那么大。

/goal 到底是个什么东西

平时你用 Codex 或者 Claude Code，是这么个节奏：你说一句，它干一步，停下来等你下一句。一问一答，你是司机，它是副驾。

/goal 把这个反过来了。你给它一个目标，它自己进入一个循环：规划下一步，干，检查自己的产出，发现错了就纠偏，接着干，直到目标达成，或者撞上一堵它自己翻不过去的墙。

换句话说，你从「司机」变成了「甲方」。需求拍下，人就可以去睡觉了。

听着很爽是吧？我一开始也这么觉得。然后我就栽了第一个跟头。

我栽的第一个跟头：prompt 根本不够

我第一次跑，信心满满写了一段我觉得挺详细的目标描述，七八行。敲下 /goal，泡了杯茶，回来一看，它产出的东西，跟我用普通 prompt 一句句催出来的，没什么两样。

后来我翻到一个开发者的原话，差点笑出声，因为太贴了：「我手写的任何 /goal prompt 都不够好。它产出的结果，跟一个普通 prompt 没区别。」

问题出在哪？人类天生低估 agent 需要知道多少。我们脑子里那些「这还用说吗」的默认假设，它一个都不知道。

我后来盯着它跑了一个小时，越看越脸红：我漏了至少 3 条约束、2 条验收标准，还有一整个架构假设。我以为我说清楚了，其实我只说了我自己懂的那部分。

救命技巧一：让它先帮你写 prompt

栽完跟头，我学乖了。最有用的一招，叫元提示（meta-prompting）。

别自己硬写那段 /goal。先让模型帮你把目标扩写成一份够格的 /goal prompt。你把粗想法甩给它：「我要做个 X，帮我把这个写成一份完整的、给自主 agent 用的目标说明，把所有你需要我澄清的地方都列出来问我。」

它会反过来追问你：用什么技术栈？这个边界情况怎么处理？算「完成」的标准是什么？把你脑子里那些没说出口的默认值，一个个逼出来。

等这一轮问答结束，你手里那份 prompt，比你自己硬憋出来的强十倍。五分钟的追问，省下后面几个小时的跑偏。这一步我现在雷打不动。

救命技巧二：给它一个外置大脑

第二招更关键，也是那个 25 小时实验能跑成的真正原因：持久化项目记忆。

道理很简单。一个 agent 跑 25 小时，中间 context 会换了一茬又一茬，它早就「忘」了最开始你说过啥。所以不能把信息只放在对话里，要落到磁盘上。

我现在的做法是，开跑前在项目里铺好几个 markdown 文件：spec.md 写死规矩，plan.md 写拆好的步骤，todo.md 是任务清单、每条带一个可验证的完成标准，status.md 让它自己记跑到哪了。

然后在 /goal 里明确告诉它：每干一步，回去读这几个文件，干完更新 status.md。这样哪怕它跑了一整夜、context 翻了十遍，磁盘上这几个文件就是它的「外置记忆」，随时能回看，不会跑着跑着把自己跑丢。

那个 14 小时跑通设备驱动项目的案例，核心也是这套。

让它真能跑长的三件套

把上面两招归拢一下，再加一条，就是让 /goal 真正跑得久的三个硬件。

第一，一句「别停」的指令。你得在 prompt 里白纸黑字写明：不要停下来等我，持续干，直到全部完成。不写这句，它干两步就习惯性回来问你了。

第二，一份带验证步骤的 todo。光列任务不够，每条任务后面得跟一个「怎么算这条做完了」，跑哪个测试、看哪个输出。没有验证锚点，它会自我感觉良好地宣布「做完了」，其实啥也没编译过。

第三，高推理档。复杂任务一定开 High 或 xHigh。那个 25 小时实验用的就是 Extra High。档位低了，长程任务上它会越跑越飘。

这三件套缺一个，长跑大概率半路死。

必须说的坑：它不是真·永动机

吹了这么多，得泼盆冷水，免得你半夜醒来发现啥也没跑。

最大的坑：Codex 的 automations 本质是本地 cron job。说人话，你的电脑关机了、Codex app 关了，它就不跑了。它不是云上有个服务器替你 24 小时盯着。我第一晚就差点中招，本来想着合上笔记本去睡，幸好多看了一眼文档。后来我是让机器整夜开着、app 挂着，才跑完的。

第二个坑：它不会自己判断「做完了没」，也读不懂模糊需求。这就是为什么前面那两招那么重要。你目标定义得不彻底，它要么无限 loop，要么默默跑偏到南极去。

说实话，写到这儿我自己都有点犹豫：这套流程门槛其实不低。它不是「一句话躺平出活」，更像是「你先当半小时产品经理，把需求抠死，然后才敢撒手」。

上手配方：你可以直接

废话不多说，给你一份能直接照做的最短路径。

• 装好环境。npm 全局装 Codex CLI，OpenAI API key 设进环境变量，建个项目目录，git init（强烈建议，出岔子能回滚）。

• 别自己写 goal，让模型先写。把粗想法丢给它，要它扩写成完整目标说明，加反问你所有不清楚的点。答完。

• 铺外置记忆。项目里建 spec.md、plan.md、todo.md、status.md，todo 每条带验证标准。

• 进交互会话，敲 /goal，后面跟你那份打磨好的目标，并写明「持续干别停、每步回读那几个 md、干完更新 status」。

• 开 High 或 xHigh。

• 机器和 app 整夜别关。早上来看 status.md 和 git log，验收。

谁该试，谁先别碰

适合的活：边界清楚、能写出明确验收标准的。脚手架搭建、批量重构、按 spec 从零起一个小工具、写一大片测试。这种「方向定了，就是体力活」的任务，/goal 跑一夜顶你干一周。

先别碰的活：需求还没想清楚、探索性强、得边做边拍板的。这种你撒手它一定跑偏，还不如你坐那儿一问一答。

我现在的用法是：白天用普通对话模式跟 Claude Code、Codex 你一句我一句地探索、定方向；方向定死了、能写出验收标准了，才打包成一个 /goal，扔给 Codex 跑一晚上。探索归人，体力归机器。

这套我还在调，持久记忆那几个文件怎么写最省事，我也没完全摸透。但有一点我现在很确定：/goal 不是让你偷懒的，是把你的工作从「敲代码」前移到「把需求抠死」。前半小时你越较真，后面这一整夜它给你的回报就越大。

你要是也跑了一夜，第二天早上你那台机器变成了啥样？回来跟我聊聊。