Codex /goal 和 Claude Code /goal 都能让代理围绕一个目标继续工作，但它们不应该被当成同一个按钮。中文开发者遇到这个选择时，通常不是想看谁更强，而是想知道：我这次长任务到底该交给 Codex、Claude Code、普通对话，还是 CI/调度器。答案要先看任务归属和完成证据，而不是先看模型名。
如果任务已经在 Codex 的线程、CLI 或本地仓库流程里，并且完成结果可以用测试、类型检查、lint 或可审查 diff 证明，就可以考虑 Codex /goal。如果任务已经在 Claude Code 会话里，工作区可信、权限模式需要一直可见，而且完成条件能由会话中暴露的证据判断，就可以考虑 Claude Code /goal。如果目标还在变化、需要审美判断、涉及生产数据或没有明确中止规则，不要把它交给目标循环。
先用四路线决策板
| 路线 | 什么时候用 | 开始前要有的证明 | 停止规则 |
|---|---|---|---|
Codex /goal | 任务属于 Codex 工作流，仓库范围清楚，结果应该是可审查的 diff。 | 指定测试、类型检查、lint、快照或人工 diff 检查。 | 目标变化、diff 扩出边界、证明命令连续失败时暂停或清除。 |
Claude Code /goal | 工作已经在 Claude Code 中，权限模式和本地工作区判断很重要。 | 会话中的工具输出、文件变更和说明足以让完成条件被判断。 | 条件变模糊、需要新判断、或权限边界要重新选择时停止。 |
| 普通引导会话 | 需求会变化、需要架构取舍、UI 品味、排障路径还不明确。 | 每一步发现后仍需要人来决定下一步。 | 不让代理自动循环，保持计划、提问、确认的节奏。 |
| CI / 调度器 | 任务是定时、重复、外部触发，或者需要稳定日志和重试。 | workflow、cron、队列或测试流水线自己有日志和失败策略。 | 让自动化拥有循环，编码代理只负责修改自动化。 |
这张表比“Claude Code 和 Codex 谁更强”更有用。/goal 适合完成条件已经能被验证的任务，不适合把一堆模糊愿望塞进代理。一个目标循环应该像验收合约：它告诉代理什么算完成，也告诉人什么时候必须把控制权拿回来。
很多中文讨论会把 Codex 的持久目标、Claude Code 的持续执行、预算、云端、多代理、权限模式混在一起讲。实际写目标时要拆开：目标只描述完成条件；权限决定能不能做动作；测试证明结果；代码审查决定能不能合并；预算和订阅只决定你是否应该让长任务继续跑。
/goal 实际改变了什么
OpenAI 的 Codex slash command 文档把 Codex /goal 标成实验功能，并且和 goals feature flag 绑定。已核对的命令包括 /goal <objective>、/goal、/goal pause、/goal resume 和 /goal clear。所以中文文章里不应该把它写成永久稳定、所有 Codex 入口都完全一致的能力。
Claude Code 的 /goal 文档则围绕 completion condition：你写出完成条件，Claude Code 在多个回合中继续推进，每个回合后由评估器根据会话中可见的证据判断条件是否满足。它强调的是一个会话里的完成判断，而不是自动替你选择权限模式、替你跑所有测试、替你批准所有命令。
二者共同点是“让代理继续朝一个条件推进”。差异在于运行表面和控制边界。Codex 可能出现在 app、IDE、CLI 或云端任务中，不同入口的仓库权限、沙箱和审查路径并不一样。Claude Code 更强调本地会话、可信工作区、权限模式和会话证据。把这些差异抹平，最容易导致目标写得过大、权限给得过宽、结果没人真正验证。
机制差异要先问五件事
| 决策点 | Codex /goal | Claude Code /goal | 为什么重要 |
|---|---|---|---|
| 启用状态 | 已核对文档中是实验功能，需要 goals feature flag。 | 依赖 Claude Code 版本和可信工作区。 | 可用性是当前事实，不能写成永久承诺。 |
| 工作表面 | Codex app、IDE、CLI、云端任务可能有不同边界。 | Claude Code 会话、本地/远程/非交互路径各有要求。 | 目标不能假设代理正在使用另一个入口。 |
| 完成证据 | 最好是测试、lint、类型检查、快照或 reviewable diff。 | 评估器看会话中已经暴露的证据。 | 没有证据的目标容易“看起来完成”。 |
| 权限边界 | 目标不改变沙箱、仓库访问和命令批准。 | permission modes 仍然独立。 | 循环不是授权。 |
| 用量风险 | 长任务可能消耗更多额度或费用。 | 订阅、API key、会话分配也需要当前检查。 | 开跑前要知道谁为长循环买单。 |
如果任务需要只读分析，应先用 Claude Code 的计划或普通对话，不要马上设 /goal。如果任务需要 Codex 产出 diff，应先确认当前分支、依赖安装、测试命令和要保护的文件。目标循环会放大你写下的边界；边界清楚，它就有用；边界含糊，它会把含糊执行得更久。
开始前写成目标合约
| 合约项 | 可以开始 | 太含糊 |
|---|---|---|
| 结束状态 | “修复 packages/billing 的日期解析回归，相关测试通过。” | “整理一下 billing。” |
| 证明命令 | “pnpm test packages/billing -- date 通过。” | “确保能用。” |
| 范围边界 | “只改 parser、fixture 和回归测试。” | “需要什么就改什么。” |
| 权限模式 | “修改代码可以，触碰数据迁移前必须询问。” | “全权处理。” |
| 用量检查 | “证明命令失败两次就暂停汇报。” | “一直试到完成。” |
| 中止规则 | “问题超出日期解析就停止。” | “自己判断。” |
一个好目标应该能被不在现场的人复核。它不一定很长，但必须有可判断的终点。比如：
hljs text目标：在 Codex CLI 中只修改 checkout 折扣测试和 rounding helper，让 pnpm test packages/checkout -- discount 通过；如果需要改支付 provider 代码就停止。
再比如：
hljs text目标：在 Claude Code 中完成 docs/api/authentication.md 的锚点修复；docs lint 通过才算完成；修改 docs/api 以外文件前必须询问。
这类目标能让 Codex 保持任务稳定，也能让 Claude Code 的完成判断有证据。更重要的是，人类审查者能看出代理有没有越界。
/goal 不替代风险控制
/goal 不替代权限批准。Claude Code 的不同 permission mode 代表不同信任级别；Codex 的沙箱、仓库访问和命令执行边界也必须单独理解。目标只是让代理继续工作，不是自动允许它做任何事。
/goal 不替代测试。目标可以要求测试通过，但测试本身必须真实运行，且要和问题相关。一个窄测试通过，不代表生产风险已经消失。
/goal 不替代代码审查。目标循环产出的 diff 仍然是 diff。你要读改动、看是否碰了无关文件、复跑关键命令，并拒绝不在合约里的“顺手优化”。
/goal 不替代用量控制。Codex 和 Claude Code 的计划、API key、会话窗口、云端任务、订阅分配都可能变化。长时间任务开跑前，要看当前账户和当前入口，而不是凭过期资料估算。
/goal 不保护密钥和生产数据。带客户记录、凭证、不可逆迁移、生产账务路径的任务，应该先写 runbook、备份、staging 验证和人工批准链，而不是交给目标循环“直到成功”。
什么时候普通对话或 CI 更好
普通引导会话适合还在探索的问题：架构拆分、复杂事故、UI 体验、模糊需求、跨团队取舍。代理读到新信息后，你可能会改变目标；这时让它继续循环，反而会错过重新决策的节点。
CI 或调度器适合重复和时间触发：夜间依赖检查、定期文档扫描、部署后验证、监控驱动的报告。编码代理可以帮你写 workflow，但不应该成为 workflow 本身。自动化应该有自己的日志、重试、告警和失败分派。
如果你还在问“整体上 Claude Code 和 Codex 该选哪个”，先看 /zh/posts/codex-vs-claude-code。如果问题是 Claude Code 的订阅、API 计费和额度路径，去看 /zh/posts/claude-api-pricing-vs-subscription。本篇只解决 /goal 这一层的任务归属。
可复用的目标写法
测试修复
hljs text目标：修复 auth/session-expiry 测试，不改变公开 API。pnpm test auth/session-expiry 通过，并且 diff 只触碰 session expiry 代码和测试，才算完成。
它适合目标循环，因为失败边界清楚，证明命令明确，reviewer 能看 diff。
有边界的重构
hljs text目标：只在 packages/auth 内把内部 legacyToken helper 改名为 sessionToken。typecheck 通过且没有修改 packages/auth 以外文件才算完成。
这种目标可以交给 Codex，也可以交给 Claude Code；真正决定入口的是你当前在哪个工具里工作，以及权限模式是否清楚。
文档一致性
hljs text目标：让三篇 OAuth 设置文档包含同一条 redirect URI 警告，并让 docs lint 通过。如果需要改产品行为，停止并汇报。
这是一个好的文档目标，因为输出范围和停止条件都明确。
坏目标：泛化优化
hljs text目标：把 dashboard 做好一点。
这不是完成条件。先做普通引导会话，列出具体缺陷，再拆成一个空状态、一个可访问性问题、一个加载错误等小目标。
坏目标：生产风险
hljs text目标：修复生产 billing migration，直到能跑通。
这种任务需要人工 runbook、备份、审批和 staging 验证。/goal 不应该拥有不可逆风险。
团队里怎么落地这个选择
如果团队里已经同时使用 Codex 和 Claude Code，不要把 /goal 当成个人偏好的入口。更稳的办法是把任务先分成三类：能由证明命令关闭的代码任务、需要人类判断的探索任务、应该交给自动化系统的重复任务。第一类才适合进入 goal loop，第二类应该保持普通对话或 plan mode，第三类应该沉淀为 CI、cron、queue 或仓库 workflow。
在 code review 里，也要把 goal 合约作为审查对象。 reviewer 不只看代码有没有跑通，还要看目标是否一开始就限定了文件范围、是否记录了证明命令、是否在连续失败后停止、是否把权限和生产风险留给了正确的控制层。这样可以避免“代理很努力但方向错了”的情况。长任务失败时，最有价值的产出不一定是最终 patch，而是清楚说明为什么当前目标不再成立。
团队可以把目标写法放进 issue、PR 描述或任务模板里，但不要把模板变成新的官僚动作。模板只需要问几个硬问题：完成以后谁能验证？验证命令是什么？不能改哪些文件？哪些动作需要再次确认？什么时候必须停止？这些问题比“用 Codex 还是 Claude Code”更早，也更能减少事故。
还有一个实际边界：不要把 goal loop 当作交接给初级工程师的替代品。它适合执行有清晰验收条件的工作，不适合承担需求澄清、风险排序、对外承诺、上线批准和数据权限判断。人仍然要拥有目标定义、权限选择、review、上线决策和事后复盘。把这些职责写清楚，Codex /goal 和 Claude Code /goal 才会变成可控的加速器，而不是一个更持久的模糊指令。
如果任务结果要进入主干分支，还应该在 PR 里保留一条很短的执行记录：启动 goal 时的目标、实际运行的证明命令、没有完成或被中止的原因、以及 reviewer 需要特别看哪些文件。这样后续维护者看到的不是“某个代理改了代码”，而是一段有边界、有证据、有停止条件的工程变更。
这条记录也能反向训练团队：哪些任务适合目标循环，哪些任务应该先拆小，哪些任务根本应该进自动化或审批流程，而不是继续追加提示词。
FAQ
Codex /goal 和 Claude Code /goal 是同一个功能吗？
不是。它们都围绕完成条件继续工作，但产品合约不同。Codex 文档把 /goal 标为实验性的 Codex slash command；Claude Code 文档强调完成条件、评估器、一个会话一个 active goal，以及可信工作区等要求。
先试哪一个？
如果任务已经在 Codex 中，有明确仓库边界、证明命令和可审查 diff，先试 Codex /goal。如果任务已经在 Claude Code 中，本地权限模式和会话证据很重要，先试 Claude Code /goal。如果目标模糊或有生产风险，两个都不要先试。
/goal 会自动批准 shell 命令或代码修改吗？
不会。目标完成和权限批准是两套控制。Claude Code 的 permission modes 仍然要选；Codex 的沙箱、仓库访问和命令边界仍然要看。
/goal 能省钱吗？
不能这样假设。清楚的目标可能减少无效回合，但长任务也可能消耗更多额度。开跑前检查当前 Codex 或 Claude Code 入口的用量和计费路径。
好目标最少要有什么？
至少要有结束状态、证明命令或审查证据、范围边界、权限模式、用量检查和中止规则。少一项，就先让代理计划或提问，不要直接循环。
CI 或调度器什么时候更合适？
当工作是重复的、定时的、外部触发的，或者需要日志、重试和告警时，用 CI 或调度器。编码代理可以修改自动化，但不应该替代自动化本身。
