Codex goal 把完成标准交给任务本身

goal 不是继续按钮

如果只看命令形态，/goal 很像一句增强版的“继续做，直到完成”。但这会把重点带偏。

长任务最麻烦的地方，不是模型愿不愿意继续，而是每一轮结束以后，谁来判断还要不要继续。

你让 agent 迁移一个前端项目，它可能改了路由就觉得完成了；你让它修一个测试，它可能让当前失败用例通过就停了；你让它重写一批文章，它可能改了几篇高风险稿就认为已经处理了重点。

这些停点不一定是错的，但它们经常和人的验收口径不一样。

goal 要解决的就是这件事：把验收口径提前写清楚，让后续每一轮都能围着它判断。

一个松散目标是这样的：

/goal 帮我把前端迁到 Next.js

它的问题不是短，而是没有停机条件。Codex 可以迁几页，可以顺手重构组件，也可以一直补它认为该补的东西。

更可用的写法应该接近这样：

/goal 把订单后台从 React Router 迁到 Next.js App Router。
登录页、订单列表、订单详情和下单页的视觉行为要和旧版一致。
不要改 API 合约和数据库 schema。
每完成一批页面都跑 npm run build、npm test 和 Playwright 关键路径。
只有这些验证都通过，才算完成。

这段话多出来的不是废话，而是四个控制面：

goal 抬高的就是这四件事。

为什么它能跑很久

Codex 能在 goal 下持续推进，不是因为一次回答被拉长了。

真正的工作方式更接近一个循环：计划、执行、观察工具结果、修正，再决定是否继续。构建失败、测试失败、截图不一致、lint 报错、评估样本没过，都会把任务拉回下一轮。

如果目标里写了验证方式，agent 就不只是凭感觉说“应该好了”。它需要拿到证据。证据没有回来，就继续查；证据失败，就继续修；证据都通过，才有资格收工。

这就是为什么 goal 适合迁移、重构、批量改稿、prompt eval、长链路排障这类任务。它们共同的特点是：一轮做不完，而且完成不能只靠主观判断。

反过来，这样的目标就很危险：

/goal 想一个更高级的产品方案

它没有边界、没有验证，也没有停机条件。agent 可能跑很久，但跑久不等于有用。至少要写清楚产出几套方案、覆盖哪些约束、用什么标准筛掉、什么时候停。

Claude Code 也在处理同一件事

Claude Code 也有 /goal，官方文档的说法更直白：用户设置 completion condition，Claude 会跨 turn 持续工作，直到条件满足。

Claude Code 文档还提到，每一轮结束后会检查完成条件是否成立；如果不成立，就继续下一轮。这一点很关键，因为它把“继续”从模型自己的主观收尾里拿出来，变成一个额外的条件判断。

两家的具体实现细节不必强行等同，但方向是一致的：终端 agent 开始从“执行下一条指令”，走向“围绕可验证目标持续推进”。

可以简单分一下：

这张表里，goal 的位置很清楚：它不是替代 hooks，也不是替代记忆。它管的是“这次任务做到什么程度算完成”。

好 goal 要写得像验收条件

我现在会把一个 goal 写成四行：

目标：最终要出现什么用户可见结果。
边界：哪些文件、接口、数据、视觉或行为不能乱动。
验证：用哪些命令、测试、截图、评测或人工检查作为证据。
停机：全部满足时停止；遇到哪些权限、事实、产品判断时暂停。

这和普通 prompt 的区别很大。

普通 prompt 更像下一步动作，goal 更像完成口径。它不是让人从流程里消失，而是把人的判断提前放进去。你不再每一轮提醒它“这个不算完成”，而是在一开始就把“什么算完成”写成后续必须服从的条件。

所以，越想让 agent 自己跑，越要把目标写窄。

越想少盯过程，越要把验证写实。

越不想它跑偏，越要把边界写清楚。

这才是 goal 真正值得关注的地方。不是多一条命令，不是可以跑多久，而是终端 agent 开始把“谁来判断做完”这件事抬到台面上。

参考资料

• Follow a goal | Codex use cases
• Slash commands in Codex CLI | OpenAI Developers
• Run long horizon tasks with Codex | OpenAI Developers
• Keep Claude working toward a goal | Claude Code Docs

$blog-writer 详解 codex 新出的 goal 命令，工作原理是什么，为什么持续工作很长的时间，官方提供的案例是什么。claude code 有没有类似的命名，顺带整理近期 两家终端新出的，好用的、受欢迎的功能，整理为表格。