Claude Code 越聊越乱，该清空还是压缩？

同一个会话里，你先让 Claude Code 排查登录问题，接着聊了页面样式，又回头处理会话恢复。中间它读了长长的日志和旧配置，还否决过两个方案。

聊到后来，它忽然又提出那个早已排除的方案 A，一次测试的输出还刷了几千行。你开始犹豫：该 /clear 重来，还是 /compact 压缩一下，要不要先写个交接文件？

多数人把这种状况归结为“上下文满了”，背后其实可能是两件事：

• 窗口快装不下了
• 窗口里的信息已经乱了，旧目标、过期日志和被否决的方案混在一起，窗口再大也理不清

前一种靠腾空间，后一种靠整理，混在一起判断，就容易清掉不该清的，压缩时又丢了关键结论。

所以处理的顺序很清楚：先找出干扰来自哪里，再想办法让多余的内容别再涌进来，最后才轮到选清空、压缩还是交接。

测试日志怎样既控制长度又保住真实的退出码，一份能让别人接着干的交接文件该写些什么，清理完怎样确认任务没有丢，都按这个顺序往下说。

01 空间不足与依据混乱要分开查

窗口接近上限时，重要信息可能难以继续保留；窗口还有空间时，旧目标、过期日志和已否决方案也可能干扰判断。这些冲突要靠整理来消除，窗口再大也一样。

上下文工程是为当前判断组织相关、准确、充分且状态清楚的信息，Anthropic 的工程博客对此有系统的讨论。容量决定能容纳多少，整理则决定哪些信息仍有效，两者需要分别检查。

Claude Code 每次请求模型时，会组织当前可用上下文。常见内容按治理用途可分为三类：

工具输出也属于动态信息，这里单独列出，因为它有时会突然变得很长。规则和扩展什么时候加载，由配置决定；表中各项内容是否已经加载，要以当前会话的加载记录为准。

接近容量边界时，Claude Code 会管理旧工具结果并在需要时压缩对话，使工作继续。摘要会舍弃细节，架构决策的理由、早期临时约束和失败尝试都可能只剩片段。对话虽然能继续，还是要检查这些关键状态。

02 找出需要处理的上下文

发现会话状态不清时，可以先用 /context 观察占用，再结合实际加载、读取与行动记录判断相关性。占用统计只反映用了多少空间，某条结论是否过期要看记录；反应变慢也可能来自模型、网络或工具等待。

本例有两项问题：测试输出过长，已排除的方案 A 又进入判断。前者要控制后续输出，后者要重新明确排除依据。压缩前先整理当前目标、已确认事实、已排除方案和未验证改动，避免仅减少文本却保留错误状态。

如果反复出现的是同一条过期项目规则，则还需要修正加载源。压缩旧历史后，下一次又加载旧规则，问题仍会回来。一次治理可能需要同时澄清已有状态、控制后续输入，再选择相应的清理方式。

已经出现的长输出会留在历史里，之后再运行短命令也还在；每轮重新加载的长规则，压缩一次后还会回来。要区分“处理已有内容”和“阻止新噪声继续进入”。

03 控制工具输出，保留证据

一次完整测试可能返回几千行：

running 262 tests
test auth::test_login ... ok
test auth::test_logout ... ok
...

下一步通常需要知道总体结果、失败用例、关键堆栈、退出状态，以及该读哪个文件。大量通过项会增加查找负担，完整日志却仍可能包含后续排查需要的细节。可以把原始输出保存在文件里，只向会话提供摘要和回查位置。

先确认项目测试命令，再决定哪些输出要进入会话。怎么跑和返回多少日志是两回事；测试改成串行执行，日志量照旧。

直接截取末尾输出，可能同时丢失失败线索和真实退出状态：

npm test 2>&1 | tail -80

标准 shell 管道通常返回最后一个命令的状态。tail 成功时，测试即使失败，管道也可能返回 0。可先保存原始日志和测试状态，再显示摘要：

test_status=0
npm test > /tmp/claude-test.log 2>&1 || test_status=$?
tail -n 80 /tmp/claude-test.log
printf 'test exit code: %s\n' "$test_status"
exit "$test_status"

这里先保存测试状态，再显示末尾，并把原状态作为脚本结果返回。即使末尾只有汇总，也可以按日志路径回查失败堆栈。固定日志名适合单次示例；并行运行时应为每次执行使用独立文件，避免覆盖证据。

项目脚本或输出过滤工具也可以生成结构化摘要，但要能追溯原始输出，“少返回”的同时保留坏消息。不同任务需要的摘要不同：

输出是否合适，应以“能否决定下一步”判断。摘要不足时按需展开相关部分。

04 清空、压缩、交接怎么选

切换无关任务时清空。 登录任务完成，开始不相关的页面工作时，可以用 /clear 清理当前会话上下文。它不撤销磁盘改动，也不删除持久化项目规则；后续加载哪些说明，仍需按配置确认。如果页面任务依赖刚修改的接口，先保留接口结论与验证状态，再切换会话。是否清空要看依赖关系，任务标题变了未必该清。

