让Codex修一个小Bug通常很顺找到问题、修改代码、运行测试几十分钟以内就能结束。真正麻烦的是长任务。例如把旧前端迁移到新框架重构一个几万行的核心模块连续修复一批兼容性问题把大型项目补齐测试反复运行实验直到达到目标指标。这类任务往往不是一句提示词能完成的。运行时间一长开发者很容易遇到Codex做到一半停了后面开始处理无关问题前面确认过的目标逐渐被忘掉测试失败几次后不断换方案最后改了很多代码却没人说得清到底完成了多少。这时真正缺少的不是更长的提示词而是一个持续有效的目标和停止条件。Codex现在提供的/goal就是用来处理这种长周期任务的。一、Goal和普通提示词有什么区别普通提示词更适合一次性任务修复用户登录后出现两次跳转的问题。Codex分析、修改、测试然后结束当前轮次。Goal则更像给Agent一张持续有效的任务单/goal 完成认证模块重构 直到旧接口全部迁移到新接口 相关测试全部通过 且旧实现仍然保留可回退路径。重点并不是命令前面多了一个/goal。真正的区别在于普通提示词告诉Agent“现在做什么”Goal告诉Agent“持续朝什么结果推进什么时候才能停止”。因此一个好的Goal一定同时包含一个主要目标明确范围验证方式停止条件。二、什么任务适合使用GoalGoal不是越大的任务越适合。比较适合的是大型代码迁移例如Vue 2 → Vue 3 旧SDK → 新SDK Java 11 → Java 21 旧认证接口 → 新认证接口目标明确而且可以不断迁移、测试、修复。大型重构例如拆分核心Service、移除历史兼容层、统一数据访问接口。每完成一阶段都可以通过测试检查是否继续。持续实验例如调整Prompt并持续运行Eval直到通过率达到95%。这种任务天然拥有“执行—验证—调整—再次执行”的循环。原型和项目第一版已经有清楚的PLAN.md希望Codex按照里程碑持续实现。不适合Goal的是帮我把这个项目所有能优化的地方都优化一下。这种目标没有边界也没有明确的完成定义。Goal应该比一个普通提示词大但比一个开放式Backlog小。三、第一步先定义“停止条件”很多人写Goal只写要做什么却没有写什么时候停止。例如/goal 重构订单模块。问题非常明显。重构到什么程度算完成Agent可能继续改命名拆文件调整目录清理旧代码升级依赖优化测试顺便改善性能。任务越来越大。更合理的是/goal 重构订单价格计算模块。 停止条件 1. 价格计算从OrderService中完全抽离 2. 外部调用接口保持兼容 3. 原有测试全部通过 4. 新模块拥有独立单元测试 5. 不存在无关Diff。 达到以上条件后停止 不要继续优化其他订单逻辑。这里最重要的一句其实是达到以上条件后停止。Agent不仅需要知道如何开始还必须知道什么时候应该结束。四、第二步告诉Codex先读什么长任务最怕一开始方向就错。如果Codex没有读取关键文档后面执行得越久返工成本越高。可以明确指定开始前先阅读 - AGENTS.md - docs/ARCHITECTURE.md - docs/auth-migration.md - 当前Issue - 最近相关测试失败日志 先总结 1. 当前状态 2. 目标状态 3. 不能破坏的兼容规则 4. 推荐执行阶段。 确认计划后再开始修改。也就是说长任务不要从“开始写代码”开始而应该从“建立共同事实”开始。如果有大型迁移最好再准备一份PLAN.md。例如PLAN.md Phase 1建立兼容层 Phase 2迁移读取接口 Phase 3迁移写入接口 Phase 4删除旧调用 Phase 5完整回归测试Goal负责保持最终目标PLAN负责描述中间路线。五、第三步把长任务拆成CheckpointGoal不是让Codex连续工作几个小时后最后一次性告诉你结果。更可靠的方法是设置检查点。例如大型迁移可以拆成Checkpoint 1 确认现有调用方和依赖关系。 Checkpoint 2 建立新接口兼容层并运行测试。 Checkpoint 3 迁移第一批调用方。 Checkpoint 4 迁移剩余调用方。 Checkpoint 5 删除旧实现。 Checkpoint 6 运行完整测试并Review最终Diff。每个Checkpoint都要有自己的验证条件。例如Checkpoint 3完成条件 - 10个目标调用方已迁移 - 新旧接口返回结果一致 - 单元测试通过 - 不修改Checkpoint 4范围内的文件。这样Agent即使运行很久也不会只有“完成”和“没完成”两种状态。开发者可以清楚知道现在推进到了哪里。六、第四步每一个阶段都必须有验证循环长任务最危险的模式是修改一百个文件 → 最后统一运行测试。一旦失败根本不知道问题是在哪一步引入的。更合理的Goal应该明确每完成一个Checkpoint 1. 运行当前阶段测试 2. 检查Diff 3. 记录已验证结果 4. 更新剩余任务 5. 验证通过后才进入下一阶段。可以形成循环修改 ↓ 验证 ↓ 失败 ↓ 分析原因 ↓ 小范围修复 ↓ 再次验证 ↓ 通过 ↓ 进入下一CheckpointGoal最适合的任务本质上都是这种具有稳定反馈循环的工作。七、怎样保存长任务的进度只依赖聊天记录并不够稳。建议要求Codex维护一份简短进度文件例如GOAL_PROGRESS.md内容可以非常简单# Goal Progress ## Objective 完成认证模块迁移。 ## Current checkpoint Phase 3迁移Token刷新调用。 ## Completed - 新接口兼容层完成 - 登录接口迁移完成 - 单元测试通过 ## Remaining - Token刷新 - 登出流程 - 旧接口删除 - 完整回归测试 ## Blockers 无 ## Last verification pnpm test auth PASS重点不是写漂亮文档。而是任务中断、换会话或者第二天继续时Agent能够快速恢复状态。长任务真正需要保存的是已完成什么、验证了什么、还剩什么、哪里被阻塞。八、什么时候应该Pause长任务不是设置Goal以后就完全不管。出现以下情况建议暂停需要扩大修改范围原来只修改认证模块却发现必须调整公共用户状态。先暂停重新评估影响。关键假设被推翻原来认为问题来自缓存实际根因在数据库事务。这时继续执行旧计划只会浪费时间。测试连续失败如果同一阶段已经尝试两三种方案仍然失败应先停下来检查环境需求测试本身上游依赖。出现高风险操作例如数据库迁移删除大量文件修改生产配置改变公共API增加重要依赖。都应该暂停并人工判断。Goal的价值不是让Agent永远不停而是在安全边界内持续推进。九、暂停、恢复和清除怎么用常见控制方式可以记成四个/goal 目标建立目标。/goal查看当前Goal状态。/goal pause暂停。适合需要人工检查、发现阻塞或者准备改变方向的时候。/goal resume确认问题解决后继续。/goal clear当前目标已经完成、失效或者准备彻底更换方向时清除。如果命令列表里看不到Goal可以检查功能是否已经启用。例如配置[features] goals true也可以通过CLI启用Goals功能。十、实战把Vue 2项目迁移到Vue 3假设现在有一个旧项目。如果只输入把这个项目升级到Vue 3。任务太大。可以改成/goal 将当前项目从Vue 2迁移到Vue 3。 最终完成条件 1. 应用可以正常构建 2. 主要页面视觉与迁移前保持一致 3. 单元测试全部通过 4. Playwright核心流程通过 5. 不删除旧代码除非已经确认没有调用方 6. 保留明确回退方案。 执行阶段 Checkpoint 1 分析依赖与不兼容项只输出迁移清单。 Checkpoint 2 升级基础运行环境并恢复构建。 Checkpoint 3 迁移公共组件。 Checkpoint 4 迁移核心页面。 Checkpoint 5 处理剩余兼容问题。 Checkpoint 6 运行完整测试并Review最终Diff。 每完成一个Checkpoint 运行测试、更新GOAL_PROGRESS.md 确认成功后再进入下一阶段。 以下情况必须暂停 - 需要更换UI组件库 - 需要修改后端接口 - 需要删除仍有调用方的组件 - 连续两次无法恢复测试。这就是一个能够真正长期运行的Goal。它没有规定Codex每一步必须具体怎么写代码却把目标、阶段、证据、边界和停止条件全部定义清楚了。十一、发现Goal开始跑偏怎么办不要不断增加临时提示不对先做这个。还有那个也别改。顺便再检查一下这里。这种指令越来越多Goal最终也会被污染。如果发现状态报告越来越模糊应重新收紧Goal。例如暂停当前Goal。 当前只保留Checkpoint 3。 下一步唯一目标 完成公共Button组件迁移。 验证命令 pnpm test Button pnpm playwright test button.spec.ts 禁止 修改业务页面 升级其他依赖 重构CSS系统。 通过后再恢复后续阶段。正确动作不是继续堆更多指令而是重新缩小当前执行边界。十二、一个可直接复制的Goal模板/goal 完成【长期目标】。 最终停止条件 1. 【可验证结果】 2. 【测试条件】 3. 【兼容或质量条件】 4. 【不得出现的结果】 开始前必须阅读 - 【AGENTS.md】 - 【架构文档】 - 【Issue / PLAN.md】 - 【相关日志或测试】 执行Checkpoint Checkpoint 1 【阶段目标】 验证【命令或结果】 Checkpoint 2 【阶段目标】 验证【命令或结果】 Checkpoint 3 【阶段目标】 验证【命令或结果】 工作规则 - 一次只推进一个Checkpoint - 每完成一阶段立即验证 - 保持简短进度日志 - 不执行无关重构 - 不擅自扩大任务范围。 必须暂停 - 需要修改范围外文件 - 核心假设发生变化 - 连续失败超过【次数】 - 需要高风险权限或生产操作 - 无法通过指定方式验证结果。 完成后输出 - 已完成内容 - 修改文件 - 验证结果 - 剩余风险 - 回退方案。结语Codex能够工作越来越久以后开发者面对的新问题已经不再是AI能不能完成复杂任务而是怎样让AI工作几个小时以后仍然朝正确方向推进Goal解决的正是这个问题。一个可靠的长任务应该具备一个明确目标一个可验证的停止条件一组阶段性Checkpoint每阶段独立验证一份可恢复的进度记录明确的暂停条件。不要把Goal理解成“让Codex一直运行”。真正有价值的是让Codex持续工作但始终知道下一步是什么、怎样证明自己没有跑偏以及什么时候必须停下来。当任务从十分钟的Bug修复变成几个小时甚至更长的迁移、重构和实验后这种目标管理能力会比单纯写一条更长的提示词重要得多。