继续一个中断的 AI 编程项目，不需要把所有聊天重新读一遍。你真正需要恢复的是最后一次被验证的项目状态：目标、当前文件、已经接受的决策、通过的检查、尚未收口的缺口，以及下一个边界清晰的动作。
聊天记录告诉你讨论过什么；续接简报告诉你现在什么是真的。
五分钟续接顺序
- 读取当前产品目标和正在推进的路线图里程碑。
- 在相信任何总结前，先检查工作树和最近提交。
- 找到最近一次成功的测试、构建或运行证据。
- 列出未完成缺口，判断哪一个最先阻断用户结果。
- 用一个明确结果和完成证据启动新 Agent 会话。
这套顺序能避免两种高成本错误：重复已经落地的工作，以及从一个从未被验证的结论继续往下做。
从当前现实开始
运行仓库约定的状态与测试命令，只阅读最小相关代码路径。如果路线图说功能已完成，但当前页面、测试或运行状态不同，以当前证据为准。
把观察与推断分开：
- 观察：结账路由存在、构建通过，但生产返回 404。
- 推断：发布版本可能没有包含新路由。
这样可以防止新 Agent 把一个听起来合理的解释当成事实。
恢复决策链，而不是恢复整段聊天
真正有用的历史很短：
- 为什么选择当前方案；
- 哪些替代方案被放弃，以及原因；
- 哪些公共行为或边界必须保持；
- 哪个失败路径不应重复；
- 当前生效的是哪个精确版本、提交或对象。
越来越多 Coding Agent 支持仓库级指令，就是因为稳定项目上下文可以减少重复提示。GitHub 文档把仓库指令定义为跨会话保留项目结构、约定、构建和测试知识的方式：Customize Copilot for your project。
但不要把所有内容塞进一份巨大的指令文件。OpenAI 分享过超大 AGENTS.md 会挤占任务和相关代码的上下文，因此改用指向聚焦文档的地图：Harness engineering。
按第一处断链选择下一步
从入口到结果追踪用户旅程，找到“已验证现实”第一次不再符合目标的位置。
如果注册成功但引导失败，不要先重做计费；如果本地页面正常但发布物缺失，不要重写组件。下一步应该修复第一处断链。
可复制的续接简报
目标
本轮完成后，用户可以 [具体动作]。
当前已验证
- 当前分支与提交：
- 相关工作树改动：
- 已通过检查：
- 运行或页面证据：
必须保留的决策
- 产品边界：
- 公共行为：
- 数据权威：
- 已放弃路径：
尚未收口的缺口
- 第一处断链：
- 支撑证据：
- 为什么阻断用户结果：
下一次执行
- 授权范围：
- 必须验证：
- 停止条件：
- 期望交接：
哪些内容不该进入续接简报？
不要放入：
- 完整聊天记录；
- 尚未验证的根因猜测；
- 已经过期的旧计划；
- 与当前目标无关的未来想法；
- 没有结论的原始日志；
- 没有稳定身份的“最新版”。
原始材料可以保留用于审计，但不应要求下一个 Agent 先从日志海洋里找事实。
在不同 Coding Agent 之间切换
Codex、Claude Code、Cursor 和 Copilot 都有自己的会话机制。跨工具连续性应该放在所有工具都能读取的项目事实里：当前文件、聚焦的指令、路线图结果、验证证据和简短交接。
开发者关于跨 Agent 切换的讨论也指出了相同的丢失点：架构决策、项目约定、失败路径，以及选择背后的原因。参见切换 Coding Agent 时会丢失什么。
什么时候不应直接续接？
出现这些情况时，先暂停并重新规划：
- 依赖或平台合同已经发生明显变化；
- 生产状态不同于上次本地状态；
- 用户目标改变；
- 工作树里有无法解释的改动；
- 上次运行停在一次结果未知的外部写入中。
这时第一项任务应该是只读现实审计，而不是继续沿旧计划实现。
核心原则
从已经验证的项目状态继续，而不是从记忆中的对话继续。只要耐久事实一直留在项目旁边，一次可靠续接只需要几分钟。