对话变长后，先看占用，再决定压缩
Claude Code上下文越来越长时，先用/context查看空间主要用在哪里，再考虑用/compact聚焦保留关键信息。压缩的是对话上下文，不是撤销磁盘文件，也不是增加账户使用额度。
如果任务连续引入巨大文件或重复工具输出，只压缩一次而不改变输入方式，空间可能很快再次被占满。应先找出反复进入上下文的来源，再选择分段读取、缩小输出或整理交接记录。
本文聚焦长任务中的上下文管理，与恢复旧会话、清除代码修改和调整计费额度分别处理。
压缩前，先写一份小而准确的保留清单
记录当前目标、已经确认的决定、实际改动文件、已运行的检查、失败的尝试和下一步。对尚未验证的假设明确标记，不要让压缩后的摘要把“可能原因”变成“已经修复”。
需要长期遵守的项目规则，应放在相应的持久说明中，而不是仅在很早的一轮对话里提到。官方说明自动管理上下文时可能清理旧工具输出并总结对话，早期细节不保证完整保留。
保留清单不应包含真实密钥、整份私人日志或无关材料。它的作用是让后续任务能回到证据，不是把所有旧内容再复制一遍。
怎样给/compact一个明确重点
在需要压缩时，可以提供聚焦范围，例如“保留API字段变更、已验证命令和剩余失败项”。这类要求应描述真正要保留的任务信息，而不是笼统地要求“全部记住”。
当前官方文档给出/compact带关注点的用法，也建议通过/context观察占用。命令与选项可能随版本调整，应以本机帮助和当前官方说明为准；本文没有操作你的真实会话。
压缩完成后，先请它复述目标和未完成项，并与刚才的清单对照，再继续写代码。这个简短核对能发现遗漏，但不能作为所有细节都被完整保存的证明。
压缩前后的核对练习
假设你正在修改一个虚构的导入接口，已经完成字段校验，但大文件测试尚未运行。压缩前的清单应写“字段校验已改；大文件路径待测”，并保留对应文件和测试入口。
压缩后，如果总结变成“导入功能已完成”，先纠正，再继续下一步。不要让错误摘要成为后续发布的依据，也不要因为摘要遗漏文件就立即重新实施同一段修改。
如果需要重新读取代码，先看当前文件与差异。上下文摘要中的旧代码片段可能已经过期，磁盘状态应另行核对。
总是压缩后马上又满，查什么
查看是否有某个单次工具输出、文件或反复引入的资料占用大部分空间。先缩小读取范围、过滤必要段落或把任务拆成可验收步骤，而不是持续循环压缩。
官方说明，面对持续反复填满上下文的情况，自动压缩可能在若干次尝试后停止并报告错误。不要把这种状态直接解释为账号额度不足，也不要通过无限重试掩盖输入结构的问题。
涉及多个独立任务时，分别保存目标、工作区和交接记录，有助于减少无关上下文；是否使用新的会话或其他功能，应根据任务连续性决定，不能让不同任务共享一份含糊摘要。
哪些操作不能被混淆
压缩不撤销Git修改，不恢复旧数据库，也不保证服务仍然运行。要回滚文件、恢复数据或清理进程，应分别核对相应工具和风险，不通过聊天上下文操作替代。
本文命令含义已参照官方说明，练习场景为原创，没有对真实项目运行压缩、清空或回滚操作。文末清单可以作为你实际使用前后的核对记录。
参考资料与核验范围
资料核对日期：2026年10月18日。以下为官方原始资料；产品入口和可用范围仍以当前账户为准。
1. [官方资料1](https://code.claude.com/docs/en/how-claude-code-works)
2. [官方资料2](https://code.claude.com/docs/en/interactive-mode)