如果你经常把一个数小时的迁移或重构交给 Codex，核心结论是：不要只写“继续做到完成”，而要把目标、边界、验证方式和停止条件写成一份可执行合同。/goal 适合目标明确、可以反复验证、允许代理分阶段推进的长任务；它不适合装下互不相关的待办清单。
/goal 解决的不是“写计划”，而是持续执行
普通对话通常围绕一轮任务展开；/goal 则让 Codex 围绕一个持久目标跨多轮工作，直到达到可验证的结束状态。它适合框架迁移、大型重构、部署重试、原型打磨或有评分标准的实验。
这和 ExecPlan 并不冲突。ExecPlan 是任务的路线图，记录里程碑、决策与发现；/goal 是让执行循环持续运转的控制方式。复杂项目可以先把约束写进计划文件，再让目标引用它。一个回答“准备怎么做”，另一个回答“什么时候继续、什么时候停止”。
如果命令列表里没有 /goal，官方文档给出了两种启用方式：在配置文件的 [features] 下设置 goals = true，或在 CLI 中运行 codex features enable goals。修改配置前应先查看现有内容并保留备份，避免覆盖其他个人设置。
一条好目标必须有四个零件
第一是单一目标。例如“把服务从旧客户端迁移到新客户端”，而不是“迁移客户端、整理文档、顺便优化首页”。目标过多时，代理难以判断优先级，也无法证明整体完成。
第二是明确边界。列出不可修改的接口、数据库结构、兼容范围和允许操作的目录。对生产发布、数据删除、权限变更等高风险动作，应要求停在审批点，而不是把“持续工作”理解成无限授权。
第三是验证循环。指定每个检查点要运行的测试、构建或对比方法。不要只写“确保没有问题”，而要写出能产生证据的命令和预期结果。如果验证依赖真实账号、生产环境或人工视觉判断，也应明确说明，避免把静态检查误报成端到端成功。
第四是停止条件。成功条件可以是“契约测试全部通过，旧路径仍可回滚”；失败条件可以是“同一错误连续出现三次，且没有安全替代路径”。没有停止条件的目标，容易在边际收益很低时继续消耗时间，也可能在外部依赖故障时空转。
可直接改写的目标模板
下面这个结构比一句“请一直做完”更可靠：
``text /goal 完成 [一个具体目标]。 先阅读 [计划、问题单和关键目录]，不要修改 [边界]。 按检查点推进，每完成一步运行 [验证命令] 并记录结果。 仅当 [可验证结束状态] 达成时结束。 遇到 [审批事项或连续失败条件] 时停止并报告，不执行高风险操作。 ``
启动后，状态汇报也应保持短而具体：当前检查点是什么、刚验证了什么、还剩什么、是否受阻。若进度描述开始变得模糊，优先收紧目标合同，而不是不断追加零散指令。
三个常见误区
一是把目标写成开放式愿望，例如“让项目越来越好”。代理没有客观终点，只能自行猜测。二是只写成功标准，不写权限边界，导致任务越做越宽。三是把“长时间自主执行”等同于“不需要验收”。实际上，目标机制提升的是持续性，不会替代测试、代码审查和上线审批。
还要区分“暂停”和“完成”：方向临时变化时可以暂停，补充约束后再继续；目标已经不再适用时应清理，而不是让旧目标和新指令相互竞争。对关键项目，最终仍要回看差异、测试证据、未验证项和回滚路径。
最后检查清单
- 目标是否只有一个，并且比单轮任务大、比开放待办小？
- 是否写清不可修改范围与需要人工批准的动作？
- 每个阶段是否有可运行、可观察的验证方法？
- 是否同时定义成功终点与受阻停止条件？
- 最终报告是否区分“已验证”“仅静态检查”和“尚未验证”？
/goal 真正有价值的地方，不是让 Codex “永不停下”，而是让它在清楚的合同内持续前进，并在该停的时候准确停下。目标越可验证，长任务越值得放心交出去。