同一任务推进时压缩。 原因已经查明，下一步按确认方案实施，可以用 /compact 摘要探索过程。它保留经过选择的会话信息，为继续同一目标腾出空间。摘要可能漏掉或弱化“为什么放弃方案 A”“哪个测试还跑不了”“哪些文件必须不动”。这些信息重要时，可以指定压缩重点，再检查摘要后的状态。压缩要保留什么，也可以提前写进 CLAUDE.md 的 Compact Instructions。

用交接文件保留状态。 HANDOFF.md 是人为约定的交接文件名。将必要状态写入磁盘后，接手会话还需明确读取，并核对是否符合当前文件状态。

清空适合无关任务切换，压缩适合同一任务继续推进，交接适合需要审查或跨会话保留的状态。三者也可以配合，例如先交接必要结论，再清空并开始下一任务。

05 写一份能接着干的交接

交接让接手者直接了解现状，并按需回查探索过程。至少保留：

• 当前目标、范围和临时约束；
• 关键文件与已经确认的事实；
• 尝试过的方案、有效方案和已排除方案的理由；
• 已改文件与改动意图；
• 验证命令、结果，以及未运行或被阻塞的检查；
• 未解决风险与下一步动作。

下面是一份构造的交接片段，路径和测试名称仅为教学示例：

# 登录恢复排查交接

## 当前目标
修复刷新后匿名会话被重新创建的问题。
本次不重做登录界面，主动退出行为须保留。

## 已确认与已排除
- `refresh-session.test.ts` 能复现刷新后会话 ID 改变。
- 已核对恢复调用链，未经过 `legacy/login.ts`。
- 方案 A（继续修改旧登录模块）已排除，原因是它不在失败路径上。

## 改动
- 已修改 `src/auth/restore-session.ts` 的恢复分支。
- 改动意图：已有会话有效时复用，不直接创建新会话。
- 根因判断仍需通过复验确认。

## 验证状态
- 修改前刷新测试失败。
- 修改后该测试尚未运行。
- 主动退出行为尚未检查。

## 风险与下一步
- 先核对当前分支与差异，确认这些改动还在。
- 从项目测试脚本确认运行入口，复验刷新测试。
- 再检查主动退出；不能仅凭刷新通过就宣布全部完成。

交接把“已修改”与“尚未运行验证”分开，接手者才能判断下一步仍需复验。排除方案时保留理由，也能减少重复调查。修改完成就写修改完成，验证通过才写验证通过，实际状态用事实描述，少用“基本完成”。

写完要核对目标、修改和验证状态。新会话读取交接后，还要检查当前分支、工作目录与文件是否仍匹配，因为文件可能在会话之间变化。交接提供继续工作的起点，接手时仍需核实状态。

06 在探索开始前就隔离噪声

上面处理的都是已经进会话的信息。如果接下来还要扫描大量代码，可以在探索开始前就决定哪些过程留在主会话。

Subagent 的独立上下文可以承接一段高噪声但边界明确的探索。 例如主会话已经决定检查恢复入口，却还需要搜索相关调用方，可以把这段只读搜索分出去：

只读搜索会话恢复入口的调用方，不修改文件。
返回相关路径、调用关系、支持判断的证据和未确认项。
完整过程留在子任务中，不粘贴大段源码。
遇到无法访问的文件，说明缺口，不猜测调用关系。

主会话收到的应是可继续判断的结果。“调用方在三个文件中，分别承担这些职责”比“已完成搜索”有用；需要核实时仍能回到具体文件。如果摘要太短，连依据都丢了，主会话还得重新调查。

只有当子任务可以独立产生结果时，这种隔离才有明确收益。如果它每读一个文件都要等待主会话决定方向，就不适合强行拆分。权限和文件写入隔离要另外处理，见多个子代理并行改代码，先划分好谁写哪份文件。

Plan Mode 则解决“何时进入修改”的问题：复杂任务可以先探索并核对计划，减少走错方向后产生的返工记录。已有噪声仍要用压缩或交接来清理。

07 清理之后核对任务状态

回到登录恢复任务。已有大量探索历史，下一阶段只需复验改动，可以先核对上面交接中的状态，再用 /compact 压缩，或开启新会话，明确让它读取交接后再继续。选择哪一种，取决于是否需要可审查、跨会话复用的交接，以及剩余历史是否仍有价值。

处理完成后，除了查看腾出的空间，还要确认能否正确回答：当前改了什么、哪个结果尚未验证、下一步应该运行哪项检查。如果回复把“尚未运行”说成“测试通过”，就根据原记录纠正，再继续。

条件变化时，选择也会变化：

同样是会话变长，解决办法可能是整理历史、更新状态、修正规则或收紧输出。先找造成干扰的内容，再改变它的进入或保留方式，最后确认任务仍能继续，才完成一次上下文治理。