Plan 与 Goal：怎样让长任务持续推进而不是无限运行

「继续做到完成」是最危险的模糊指令之一

任务已经跑了两个小时。文件在变，状态更新不断出现。你问进度，它说还在继续。可是谁都没有写下「完成」到底长什么样。

长任务真正缺的通常不是耐心，而是终点。

Goal 的价值不是让 Codex 永不停下，而是让它知道什么时候必须停。 这节课会跟着一次迁移任务，把探索、计划和持续执行拆开，并把新授权、重复阻塞和目标变化写进停止条件。

Plan 和 Goal 解决不同问题

官方 Long-running work 文档把长期工作建立在清楚的结果、约束和验证上。Plan 用于在执行前理解环境、比较方案、暴露会改变路线的未知；Goal 用于在路线已足够明确后持续推进同一目标。

一个常见错误是把 /goal 当成“不要停”的开关。Goal 的价值恰好相反：它需要一个足够清楚的首条消息作为完成标准，并在需要用户决定、权限越界或外部状态改变时暂停。持续执行不等于无限授权。

什么时候先进入 Plan

满足任一条件，先 plan：

• 结果本身还不确定；
• 有两种以上架构方案，会影响公开接口或数据；
• 工作区不熟悉，需要先建立系统地图；
• 任务跨多个模块、迁移或发布阶段；
• 风险高，必须提前写回退和人工批准节点。

Plan prompt：

/plan

目标：把当前 JavaScript 模块逐步迁移到 TypeScript。
请先只读检查仓库结构、构建链、测试、运行时入口和项目指令。
输出：
1. 当前系统地图与证据路径；
2. 会改变方案的未知和需要我决定的事项；
3. 分阶段里程碑、每阶段可交付结果；
4. 验证、兼容和回退策略；
5. 文件重叠与并行风险。
在我确认前不要修改文件、安装依赖或执行外部动作。

合格计划不是“分析—开发—测试”。它应该说明先迁哪一层、旧调用如何兼容、什么测试构成基线、哪一步可单独回退。

计划确认后怎样写 Goal

官方框架可归纳为：

/goal

Outcome
- [最终可观察结果]

Constraints
- [必须保留的行为]
- [允许修改的范围]
- [禁止的外部动作]
- [需要暂停询问的决策]

Verification
- [每个里程碑的机械检查]
- [最终人工或行为检查]
- [失败后的恢复与重试上限]

“完成所有迁移”不是好 Outcome。更具体：

• 目标模块不再包含 JavaScript 源文件；
• 公共 API 和用户行为保持；
• 类型检查、单元测试、集成测试通过；
• 迁移记录列出剩余风险和未覆盖路径。

长任务的里程碑必须留下状态

每个里程碑记录：

字段	内容
完成内容	具体文件、行为或文档
验证	命令、结果、截图或抽样
未完成	仍欠缺的事实和风险
决策	用户确认或选择了什么
下一步	单一、可执行的下个阶段
工作区状态	分支、未提交变化、依赖

这份状态不是为了写漂亮周报，而是为连接中断、重新打开会话或协作者接手时恢复事实。

Side chat 与并行任务

状态追问和补充背景可以通过不打断主任务的方式进行，但不要让两个 chat 同时修改同一文件或共享不可分割状态。适合并行的是独立调研、测试审查、不同方案原型；不适合并行的是同一 migration 文件、同一 lockfile 或同一数据写操作。

并行前写资源矩阵：

任务 A：修改文件 / 写入资源 / 验收
任务 B：修改文件 / 写入资源 / 验收
重叠：
合并顺序：
冲突处理：

Goal 不会扩大权限

官方文档明确：Goal 保持原有 sandbox 和 approval 边界。长任务遇到外部网络、工作区外写入、生产系统或其他受限动作时，仍应暂停。不要因为目标“已经授权”就把所有后续动作视为自动获准。

什么时候必须停

• 同一阻塞条件重复出现且没有新证据；
• 完成需要未授权的发送、付款、删除、push 或 deploy；
• 工作区出现来源不明的变化；
• 关键假设与用户决策冲突；
• 只剩外部系统等待，继续重试会造成副作用；
• 验证表明方案损坏了必须保留的行为。

停止时报告“已经确认的事实、最后安全状态、阻塞、需要的决定、恢复入口”。不要用“任务复杂”当阻塞，也不要在缺少授权时自行降低完成标准。

