大型任务容易卡住，常见原因是完成标准过远，中间没有可以核对的结果。把工作按依赖拆开，每个里程碑只承担一个主要结果，并写出验证方法。上一段通过以后，下一段才获得稳定输入。
本文依据 2026 年 8 月的官方文档整理。Goal mode 的入口和进度控件可能调整，目标、约束与验证仍是长任务的基本材料。
先写最终可交付结果
“重做网站”只有活动，没有终点。可以写成“迁移三个公开页面，保留现有 URL 和表单行为，移动端与桌面端通过回归检查”。完成定义应包含能观察的页面、数据或文件，也要写明不能破坏的行为。
工作方向还不清楚时，可以先用 /plan 调查依赖和风险。方案稳定以后再用 /goal 持续推进。Goal mode 会保留原有沙箱与审批边界，持续工作不会自动获得更大的访问范围。
依赖关系决定拆分顺序
先处理会影响后面所有工作的事项。页面迁移可以先核对路由和数据来源，再建立共享布局，随后逐页实现。测试和文档不必全部留到最后，哪个阶段产生新行为，就在附近补上对应验证。
一个里程碑最好能单独交接。它应留下明确文件、检查结果和未决问题。下一段需要等待产品选择或外部凭据时，到这个节点暂停，别用假数据把流程硬接下去。
用一个真实例子检查拆分顺序
假设任务是把旧登录页迁到新框架。第一段先记录现有路由、表单字段和错误行为，产出基线清单。下一段建立新页面并让现有单元测试通过。界面稳定后再检查键盘操作与移动端，发布准备放在最后。
这几个阶段彼此有输入关系。基线没有确认，新页面就容易漏行为。代码还在变化时提前发布，也会让线上验证失去明确版本。拆分时沿着这种依赖往后排，比平均分配工作量可靠。
高风险动作单独设确认点
数据库迁移、正式发布和外部消息会影响其他人，应成为独立阶段。Codex 可以先准备迁移文件、发布清单或消息草稿，你确认目标和恢复办法后再执行。准备完成与线上生效要分开汇报。
每次确认前检查当前分支、测试结果和目标环境。执行以后再收集真实证据，例如迁移记录、部署版本和线上页面响应。没有完成外部验证时，阶段状态就停在已准备或已部署。
并行任务必须隔离写入位置
互不依赖的调查和写作可以放在不同聊天并行。两项代码工作会修改同一个仓库时，应使用不同 worktree 和分支。官方长期任务说明也建议避免两个聊天同时改同一批文件。
并行结果回来以后逐项整合。先合并一个里程碑并运行检查，再处理下一项。这样冲突出现时，能够知道是哪一段行为改变了结果。
每段结束都留下短回执
回执写清已完成结果、实际修改文件、运行过的检查和剩余阻塞。提交编号、推送状态与部署状态分别记录。后续任务可以直接从这份回执继续，不必重新猜测上一段做过什么。
