Goal 模式：让它不达目标不罢休

以前你给 Codex 发 prompt，它更像一次性响应：你说"修这个 bug"，它修完就停。Goal 模式解决的是另一个问题——"做到什么程度算收工"：做到哪里算完、拿什么证明、中间别碰什么、卡住了怎么说。

以下内容来自三篇原文：J0hn《Codex 推出 goal 功能》（微信公众号，2026-05-01）讲机制与源码级拆解；@Russell3402《如何让 Codex 像牛马一样不停工作》（X，2026-05-24）教六要素写法；@freeman1266《让 Codex 在你睡觉时自己写代码》（X，2026-05-18）给夜间无人值守的工程实践。结构按机制 → 写法 → 夜间实战展开。

以下来自 J0hn：OpenAI 给 Codex CLI 加了个实验性新命令 /goal。你设一个目标，它就在同一个会话里跨多轮持续迭代，不达目的不罢休。

版本与开启：Codex CLI 0.128.0+，在 ~/.codex/config.toml 里加一段手动开启——目前仅 CLI 可用，桌面应用暂无：

复制[features]
goals = true

基本命令：

复制/goal 重构所有的数据库查询，添加连接池   # 设目标，开始持续工作
/goal pause      # 暂停
/goal resume     # 恢复
/goal clear      # 清除

Ctrl+C 中断会自动暂停，下次恢复线程自动继续。长指令技巧：目标描述太长就写成 .md 文件，用 /goal follow instructions.md 执行——放文件里还不会被上下文压缩丢细节。

/side 命令：不打断主线目标，临时开分支会话问问题，问完按 Esc 回到主线，分支直接丢弃（作者调侃本可叫 /btw）。@Russell3402 的用法：/side 打开侧边栏实时监控进度，可以问它"目前目标完成到什么程度了"，再根据实际情况调整。

以下来自 J0hn：让 AI 自己循环跑，最怕三种死法——空转烧钱、偷懒交差、自己骗自己。/goal 配了三重防护：

① 零工具调用抑制：一轮续跑中没调任何工具（没写代码、没跑命令、没读文件）→ 判定卡住，自动停止循环，等新输入再触发。

② 预算控制：可设 token 预算和时间上限，超预算时注入提示让模型停止开新任务、总结进展、给明确下一步。关键细节：token 只统计非缓存输入 + 输出，缓存命中不计费——预算追踪的是"新增工作量"。

③ 完成审计协议：每次续跑注入隐藏 developer 指令——拆解可交付物 → 建检查清单并映射到实际证据 → 检查真实文件/输出/测试结果 → "测试通过"不能等于"目标完成"。防范"代理证据接受"（proxy-evidence acceptance），即把"产出了东西"错当成"达成了目标"。

防偷懒设计：模型只能通过 update_goal 把目标标记为 Complete，不能暂停或恢复——暂停/恢复只有用户能做（源码显式报错 "update_goal can only mark the existing goal complete"）。

以下来自 J0hn：Ralph Loop 得名《辛普森一家》的 Ralph Wiggum，由开发者 Geoffrey Huntley 命名。社区原始实现是「接力赛」——每轮从头开新上下文，靠 git 记录和进度文件交接；而 Codex 的 /goal 是进程内持续循环，同一会话跨轮次保持活跃，是「马拉松选手」（不换人，可暂停）。

以下来自 @Russell3402：一个烂 Goal 长这样：

复制/goal 把这个项目优化好

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

一个好的 Goal 长这样（可复制，照着改）：

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

小技巧：一开始不知道怎么写 Goal，先让 Codex 帮你把人话翻成工单。别让它直接开干，先让它反问缺口：最终状态够不够具体、验收能不能跑、边界有没有危险、阻塞时该找你要什么。然后别急着启动，先审它的草稿：验收有没有写清，边界有没有太大，有没有把"感觉变好"这种玄学留在里面，阻塞时会不会老实停下来。

以下来自 @Russell3402：Goal 是当前线程的持久状态——不变成全局记忆、不污染项目，绑定已读文件、跑过的命令、diff、日志、证据。保守调度器：目标 active、线程空闲、无用户输入排队、预算够、上一轮真调用了工具，才继续。注意最后一条：它和"零工具调用抑制"是同一逻辑——是"完成线"不是无限循环。

证据思维：测试全绿、benchmark 过线、截图人工检查、日志无重复报错、用户故事覆盖、旧路径可回滚、文档可构建。

官方 Cookbook 的论文复现例子就是结论分账：哪些机制重建了、哪些数值近似、哪些图表有证据、哪些被源材料挡住、哪些不确定性留存。

何时用 Goal 的判断标准：一两轮能拿到答案 → 用普通 prompt；需要 Codex 自己读文件、跑命令、改东西再根据结果决定下一步，且你能写出验收条件 → 用 Goal。适用：迁移、调优、排查、重构、研究、长文、配图、原型、eval 调参。不适用：改一行文案、解释报错、简单 code review、问答案。

离开场景：Goal 写清楚后可无人值守跑测试、修失败 case、整理资料、生成配图，回来拿带证据的进度账——这正是下一节"夜间实战"的前提。

以下来自 @freeman1266：他最初有个朴素幻想——睡前丢个需求，早上醒来代码写好、测试跑完、PR 就绪。跑了半年后结论更克制：Codex 确实在你睡觉时帮你写代码，但前提是你不能把它当通宵加班的资深工程师，而要当成"不知疲倦但边界感需提前写清的执行者"。

睡前任务三条件：输入清楚、写入范围清楚、验收命令清楚。反例"帮我优化一下这个项目"的模糊点：哪些文件能改？能否装依赖？测试失败继续吗？旧代码顺手重构吗？UI 按谁的标准？

三类好任务：① 只读扫描（成功率最高：扫 TODO、风险公开 Endpoint、漏测、Deprecated API、README 矛盾，出优先级报告；不改代码不制造冲突）；② 小范围补测试（范围窄到模块+行为，如"未付费不能创建公开报告"等具体行为；不要让它"提高覆盖率"，它会写低价值测试）；③ 文档和工程卫生（更新 README：本地运行命令、校验命令、Vercel 路由模型、内存存储限制、KV/Upstash 环境变量、健康检查接口；不改应用代码）。

三类禁区：① 产品判断重的任务（提升 onboarding 体验、提高定价页转化率——可让它给方案，但不让无人值守大改）；② 跨前后端大重构（牵一发动全身）；③ 需要真实账号/生产权限的任务。规则：localhost 可测、测试账号可点、生产后台默认不碰、个人邮箱和聊天默认不碰、"Always allow" 只给非常窄非常确定的动作。

以下来自 @freeman1266：@Russell3402 的六要素 Goal 是"官方写法"，这份睡前工单模板是手写版 Goal——不用 Goal 功能，靠模板 + AGENTS.md 一样能实现夜间自动化。固定格式（可复制）：

复制目标：________________（一句话）

上下文：________________

范围：
- 允许修改：________________
- 仅限读取：________________
- 明确排除：________________

规则：不加依赖、不改无关 UI、不重写架构、保留现有行为

验证：运行 ________________（跑不了就解释原因）

最终响应输出：
1. 修改文件列表
2. 运行命令列表
3. 残留风险 / 需人工决策事项

次日验收顺序（记住这个顺序）：① git diff --stat 看改动范围是否失控；② 看测试命令和失败信息；③ 读关键文件 diff；④ 最后才看 Codex 总结——总结是线索不是事实。"已完成"但没跑验证命令 = 没完成；改了 scope 外文件先退回问为什么。