交接时真正想解决的是什么
这次讨论交接时，我先遇到一个看似简单、实际很容易做偏的问题：新窗口不要读取原来那个会话的聊天记录。听上去，这句话像是在要求切断新旧会话之间的联系；但把它放回实际工作里看，需求并不是“原来的内容不要了”，而是“不要让新窗口承载一段过长的历史”。
这两件事只差一个转折，结果却完全不同。前者是在删除来源，后者是在控制上下文。新窗口需要的是一个能继续做事的起点，而不是把前面所有说过的话重新放进来。它应该知道任务要做到哪里、已经确认了什么、哪些地方可能需要追溯；只有在证据不足时，才回到源会话取那一小段信息。
交接的目的不是让新窗口背下全部历史，而是让它在需要时知道历史在哪里。
我一开始也容易把“不要读取原会话”理解成“不要再碰原会话”。后来发现，真正的边界应该画在日常执行和异常回查之间：日常执行只依赖压缩后的交接内容，异常回查才使用源会话。这样做既减少了上下文负担，也没有把原来的判断链凭空抹掉。
长上下文为什么会变成交接问题
长任务往往不是一次对话就能结束。前面的窗口可能已经积累了背景、尝试、修正、分支和暂时放下的问题。把这些内容全部带进新窗口，表面上像是完整，实际上会让接手者先花大量精力分辨哪些是目标，哪些只是过程噪声。
如果不处理，后面会出现两个后果。第一个是上下文越来越长，真正需要执行的内容被埋在历史里；第二个是新窗口开始依赖原对话的整体气氛，而不是依赖已经确认的结论。它可能把早期的猜测当成最终决定，也可能为了“保险”重复阅读所有记录，交接反而变成重新开工。
这件事表面上是聊天记录太长，实际上是信息没有分层。任务目标、当前状态、关键证据和未决问题的价值不同，不能用同一种方式保存。交接文档应该承担压缩和排序的工作，把下一步行动所需的信息放在前面，把完整历史留在可以定位的源头。
这里的“压缩”也不是随意删字。删掉重复解释可以，删掉结论依据就会让后续无法判断。真正要压缩的是阅读路径，而不是证据本身：新窗口先读少量高密度信息，遇到缺口再沿着入口回到原处。
不要读取，不等于找不到
这次实践中反复出现了一个误判：有人要反查某个源会话时，会说这个会话不在了。但实际情况可能只是它被归档了，或者没有出现在当前列表的显眼位置。它不在眼前，不等于它不存在；暂时看不到，也不等于没有定位办法。
最容易误判的地方，是把“当前没有直接看到”当成“源会话已经消失”。一旦这个判断成立，接手者就会放弃回查，转而凭记忆补全缺失信息。这样看似推进很快，实际上把原本可以验证的内容变成了未经确认的假设。
我选择在交接里保留源会话的定位信息，是因为它的作用不是要求新窗口立即打开全部历史，而是在证据不足时提供一条可走的路。定位信息可以是稳定的会话标识、明确的来源说明，或者足以缩小搜索范围的线索。它不需要把历史复制一遍，却必须让后续的人知道应该回到哪里查。
源会话定位信息是交接的保险丝：平时不增加阅读负担，出问题时能阻止人靠猜。
这也解释了为什么归档状态不应直接被当成不存在。归档改变的是可见性和访问路径，不一定改变源内容的存在。交接设计要区分“列表里是否显眼”和“是否还能被定位”，否则每次换窗口都会因为界面状态不同而丢掉事实依据。
两层信息，分别服务执行和追溯
我现在更愿意把一份可靠的交接看成两层。第一层是给新窗口日常使用的压缩层，里面只放任务目标、当前进度、已经形成的结论、关键证据和下一步。它要能让接手者直接行动，不必先通读一段漫长历史。
第二层是给异常情况使用的回查层，里面放源会话的定位和回查方式。它不是正文的替代品，也不是要求每次都打开的附件，而是对第一层的可验证补充。当某个结论缺少依据、某个细节影响当前选择，或者发现交接内容彼此不一致时，才进入这一层。
这两层不能互相替代。只有压缩层，没有源定位，交接会变成一份无法追溯的摘要；只有回查层，没有压缩层，新窗口每次都得从历史里捞信息，交接没有真正减轻负担。一个层负责让事情继续，一个层负责让判断经得起追问。
具体到写法，我会先写“现在要完成什么”，再写“已经确定了什么”，然后留下“哪些证据支撑这些判断”。最后补上源会话定位和触发回查的条件。这样，接手者读到的不是一串聊天发生顺序，而是一张可以行动、也可以追溯的路线图。
精准回查比完整搬运更可靠
需要原始信息时，下一步不是把整段历史再次复制，而是先明确缺口。缺的是哪一个事实？它影响哪个判断？需要确认的是原话、时间、上下文，还是某个已经做过的取舍？问题越具体，回查范围就越小，结果也越容易验证。
比如，交接只说明“某个判断已经确认”，但没有留下判断依据。新窗口不需要重新读取从头到尾的所有内容，而应根据源会话定位，搜索与这个判断相关的那一段。查到之后，再把确认结果补回交接文档。下一次接手时，第一层信息变得更完整，源会话仍然作为最后的证据入口保留。
这种做法有一个重要的闭环：交接不是一次性摘要，而是会在回查后被修正的工作记录。回查发现原判断仍然成立，就补充证据；发现当时只是一个暂定方案，就把状态改成待确认；发现源会话位置有变化，就更新定位方式。回查不是把人送回过去，而是把过去的有效信息带回现在。
如果为了省上下文，直接丢掉源会话地址，短期看似清爽，长期却会导致无法追责、无法取证，也无法恢复中断的工作。反过来，如果为了保险，每次交接都复制整段历史，新的窗口会被冗余内容拖慢，真正重要的判断也更难被看见。这两个错误捷径方向相反，本质上都是没有区分“平时要读什么”和“出问题时要查什么”。
交接的价值在于保留判断链
这件事让我重新意识到，交接并不是把信息从一个窗口搬到另一个窗口，而是把判断过程留下一个可恢复的结构。完整聊天记录当然有价值，但它的价值更像档案；交接文档的价值，则是让下一步行动不必从档案整理开始。
真正难的不是写出一份足够长的摘要，而是判断什么信息必须随任务前进，什么信息可以留在源头等待调用。任务目标必须前置，因为没有目标就无法判断取舍；当前状态必须明确，因为不知道已经做到哪里就会重复劳动；关键证据必须留下，因为没有证据的结论只能靠信任；源会话必须可定位，因为压缩永远可能漏掉后来才发现的重要细节。
一个流程成熟的标志，不是它能把所有东西都保存下来，而是它能在不牺牲可追溯性的前提下减少日常负担。对我来说，这个标准比“新窗口有没有看到完整历史”更有用。新窗口不需要拥有过去的一切，但必须拥有继续工作和必要时回到过去的能力。
好的交接让人先按结论行动，再按证据回查，而不是先在历史里迷路。
下次我会怎么做
下次遇到长任务交接，我会先把内容拆成两问。第一问是：接手者现在必须知道什么，才能继续做？第二问是：如果他对某个判断产生疑问，应该回到哪里、用什么线索查？前一问形成压缩层，后一问形成回查层，两个答案都写进交接，但不混成一段历史复述。
我会在交接中至少留下任务目标、当前状态、关键结论、支撑证据、源会话定位和回查条件。写完后先用一段独立的模拟阅读检查：假设新窗口没有上下文，它能否直接知道下一步？再假设它遇到一个证据缺口，它能否精准找到原处？如果只能做到其中一项，交接还没有完成。
如果源会话显示为归档，或者暂时不在列表里，我不会立即把它判定为不存在，而会先按定位信息尝试查找。只有确认无法定位，才把这个缺口明确标出来，而不是用猜测填上。回查得到的新事实，也会写回交接，让后来的接手者不必重复相同的搜索。
最后，我会提醒自己：交接不是把过去搬得越多越安全，而是让未来在需要时找得回来。 这条规则适用于长对话，也适用于项目文档、研究记录和任何需要换人、换窗口继续推进的工作。压缩让事情走得动，入口让判断回得去；两者同时存在，交接才真正可靠。