长任务不跑偏：用验收条件和交接记录保持方向

迁移项目、整理旧站点或完成一组相互依赖的功能，往往要经历多轮调查和修改。时间一长，最容易丢失的是“为什么做这件事”和“做到什么程度可以停止”。

官方长任务指南建议明确结果、约束和完成条件，并在相关工作中保持上下文连续。支持的客户端也提供 /goal，用于持续追踪目标；这不会扩大任务原有的权限范围。[1]

把目标写成最终状态

“检查站点”只是活动，“首页和全部文章可访问，旧链接保留，移动端无横向溢出，结果有记录”才是可以验收的状态。明确状态之后，Codex 才能判断下一步是在推进目标，还是在增加无关工作。

目标：完成静态博客的发布准备。

完成条件：
- 首页、文章页、归档和 404 页面可正常访问。
- 现有文章地址保持不变。
- 手机和桌面布局均可阅读。
- 站内链接、RSS 与 sitemap 检查通过。
- 留下验证结果和待处理事项。

范围：
在当前项目中完成内容与页面调整。
发布动作按本次任务已经明确的授权范围执行。

阶段要围绕可验证的结果

可以把工作分成现状确认、实现、验证与交付，每一阶段都留下一个小结果：站点清单、可运行版本、检查报告或部署记录。不要只按“已经花了多久”判断进度。

如果调查发现前提不成立，例如旧链接依赖动态查询，应及时调整实现路径并说明影响。目标仍然是保留访问行为，不必坚持最初猜测的技术方案。

用简短记录保留关键决定

长记录不一定更有用。优先保存影响下一步判断的信息：为什么采用当前方案、哪些方向已排除、哪些测试已经通过、哪些条件仍无法确认。

目标：
当前版本：
已完成：
已验证：
尚未验证：
修改文件：
关键决定及原因：
下一步：
恢复工作所需的命令或路径：

每个字段写具体事实。“准备测试”应留在下一步，而不能放进已验证。路径和命令需要能被实际使用，避免留下只有原作者才理解的简称。

中途纠偏时说明什么仍然有效

如果想调整页面风格，可以说“配色改为深色，文章结构和已有链接保持不变”。如果只想查询进度，明确请求状态说明，让当前任务继续。清楚的反馈能避免把一次补充理解成重新开始。

需要暂停时，先让正在运行的操作结束或安全停止，并确认阶段结果已经保存。不要用“应该已经完成”代替实际检查。

交付报告回答四个问题

完成了什么？如何验证？结果在哪里？还有什么未解决？这四个问题足以构成一份可用的交接。没有必要复述整个执行过程，但关键限制必须保留。

长任务的可靠性来自一连串可核对的中间结果。把目标与证据保持在同一条线上，后续继续、审查和维护都会容易许多。