理解对话上下文

什么是上下文窗口

每次你和 Claude Code 对话时，它能「看到」的信息量是有限的——这就是所谓的上下文窗口，大约 200K token。粗略换算的话，1 个中文汉字大约 1-2 个 token，1 行代码大约 10-20 个 token。

但上下文里装的不只是你敲进去的文字。之前的对话历史、读取过的文件内容、系统指令、项目上下文，这些全都在里面占着位置。

你可能遇到过这种情况：聊着聊着，Claude Code 的回答质量明显下降了，感觉它「变笨了」。这不是错觉。对话越长，上下文中的「噪声」越多，真正有用的信息占比就越低。我第一次遇到这个问题的时候还以为是 bug，后来理解了上下文机制才明白是怎么回事。

上下文如何被消耗

看一下这张表，你就能直观感受到上下文是怎么被吃掉的：

内容	约 Token 数	占比
系统指令 + CLAUDE.md	~5,000	2.5%
你的第一轮对话	~500	0.25%
Claude 读取了 3 个文件	~15,000	7.5%
Claude 的第一轮回复	~3,000	1.5%
…继续 10 轮…	~100,000+	50%+

注意最后一行——十轮对话下来，一半以上的上下文就没了。而这还不算它中途读取的其他文件。所以「省着用」不是一句空话。

基本管理策略

理解了消耗机制，管理策略其实就很自然了。

新任务，新对话

这是最简单也最有效的一条。当你要开始一个不相关的任务时，别在老对话里继续——直接开新的。之前对话里积累的上下文对新任务来说全是噪声。

精确引用文件

不要让 Claude Code「看看我整个 src 目录」。每读一个文件就是在消耗上下文，所以指定具体文件路径，只让它看它需要看的东西。

我的经验是，给 Claude Code 的指令越精确，它消耗的上下文越少，回答质量反而越高。这和给人布置任务其实是一个道理——范围越模糊，对方要做的「理解工作」就越多。

及时总结，重新开始

如果一个对话确实需要持续很多轮，可以在中途让 Claude Code 总结一下当前进展，然后把总结复制到新对话里继续。这相当于手动做了一次「上下文压缩」。

把上下文当成稀缺资源来管理。每一条消息、每一个被读取的文件都在消耗它。像管理内存一样管理上下文——这个类比比你想象的更贴切。