Checkpoint、压缩与 Session Fork

建议用时：25 分钟（含练习）

学习目标

能够在长任务中选择恢复、压缩或分叉，避免上下文臃肿和文件状态错位。

一份长任务 Session 管理方案

长任务中，聊天记录、工作目录、数据库和外部系统可能分别保存不同状态。回到早先一条消息，不一定回退文件；切换 Git 分支，也不一定清除聊天里的旧结论。因此讨论 Checkpoint、压缩和 Fork 时，必须说明究竟保存或复制了哪些状态。

术语

Checkpoint 是一个可用于恢复的检查点，但具体覆盖范围依赖产品。

压缩是在有限上下文中保留任务关键信息，并非无损备份。

术语

Fork 是从共同历史创建另一条探索路线，是否同时创建独立工作目录、是否复制未提交改动，都要核对实际工具行为。

共同检查点记录对话与文件版本，两条探索路线分别推进，集成前核对状态和验证结果

图中分叉的是工作路线，不是自动隔离所有资源。两个任务即使拥有不同聊天，也可能写同一个目录、使用同一数据库或争用同一端口。并行之前应指定独立修改范围与共享资源规则，避免把“开了两个窗口”误认为已经隔离。

检查点不需要复制所有日志。保留能够解释状态的摘要和可访问证据位置即可。对于结果未知的外部动作，应明确标记未知，并在恢复后先查询实际状态，不能按“没有成功消息”推断未执行。

假设任务分为检索、写作和发布草稿三个阶段。第一检查点保存来源清单、筛选理由和未解决冲突；第二检查点保存稿件版本、证据映射和审阅问题；最后检查点保存最终产物及验证结果。每个检查点都能解释下一阶段的输入是否完整。

在写作阶段，可以分叉两条路线：一条按概念组织，一条按案例组织。两条路线使用相同的已审核资料，但分别写入不同草稿文件。选择标准提前确定为读者能否完成练习、来源能否对应结论，以及结构是否清楚，而不是最后凭篇幅选择。

优先保留用户目标、明确约束、重要决策、实际修改、验证结果和待解决问题。可以舍弃重复讨论、已失效尝试的细节和大量无关输出，但某个失败如果解释了当前限制，就应保留简要原因。

压缩后需要做一次一致性检查：摘要里的“已完成”是否有证据，文件位置是否仍存在，版本是否对应当前目录，用户最近的修正是否被保留。压缩并不天然提高信息质量；错误摘要只会让错误更容易被反复使用。

恢复时先读目标和状态，再核对实际文件，最后执行下一步。合并两条路线时先审查各自产物与来源，再处理冲突，合并后重新验证。两条分支各自通过检查，不代表组合后也一定通过；重复段落、互相矛盾的定义和失效链接都可能在集成时出现。

对于第一次练习，使用无敏感数据的静态文件就足够。没有必要通过真实外部发布来证明自己理解恢复机制。模拟一次中断并让另一人接手，更容易暴露检查点中缺失的信息。

Checkpoint、压缩与 Session Fork

3 道题 · 及格分 60 分