实操与评分

在练习册选择一个至少三阶段的任务。先产出计划，让人只看计划就能指出每一阶段的结果和回退点；再写 Goal。评分各 2 分：

• 结果可观察；
• 约束保护真实风险；
• 里程碑可独立验证；
• 有状态与恢复；
• 有停止和授权边界。

低于 8 分不要开始长期执行。

完整案例：把一次支付迁移变成长任务

“把旧支付流程迁到新供应商”同时包含契约调查、数据迁移、前后端修改、回归和发布。直接设置一个宏大 Goal，agent 可能在未确认退款语义前就开始改代码。正确顺序是先用 Plan 暴露决策，再用 Goal 持续推进已确认的结果。

Plan 阶段必须回答的问题

只读调查现有支付入口、订单状态、回调签名、退款路径和测试。
列出新旧供应商契约差异、数据迁移需求、不可逆决策和需要业务确认的问题。
计划拆成可单独验证和回退的里程碑；在我确认前不要修改代码或生产数据。

一份合格计划不只是文件列表，还应包含：

1. 当前系统图和真实基线；
2. 状态映射与不变量；
3. 决策点及负责人；
4. 每个里程碑的输入、输出、验证和回退；
5. 哪些步骤需要新授权。

Goal 阶段只承诺已定义的结果

Outcome：
- 沙箱环境支持新供应商支付和退款；
- 旧订单仍能查询，不改变公共 API。

Constraints：
- 不处理生产密钥和真实资金；
- 数据迁移先生成只读报告；
- 每个里程碑独立提交，保留旧路径开关。

Verification：
- 契约测试覆盖创建、回调幂等、退款和失败重试；
- 前端在两个视口完成真实沙箱流程；
- 发布前提供迁移报告、回退步骤和未决问题。

Goal 保持方向，计划保留路径和决策记录。执行中若业务确认改变了退款语义，应更新计划与 Goal，而不是把它藏在过程消息里。

长任务的检查点

每个检查点回答四个问题：

• 已完成的可观察结果是什么；
• 新发现改变了哪个假设；
• 下一步为什么仍服务最终 Outcome；
• 是否出现需要用户授权或外部状态变化的阻塞。

“继续处理剩余问题”不是检查点；“契约测试已覆盖支付成功，但退款状态仍缺业务映射，因此暂停退款实现”才是。

停止、恢复和失败边界

长任务必须允许中途恢复。恢复记录至少包括基线 commit、当前工作树、已完成里程碑、未解决决策和下一条验证命令。

遇到以下情况应停：

• 同一失败重复出现且没有新证据；
• 需要修改生产数据、发送消息或扩大权限；
• 关键业务语义存在两种合理解释；
• 当前路径会破坏已确认的不变量。

计划评审不是批准所有里程碑

确认 Plan 表示同意当前方向，不自动授权其中的生产迁移、外部发送或部署。每个里程碑开始前仍要核对它依赖的决策和权限。若计划写着“第五步切换生产流量”，但当前请求只授权本地实现，执行记录应把第五步保留为未执行，而不是因为它出现在计划里就继续。

故障诊所

Plan 写成承诺

调查阶段还不知道文件和根因，却给出精确工期与改动。恢复方法是标记假设、先收集证据，并把不可逆决策前移给用户。

Goal 只有口号

“完成支付现代化”无法判断结束。补 Outcome、Constraints、Verification，并拆出第一个可验证里程碑。

长任务一直运行但没有进展

检查更新是否只有活动，没有新结果或新证据。缩小到一个阻塞，定义一次诊断实验和停止条件。

知识检查

业务还没决定旧订阅如何迁移时，可以把“完成全部订阅迁移”写进当前 Goal 吗？不应。可以把“生成迁移选项、影响分析和待决策清单”作为当前可完成结果。

能停下的目标，才有资格持续运行

为你的长任务补四行：最终结果、不可越过的边界、验证方式、必须暂停的情况。然后再问一次，当前状态离哪条证据最近。

如果任务只能用「再继续看看」描述进度，它还不是 goal。把终点写清楚，持续推进才不会变成持续漂移。

完成检查

• Plan 先消除会改变方案的未知
• Goal 的第一条消息足以判断完成
• 每个里程碑有独立证据与工作区状态
• 并行任务没有写入重叠
• 长期运行没有扩大 sandbox 或授权
• 暂停条件与恢复交接已经写清楚