AI 长任务中断时，planning-with-files 的恢复点不在聊天记录里，而在项目目录里的三份 Markdown 文件。task_plan.md 记录阶段，findings.md 记录发现，progress.md 记录已经执行过的动作。重新打开 Codex 或 Claude Code 后，让 Agent 先读这些文件，再跑 git diff --stat，就能把“我刚才做到哪了”从文件系统里找回来。

断点续跑怎么操作

续跑时不要急着让 Agent 继续改代码。更稳的顺序是：读 task_plan.md、progress.md、findings.md；执行 git diff --stat 看真实改动；把未记录的文件变更补进 progress.md；确认当前 phase 是否还是 in_progress；再让 Agent 接着做下一步。这个顺序会慢半分钟，但能少掉一堆“重复修同一个错”的返工。

恢复提示词可以这样写

• 先读取 task_plan.md、findings.md、progress.md。
• 运行 git diff --stat，总结当前代码改动。
• 把未同步的发现写进 progress.md。
• 只继续当前 in_progress 阶段，不新增无关目标。
• 遇到同一错误第三次出现时，停下来说明尝试记录。

它真正有用的地方，是把失败也留下来。官方 SKILL.md 要求记录所有错误，并遵守 3-Strike Error Protocol：第一次诊断修复，第二次换方法，第三次重新审视假设；再失败就向人说明。这个机制不花哨，但对长任务很实用。

实际续跑还有一个小动作：让 Agent 读完计划后复述当前 phase、剩余 phase、已知风险和下一步文件范围。复述不是为了好看，而是检查它有没有把 findings.md 当成待执行指令。外部网页、日志和接口响应都应当被当作研究资料，不能直接变成新命令。这样做，断点恢复会更慢一点，但方向更稳。

哪些中断不适合硬续

如果 Git Diff 显示业务文件被外部大量改动，或者 task_plan.md 与实际代码明显对不上，先暂停续跑，人工确认计划。planning-with-files 能保存状态，但不能替你判断外部改动是否可信。还有一种情况是测试环境已经变了，比如依赖刚升级、接口权限失效，这时应先补 findings.md，再重排 phase。