对话已经持续很久。您否决了一个方案，也解释了原因，可十来条消息之后，智能体又提出了同一个方案。第一反应很自然：清空一切，重新开始。
重复提出被否决的方案是个明显信号，但还不能据此下结论。仅凭一条回复，无法判断问题是否来自越积越长的对话：需求相互矛盾，或者智能体依据的是半小时前的文件版本，看起来也一样。
我们来看看三个直接处理对话的命令：/context 显示上下文窗口的占用情况，/compact 将历史记录压缩成摘要，/clear 开始一段新对话。比起命令语法，更值得琢磨的是该选哪个：操作前要保存什么，操作后要核对什么，以及如何判断问题根本不在对话长度。
先找出问题
在压缩或清空之前，先把情况分成四类。表面上它们很相似，智能体看起来都像是"没听进去"，但对应的处理方法各不相同。
- 缺少必要信息。没人提过奖励的计算规则，已读文件里也没有。压缩对话不会凭空补出原本不存在的内容；缺少的信息还得由您补上。
- 信息已经过时。对话里保留着半小时前读过的文件内容，磁盘上的文件却已经更新。这时该重新读取，而不是压缩。
- 需求相互矛盾。聊天里说的是一回事，保存下来的任务说明却写着另一回事。请您判断当前以哪项要求为准，并修正信息源。文件并不会仅仅因为它是文件，就自动变成正确的版本。
- 噪声越积越多。有许多被否决的方案、冗长的命令输出，以及与任务无关的文件讨论。这种情况下，处理上下文才真正有用。
窗口占用率不是这份清单的第五类情况，也不能解释所有错误。占用率高本身并不能证明智能体因此出错，低也不能证明对话没有问题。检查顺序很简单：先看需求，再确认文件和命令输出是否最新，最后才检查对话本身的状态。
请 Claude Code 说出当前任务的目标、限制条件，以及它提出方案所依据的文件。将回答与您看到的内容对照。如果它提到了与任务无关的文件，或者目标与您设定的不一致，您就知道该修正什么了，而这完全可能与对话长度无关。压缩之后和开始新对话时，也可以问同样的问题。
查看窗口占用情况
如果您怀疑问题确实出在对话本身，可以查看 /context。该命令会按类别显示窗口的占用情况：系统部分、项目指令、已读取的文件和命令输出、对话内容，以及剩余空间。哪些信息对任务已经无用，由您来判断。命令不会评估已读取内容的意义，显示消息总量的那一行也不会告诉您具体哪个文件多余。
不存在"超过某个百分比就该压缩"这样的通用阈值；窗口大小也取决于模型和设置。关注内容构成，而不是百分比。另外请注意，关闭编辑器标签页并不会自动从对话中移除已经读取的内容。
压缩后继续当前任务
/compact 会将历史记录压缩成摘要，同时让您继续处理同一个任务。随着窗口逐渐填满，Claude Code 也会自动压缩；您手动运行它，是为了自行选择时机（例如开始一大段新工作之前）并指定重点。
关键限制是：保留下来的是摘要，而不是完整对话。摘要之外的细节不能指望仍留在窗口中。即使说"请保留这些条件"，也无法保证摘要一定完整；这只是请求，并非一种保障机制。
需要保存什么
运行命令前，先为任务写一份简短记录：目标、边界、已作出的决定、已核实的事实和下一步。花不了几分钟，但与凭记忆回想对话不同，这份记录可以和文件及检查输出相互核对。不必专门新建文件，放在现有任务文档里就够了。
下面是一个关于重复发放奖励的练习任务状态示例，不是已经完成检查的报告：
目标：同一场已结束的对局只发放一次奖励；新的一局可以再次发放。
边界：src/reward-flow.js 和现有的奖励检查；不要更改界面样式。
已确认：首次发放后，在同一局中再次点击会再次增加分数。
依据：TASK_SPEC.md 中记录了复现步骤和初始状态。
已否决：不修复重复点击的处理逻辑，只隐藏按钮。
下一步：检查处理程序并提出修改方案；尚未完成修复和测试。请留意最后一行。确认问题可以复现，与修复已经完成是两回事，记录中必须清楚区分，否则压缩之后，"检查过了"很容易变成"修好了"。这里的任务文档只是示例，请换成您自己的路径。
核对完记录后，就可以带着明确重点进行压缩：
/compact 请专注于修复重复发放奖励的问题。保留目标、TASK_SPEC.md 中的边界、已确认的复现步骤、被否决的方案和下一步。注明修复和测试尚未完成。之后核对什么
压缩后不要直接从半句话接着聊。先把必须准确的信息补回对话，再提出检查问题：
请阅读 TASK_SPEC.md 和最新的 src/reward-flow.js。简要说出限制条件和下一步。如果摘要与文件不一致，请指出差异。暂时不要修改代码。请逐条根据记录核对回答，而不是只凭整体印象。在这个例子中，要检查三件事：
- "下一步"一行没有把修复和测试说成已完成；
- "边界"中仍明确禁止更改界面样式；
- "目标"中的新一局可以再次发放奖励这一条件没有丢失。
智能体的措辞会有所不同，这很正常。如果有条件丢失，请在修改前从信息源中补回来。您检查的是对话状态，而不是代码；这样的核对并不能证明下一次修改一定正确。
压缩只处理对话历史。它不会撤销文件修改，也不能替代 Git。根目录中的 CLAUDE.md 会重新加载，因此项目规则会保留下来；但任务的临时状态不该写在那里："目前正在修复奖励发放"这句话会一直留着，即使任务早已结束。智能体在压缩后提到的信息也不会自动变得可信。请确认它的信息来源：摘要、重新读取的文件，还是新一轮运行。
开始一个新任务
/clear 会开启一段没有先前聊天记录的新对话。磁盘上的文件和项目指令仍然保留，已启用的自动记忆也可能继续使用，所以这里的"从头开始"指的是聊天记录。旧对话不会被删除，您仍可以通过 /resume 返回。
它很容易和 claude --continue 混淆，但两者的作用正好相反。您在会话中输入 /clear，是为了摆脱积累下来的历史记录；启动时在终端输入 claude --continue，则会连同完整历史一起恢复此文件夹中的最近一段对话。如果问题恰恰来自那段对话，--continue 会把您带回原处。
清空之前，请保存后续要用到的内容：记录、必要路径和检查输出。新对话需要清楚的任务说明，而不是暗示：目标、限制条件和路径。您可以用 @文件 指定要提供的文件；但请注意，这种提及只是引导读取，并不会限制对其他文件的访问。
选择合适的操作
整个流程很简短：先停下来，提出检查问题；如果不清楚窗口被什么占用，就查看占用情况；然后选择一项操作并核对结果。数消息条数没有意义，应该关注对话的构成，以及您接下来要做什么。
| 情况 | 操作及原因 |
|---|---|
| 智能体没有收到奖励计算规则 | 提供规则和文件；压缩无法补上缺失的信息 |
| 回答依据的文件后来已更改 | 让智能体重新读取最新版本；无需压缩 |
聊天中达成的约定与 TASK_SPEC.md 中的记录不同 | 判断哪项要求仍然有效，并修正信息源 |
| 同一任务中有许多被否决的方案，可用空间所剩不多 | 先做记录，再带着重点运行 /compact，然后提出检查问题 |
| 压缩后，"不得修改相邻模块"这条限制丢失了 | 重新读取限制条件的信息源，并在修改前确认理解无误 |
| 开始一个独立的界面样式任务 | 保存需要的结论，运行 /clear，重新说明任务 |
这些命令如何改变工作方式
这三个命令本身不会修复任何问题。它们改变的是您处理长任务的方式：
- 遇到奇怪的回答时，先检查任务说明和文件是否为最新，再检查对话；
- 压缩或清空前先准备一份已与文件核对的记录，压缩后再逐条核对回答；
- 新任务有自己的任务说明，而不是沿用上一段对话的残留内容。
看看同一个请求前后的差别。原来是：
你搞糊涂了，我们重来吧。改成：
当前任务是修复 src/reward-flow.js 中的重复发放奖励问题。
请阅读 TASK_SPEC.md，说出限制条件和下一步。暂时不要修改代码。第二种说法会引出可核实的回答：您可以将提到的限制和下一步与文件对照，马上发现差异。第一句话则无从核对。
GO TO FULL VERSION