Claude Code 和 Codex 的 /goal 功能已经推出一段时间。这个号称能让 AI "长时间自主运行直到目标完成"的功能，实际使用效果却差异巨大：有人能让 AI 连续运行几十小时完成复杂任务，有人却遇到跑一会儿就停止的情况。这种差距不在 AI 本身，而在于你给的 /goal 指令质量。
本文将深入解析 /goal 的工作原理，并提供三种实用方法解决 /goal 中途停止的问题。
常规提示词与 /goal 指令在底层逻辑上完全不同。我们来看 Codex 在收到两类指令后的运行机制：
普通 Prompt 模式：虽然普通 Prompt 在 Codex 的"思考执行"过程中也会被拆解成小步骤执行，但输出结果没有明确标准。如果结果不符合预期，需要重新输入 Prompt 进行纠正。这些指令大多是临时的、一次性的，AI 执行完指令后约束力随之结束。
Goal 模式：Goal 是为 AI 设定一个持久的目标，这个目标有客观证据可以证明是否达成。只要目标未达成，它就会一直在后台激活，跨越多轮对话依然有效。直到达成目标、预算耗尽或遇到无法解决的阻碍，Goal 才会停止。
用一句话概括两者的核心差异：prompt 是你每步都得推着 AI 往前走，/goal 是你划定一条终点线，AI 自己跑到终点线后才给你汇报。
二、三种方法解决 /goal 跑一会就停的问题
通过对比可以发现，/goal 跑一会就停的问题往往是因为缺少清晰的目标、过程处理标准和最终验收标准。就像给团队成员布置任务却没讲清楚范围和标准，执行过程中遇到不确定就会反复询问。
方法一：使用 goal 模板
核心公式：作用范围 + 硬性约束 + 验收清单 + 停止条件
标准模板结构：
/goal { 一句话描述目标 }
Scope：{ 作用范围：改哪些文件/哪个模块的代码，以及明确不在作用范围的区域 }
Constraints：{ 硬性约束（可以多个），比如不要修改数据库 schema，保持现有公开 API 不变，不允许新增 npm 依赖 }
Done when：{ 明确可验证的交付物或最终状态（可以多个），比如 npm run test 通过，checklist 全通过 }
Stop if：{ 明确停止条件（可以多个），比如需要 npm install 新依赖，超出 token 限额 }
实际示例：
/goal 优化首页（pages/index.js）的加载性能。验证标准：在本地运行 lighthouse-cli 模拟移动端测试时，Performance 分数必须达到 90 分以上，且 First Contentful Paint (FCP) 小于 1.8 秒。约束条件：不能压缩或降低现有的核心高保真产品图片的质量。停止条件：如果尝试了代码分割和懒加载后分数仍低于 85 分，请生成当前的性能火焰图报告并停止。
对于非开发者来说，写好 goal 在开发场景下的各种约束条件并不容易。最佳方案是让 AI 辅助撰写：
- Codex 用户：利用自带的 set_goal 函数，把描述不够清楚的需求丢给 Codex，让它输出完整的 /goal 指令
- Claude Code 用户：将 goal 公式做成通用 skill，如 caicai-goal-prompt（GitHub: https://github.com/nextcaicai/caicai-skills/blob/main/skills/caicai-goal-prompt/SKILL.md）
方法二：使用 Goalbuddy
Goalbuddy 是另一个专业的 Goal Skill，相比自制 Skills 有两个显著特点：
- 需求澄清：面对模糊需求如"/goalbuddy 优化桌面端性能"，它会先让用户澄清关键问题，明确是优化页面加载速度、交互响应性能还是资源占用优化
- 实时看板：执行过程中提供本地实时滚动看板，直观查看任务清单、进程项、阻塞项、完成项等
GitHub 地址：https://github.com/tolibear/goalbuddy
Goalbuddy 的实现由三个关键文件支撑：
- SKILL.md：定义怎么做（过程 + 规则），通过结构化文件、清晰角色分工（Scout/Judge/Worker）和强制验证条件（Oracle），让 AI 按工程化流程执行长期任务
- goal.md：定义做什么 + 做到什么程度算完成（约束条件、验收标准）。梳理清楚后运行 /goal Follow docs/goals/goal.md 指令
- state.yaml：共享当前任务进度（实时状态），呈现为滚动看板。AI 每轮循环先读 goal.md，再结合 state.yaml 决定下一步
注意：GoalBuddy 不替代原生 /goal，而是为其准备本地看板和交接提示。
方法三：结合 Plan 或 Spec 工具
理解 /goal 本质后，也可以沿用常用的 Plan 或 Spec 工具梳理目标和验收标准：
- Plan 模式：通过 Codex 或 Claude Code 自带的 Plan 模式，将模糊需求一步步梳理清楚，追问确认 Done when 和 Stop if 边界问题。退出 Plan 模式后用 /goal 执行计划（注意：Plan 模式下无法编辑和创建文件）
- OpenSpec 工具：输出标准化规格文档，包括 proposal.md（提案）、specs/（规范）、design.md（设计）、tasks.md（任务清单），这些文档基本就是标准的 goal 指令
- 其他工具：Superpower 的 brainstorming + writing-plans、Matt Pocock 的 grill-with-doc + to-prd 等，只要能形成类似的需求执行文档即可
三、启用 /goal 功能
如果之前还没用过 /goal，先将 Codex 或 Claude Code 更新到最新版，它一般会出现在斜杠命令列表中。如果没有出现，可以直接让 AI 帮你启用。
开启 /goal 后，用上述任意一种方法去实践，相信会带来全新的 AI 自主运行体验。