试试 Codex 的 /goal 指令

用 AI 写代码的人应该都干过这件事：

跑完一轮，发现没做完，打字"继续"。
又跑一轮，还是没完，再打字"继续"。
来来回回五六轮，中间还穿插着"你刚才改的不对，回退"“跑一下测试看看”“别停，把剩下的也改了”。

整个过程就像在遛一条注意力只有三秒的狗——你得一直拽着绳子，稍一松手它就跑去闻别的东西了。

貌似Codex 里也有个 Goal 功能，我用了几天，感觉思路是对的。它想解决的就是这个问题：能不能让 AI 自己知道"做完"长什么样，不用你每一步都盯着。

Goal 是什么东西

说白了就是一个"持久目标"。

你用/goal给 Codex 设一个目标，它就会自己跑，跑完一步会自己检查有没有达成，没达成就继续，达成了就停。

跟普通 prompt 的区别在于：

• 普通 prompt：你问 → 它答 → 等你下一步指令
• Goal 模式：你定目标 → 它自己干 → 自己判断 → 继续或完成

关键变化是，下一步该做什么，取决于它刚发现了什么，不是每一步都要你拍板。

比如你让它集成 OAuth2，它写完授权流程发现 token 刷新逻辑有问题，会自己去修、自己跑测试验证，不需要你手动说"再试一次"。

怎么用

命令很简单：

/goal 给项目集成 OAuth2 登录，支持 Google 和 GitHub 两个 Provider

然后就不用管了。它会自己跑测试、改代码、再跑测试，直到达成目标或者碰到搞不定的障碍。

管理命令：

实际案例：集成 OAuth2

说一个我自己用 Goal 跑的真实场景：给一个 Node.js 项目集成 OAuth2 登录。

这个任务看着简单，但坑也不少。你要处理授权码流程、token 交换、refresh token、用户信息映射、跟现有 session 体系对接，中间还涉及 PKCE、state 参数防 CSRF 这些安全细节。拆成单独的小任务每个都不难，但串起来之后很容易丢失细节处理。

烂 Goal：

/goal 给项目加上 OAuth2 登录

什么叫"加上"？Google 还是 GitHub？登录成功后 token 存哪？refresh 逻辑做不做？现有的密码登录还能用吗？这些问题不讲清楚，Codex 跑完你也不知道它算不算"做完了"。

好 Goal：

/goal 给项目集成 OAuth2 登录，支持 Google 和 GitHub 两个 Provider。 用现有的用户表结构，OAuth 登录后映射到本地用户。 验证标准：两个 Provider 都能走通完整的登录-回调-token刷新流程， 跑通集成测试，现有的密码登录不能受影响。 每轮跑完记录改了什么、测试结果、下一步打算试什么。 如果某个 Provider 的 SDK 有问题或者跟现有架构冲突了，停下来报告 卡在哪里、尝试过什么、需要我提供什么配置或决策。

Codex 实际跑下来的结果：

• Google 登录授权码流程 → 跑通了
• GitHub 登录授权码流程 → 跑通了
• token 自动刷新 → 做了，用 cron 任务在 token 过期前刷新
• 用户信息映射 → 做了，email 匹配 + 首次登录自动建本地账号
• PKCE → 做了，Google 要求的
• state 参数防 CSRF → 做了
• 集成测试 → 全绿
• 现有密码登录 → 没动，验证通过

中间碰到了一个问题：GitHub 的 OAuth API 返回的用户邮箱有时候是 null（用户设了隐私），Codex 自己发现的，自己加了降级逻辑——先用 username 查本地用户，查不到就让用户手动绑定邮箱。

如果是普通 prompt 模式，这个问题大概率要到测试阶段甚至上线后才暴露。Goal 模式下它每轮都在跑测试验证，自己就把这个边界情况堵住了。
这就是 Goal 的价值——它不会因为"主流程跑通了"就停下来交差，它会带着测试结果告诉你，哪些做到了，哪些有坑，坑在哪。

什么时候该用，什么时候别用

适合用 Goal 的场景：

• 第三方服务集成（OAuth2、支付、消息队列等，有明确的端到端验收标准）
• flaky test 排查（需要反复跑、反复改）
• 性能优化（有 benchmark，有明确指标）
• 任何"做完"有客观标准、但路径不确定的任务

别用 Goal 的场景：

• 改一行代码
• 问一个问题
• 简单的 code review
• 你自己都不知道"做完"长什么样的任务

最后一种情况尤其要注意——如果你自己都说不清楚目标，Goal 只会让 Codex 带着一个模糊的路径在那疯狂烧你的额度。

背后的实现思路

Goal 不是全局记忆，也不是项目级配置，它是线程级状态。你在一个对话里设的 Goal，只属于那个对话。

状态有四种：active（跑着）、paused（暂停）、complete（完成）、budget-limited（到5h/周限额了）。

它的继续机制是事件驱动的，不是简单循环。只有在以下条件全部满足时才会自动继续：

• 当前这轮跑完了
• 没有其他任务在排队
• 没有用户输入在等
• Goal 处于 active 状态
• 额度没烧完(很费额度这个)

限额到了之后，它会停下来，给你一份进度总结，告诉你下一步该做什么。额度耗尽不等于目标完成——这一点很重要，别搞混了。

我自己的感受

用了几天之后，我觉得 Goal 解决的核心问题其实不是"效率"，而是**“上下文丢失”**。

以前用 Codex 跑复杂任务，最大的痛点不是它能力不够，而是你得不停地把目标重新说一遍。跑偏了你拽回来，拽回来它又跑偏了，来回拉扯消耗的精力比自己写还多。

Goal 把目标钉在那里，Codex 每轮都能看到"我要去哪"。这听起来很简单，但对多步骤任务来说，区别很大。

不过这个功能目前还是偏早期。写好 Goal 本身是个技术活——你得想清楚目标、验证方式、约束条件，这其实就是把需求分析的活提前干了。如果你平时写需求就是"加上登录""优化一下"这种级别的描述，那 Goal 也帮不了你太多。