02 · 一次能看多少代码
翔宇用 Claude Code 的头一个月，有时候它分析得头头是道，有时候聊着聊着就「变笨了」。翻了文档才发现，这不是智力波动，是工作台被堆满了。搞清楚这张工作
翔宇用 Claude Code 的头一个月，有时候它分析得头头是道，有时候聊着聊着就「变笨了」。翻了文档才发现，这不是智力波动，是工作台被堆满了。搞清楚这张工作台的运作方式之后，很多操作上的困惑就全解开了。——翔宇
要点速览
- 你将理解上下文窗口的本质——AI 在一次会话中同时能看到的信息总量
- 你将理解 100 万 token 具体有多大，以及它让哪一类问题从「不可能」变成「一眼看到」
- 你将理解上下文是怎么被消耗的，以及为什么它一定会满
- 你将理解满了之后的三种应对策略，以及它们各自适合什么场景
1. 从最简单的情况开始
想象你面前有一张桌子。你和 Claude 在这张桌子上协作——你把文件摊开，它看了之后给你建议。
这张桌子就是上下文窗口。
最简单的情况是这样的：桌子是空的，你问了一个问题，Claude 回答了。桌子上放了两样东西——你的问题和它的回答。很轻松，空间绰绰有余。
这是所有人最开始用 Claude Code 的体验：反应快、回答精准、感觉什么都能搞定。
但随着工作推进，事情会发生变化。
2. 桌子上的东西越来越多
你让 Claude 看了十几个文件。每个文件几百行，放上桌。
你让它跑了几次测试。测试输出了大量日志，放上桌。
你和它来回讨论了几十轮。它的每段分析——通常比你的提问长得多——放上桌。
还有一些你看不到但确实存在的东西也在桌上：Claude Code 自身的系统提示（大约 50 条内置指令），你的 CLAUDE.md 配置文件，Auto Memory 的 MEMORY.md 前 200 行。这些在每次会话开始时就自动上桌了。
💬 通俗讲 想象你在开一个长会。每个人说的话都在往白板上写——你说的、对方说的、中途查的资料、打开的文件。白板很大，但不是无限大。如果会开得够久，白板总会写满。
具体来说，以下这些都在消耗桌面空间：
你说的话。 每一条消息、每一个追问。
Claude 说的话。 它的每段回答、每段代码。别忘了——Claude 的回答通常比你的提问长得多，所以它自己其实是上下文的主要消耗者。
读取的文件内容。 一个 500 行的文件大约占 5000 到 7000 个 token。
执行命令的输出。 测试结果、编译日志、安装过程——跑什么就上什么。
系统级内容。 CLAUDE.md、MEMORY.md、内置系统提示。
到这里，你对上下文窗口已经有了一个基本画面：一张桌子，所有交互的内容都在往上堆。
3. 这张桌子有多大
现在给桌子加一个数字：100 万 token。
1 个 token 大约是 4 个英文字符（约 0.75 个英文单词），中文大约 2 个 token 对应 1 个汉字。所以 100 万 token 约等于 50 万中文字，大约是 5 到 6 本长篇小说的篇幅。
换算到代码场景：一行代码平均 10-15 个 token，100 万 token 大约能容纳 7 万到 8 万行代码。一个中型项目的全部源代码——从路由到模型到工具函数——通常在这个范围内。
停下来想想这意味着什么。
以前的版本是 20 万 token，大约能看 1.5 万行代码。你让它修一个登录 Bug，它只能同时看到登录相关的几个文件。路由文件看了，可能就放不下数据库迁移文件了。
🧠 底层逻辑 100 万 token 和 20 万 token 的区别不只是「大了 5 倍」。当你能同时看到整条链路时，你能发现的问题类型发生了质变。「路由传了 userId 但控制器期望 user_id」这种跨文件的字段不匹配——只看一个文件永远发现不了，必须同时看两个文件才行。100 万 token 让一类原本不可能发现的问题变得可以发现。
20 万 token 像是只能透过钥匙孔看房间——你能看清某个角落，但看不到全貌。100 万 token 像是打开了房门走进去——你能同时看到家具之间的空间关系。找一件东西的效率完全不同，不是快了 5 倍的问题，而是从「碰运气」变成了「一眼看到」。
想一想：如果有人问你「100 万 token 和 20 万 token 的区别是什么」，你会怎么回答？不是「大了 5 倍」——那只是数字。真正的区别是什么？
4. 加入一个新需求：桌子一定会满
现在我们的画面是：一张很大的桌子，所有交互内容都在往上堆。
下一个自然的问题：它会满吗？
答案是：看你怎么用。如果你只做简单问答——问个问题、得到回答、再问一个——100 万 token 可以聊很久很久。
但实际工作中不是这样。你让 Claude 读了十几个文件，每个几百行。你让它跑了几次测试，输出了大量日志。你和它来回讨论了几十轮，每轮它都写了长长的分析。这些加起来，消耗速度比你想象的快得多。
而且有一个容易忽略的点：上下文的消耗不是线性的。 随着对话深入，Claude 需要回顾之前的内容来保持连贯——这意味着每一轮新的交互，实际处理的信息量都在增长。
所以问题不是「会不会满」，而是「满了怎么办」。
🔑 关键点 上下文窗口不是一个「装东西的桶」——东西放进去就静静待着。它更像一个「每轮都要翻一遍的工作台」。每一轮交互，Claude 都要把桌上所有东西扫一遍才能回答。桌上东西越多，每轮扫描越慢、成本越高。所以「能用多少就用多少」不是最优策略，「只放需要的东西」才是。
5. 满了怎么办：三种策略
Claude Code 提供了三种应对策略，它们适用场景完全不同。
a. /compact——压缩，保留精华
/compact 是最常用的。它的原理是让 Claude 回顾当前对话，把核心信息提炼成精简摘要，然后用这个摘要替代原来那一大堆内容。
就像开了两小时的会，有人站起来说：「我来总结一下刚才讨论的要点。」然后擦掉白板上的细节，只留下几条关键结论。白板腾出了空间，核心决策没丢。
你还可以指定压缩的重点。比如 /compact 保留数据库相关的讨论——这样 Claude 在压缩时会特别保留数据库方面的信息，压缩掉其他不太相关的内容。
一个重要的细节：Claude Code 在上下文接近上限时会自动触发压缩。 你不需要时刻盯着 token 数。但如果你知道接下来要做的事跟之前的讨论完全无关——提前手动压缩是更聪明的做法。
b. /clear——清空，重新开始
/clear 更彻底。它直接清空整个对话历史，回到一张干净的桌子。
什么时候用？当你要切换到一个完全不同的任务时。比如你刚花了半小时修一个 Bug，现在要开始写一个新功能——这两件事之间没有关联。与其让 Bug 修复的上下文占着空间，不如清空重来。
/compact 和 /clear 的本质区别在于：/compact 是「压缩但保留」，/clear 是「全部丢弃」。判断标准很简单：问自己「接下来的任务跟刚才聊的有没有关系？」有关联用前者，无关联用后者。
c. 拆分任务——从源头减少消耗
⚡ 速记 三种策略不是互相替代：
/compact保留精华继续干，/clear清桌子换任务，拆分任务从一开始就别让桌子堆满。
第三种策略不是一个命令，而是一种工作方式：把大任务拆成多个小任务，每个小任务用一个独立的会话完成。
比如你要重构一个模块。与其在一个会话里把整个重构做完（读文件、分析、制定方案、逐个修改、跑测试……这一套下来上下文肯定爆），不如拆成几步：
第一个会话：让 Claude 分析模块结构，输出一个重构方案，保存到一个 Markdown 文件里。
第二个会话：读取那个方案文件，开始实施第一部分。
第三个会话：继续实施下一部分。
每个会话都从一张干净的桌子开始，只放当前步骤需要的东西。
拆分任务之所以高效，根本原因是：一个任务的每个阶段需要的信息是不同的。 分析阶段需要看很多文件但不需要之前的对话记录。实施阶段需要方案文件和目标文件但不需要分析过程。把所有阶段塞进一个会话，大量空间被已经「过时」的中间信息占据。拆开来，每个阶段的桌子上都只有当前最需要的东西。
6. 一个容易混淆的地方
到这里你可能注意到了：我一直在说「桌子」，没有说「记忆」。这是故意的。
很多人把上下文窗口类比成「记忆力」——100 万 token 就是记忆力超强，能记住很多东西。这个类比有一个致命的偏差：记忆是可以长期保留的，但上下文不是。
🎯 一句话理解 上下文窗口是 AI 在一次会话中同时能看到的信息总量，不是它能永久记住的东西。你一旦关掉这次会话，桌子上的东西全部清空。下次打开，桌子是空的。
「看到」和「记住」是两件事。你看一本书的时候，翻开的那些页面你都「看到」了——但合上书之后你不一定「记住」了。上下文窗口决定的是 Claude 能同时「翻开」多少页面，不是它能永久「记住」多少内容。
那 AI 怎么「记住」你的习惯和项目信息？那是另一套系统——永久记忆。下一篇会拆。
7. 回头看全貌
把前面所有内容串起来，形成一个可操作的心智模型：
开始一个任务时，桌子是空的（或者只有 CLAUDE.md 和 Auto Memory 的摘要）。这时候上下文很宽裕，可以放心让 Claude 读文件、跑命令。
工作进行中，桌子上的东西越来越多。你要有意识地关注这个趋势。如果你发现 Claude 的回答开始变得不那么精准、或者响应变慢了——这通常是上下文快满的信号。
当你感觉到信号时，做一个决定：
- 如果接下来的工作跟之前有关联 →
/compact - 如果要切换到完全不同的任务 →
/clear - 如果任务本身很大 → 拆成多个会话
整个过程中，最重要的习惯是：不要在一个会话里做太多不同的事。「一个会话一个主题」不是强制要求，但它是上下文管理最省心的方式。
上下文管理的核心原则：让桌子上永远只有当前最需要的东西。不是追求桌子多大，而是追求桌子多干净。
8. 你真的懂了吗
这篇拆了一个概念：上下文窗口。
回到费曼的检验方法——试试能不能用自己的话解释清楚：
- 有人说「100 万 token 就是记忆力好」。你能解释这个说法错在哪吗？上下文窗口和记忆的区别是什么？
- 上下文窗口从 20 万扩大到 100 万，为什么说这是「质变」而不只是「量变」？你能举一个只有看全貌才能发现的问题类型吗？
- 你的同事说「反正上下文有 100 万 token，不用管它」。你会怎么反驳？不管理上下文会导致什么后果？
/compact和/clear的区别是什么？你在什么情况下用前者，什么情况下用后者？
如果你能不看文章就回答这些问题，说明你真正理解了上下文窗口——不只是「知道有这个东西」。
这篇在概念网络中的位置
上一篇我们理解了 Claude Code 的核心设计决定是「位置」——AI 住在你电脑里。这篇拆解的是它「怎么看你的项目」——通过上下文窗口，一次把你的代码摊开在一张大桌子上。
理解了上下文窗口，接下来有两条路：
- 上下文是会话级别的，关机就没了。那 AI 怎么「记住」你的习惯和项目信息？ → 下一篇「记忆」
- 上下文能装多少东西，取决于你怎么说话——同样的意思，不同的表达，消耗的 token 天差地别。 → 第 4 篇「对话」