适合需要让 Codex 连续处理大型功能、跨模块改造或数小时重构的开发者。核心结论：长任务不能只靠一段很长的提示词，应该把目标、进度、决策和验收写进一个持续更新的 ExecPlan。
为什么普通待办清单撑不住长任务
短任务可以依赖当前对话：找到文件、修改、测试、检查 diff。但当工作跨越多个模块、需要先做原型、可能中途失败或换人接手时，“第一步改接口，第二步补测试”这样的清单很快就会失真。后来接手的人不知道为什么选这个方案，也不知道某项打勾后究竟验证了什么。
OpenAI 官方把 ExecPlan 定义为一种可执行、持续更新的设计文档。它不是实施前写完便归档的方案，而是任务进行中的事实来源：进度变化要更新，意外发现要记录，关键取舍要说明，最终结果要用可观察行为证明。官方示例甚至用于支撑单次提示下持续数小时的工作，但这不意味着所有任务都应套用重型流程；小修复仍应保持轻量。
第一步：先定义什么时候必须使用
把触发规则写进项目的 AGENTS.md，避免每次临时决定。例如：
``text 当实现复杂功能、重要重构，或任务预计跨越多个可独立验收的阶段时， 从设计到实现都维护一个 ExecPlan，并遵循 .agent/PLANS.md。 ``
触发条件应面向风险，而不是代码行数。涉及数据迁移、多个服务、外部依赖验证，或无法一次完成的任务，通常值得建计划；只改一个文案、补一个明确测试，则没有必要增加文档负担。
第二步：让计划在脱离对话后仍能执行
一个合格的 ExecPlan 必须自包含。假设下一位执行者只有当前工作区和这份文件，仍应能理解：用户最终能获得什么、现状在哪里、需要修改哪些路径、命令从哪个目录运行、成功时应该看到什么。
不要写“按之前讨论的方案处理缓存”，而要说明缓存位于哪个模块、当前行为是什么、为何选择失效策略，以及如何验证旧数据不会继续返回。术语第一次出现时用普通语言解释。计划可以引用仓库中已提交的文档，但不能依赖一段找不到的聊天记录。
第三步：把长任务拆成可观察的里程碑
里程碑不是按文件平均分块，而是每一段结束时都多出一种能验证的能力。例如：
- 先建立失败测试，复现当前缺陷；
- 用最小原型验证依赖库能满足关键约束；
- 接入一条真实业务路径，同时保留旧路径；
- 完成行为比对后切换默认路径；
- 删除兼容代码并跑完整回归。
每个里程碑都要写清命令、工作目录、预期结果和失败后的恢复方式。这样即使第三阶段中断，也不需要重新猜测前两阶段是否真的完成。对于数据库或配置修改，优先设计可重复执行的步骤，并给出备份、回滚或安全重试办法。
第四步：维护四个“活”的区域
官方模板要求持续维护四类信息，它们恰好解决长任务最常见的失忆问题。
- Progress：带时间记录已完成、未完成和部分完成的工作，停下前必须更新。
- Surprises & Discoveries：记录意外行为，并附测试输出、日志或小段 diff 作为证据。
- Decision Log：写清做了什么选择、理由是什么、何时由谁作出。
- Outcomes & Retrospective：对照最初目标，总结已实现能力、遗留问题和经验。
注意，计划变化并不代表计划失败。发现原设计与真实代码不符时，正确动作是更新决策和后续步骤，使文档重新与工作区一致，而不是继续执行一份已经过时的清单。
第五步：验收必须描述行为
“新增了一个健康检查类”不是验收，因为代码存在不等于用户能用。更好的写法是：“启动服务后请求 /health，返回 HTTP 200 和预期正文；新增测试在修改前失败、修改后通过。”如果改动是内部重构，也应通过旧测试、新增回归用例或同一输入下的行为比对来证明兼容。
同时区分证据强度：静态检查通过、项目构建成功、单元测试通过和真实环境回归是不同层级。计划中应明确哪些已执行、哪些因环境限制尚未执行，不能用“验证完成”模糊带过。
一个可直接复用的最小骨架
创建计划时至少包含：目标与用户可见结果、当前上下文、进度、意外发现、决策日志、分阶段工作、具体命令、验收标准、幂等与恢复、最终复盘。提示 Codex先研究仓库再补全这些部分，实施过程中在每个停点同步更新。
真正有价值的不是文档篇幅，而是它能否回答三个问题：现在做到哪里，为什么这样做，下一步怎样证明成功。当 ExecPlan 可以独立承担这三件事，长任务就不再绑定某一次对话；即使任务中断、上下文压缩或换人接手，也能从已验证的事实继续前进。
注意事项
- 不要把令牌、生产口令或个人路径写入计划；用秘密管理和泛化示例代替。
- 不要把尚未运行的命令标为完成；保留真实状态比漂亮进度更重要。
- 原型必须注明保留或删除条件，避免试验代码悄悄进入正式路径。
- 大任务可以详细，小任务保持简洁；流程成本应与变更风险匹配。