02 · 一次能看多少代码

翔宇用 Claude Code 的头一个月，有时候它分析得头头是道，有时候聊着聊着就变笨了。翻了文档才发现，这不是智力波动，是工作台被堆满了。搞清楚这张工作台的运作方式之后，很多操作上的困惑就全解开了。——翔宇

1. 从最简单的情况开始

想象你面前有一张桌子。你和 Claude 在这张桌子上协作——你把文件摊开，它看了之后给你建议。

这张桌子就是上下文窗口（context window，会话工作台）。

最简单的情况是这样的：桌子是空的，你问了一个问题，Claude 回答了。桌上放了两样东西——你的问题和它的回答。很轻松，空间绰绰有余。

这是所有人最开始用 Claude Code 的体验：反应快、回答精准、感觉什么都能搞定。

但随着工作推进，事情会发生变化。我们用一个具体的会话场景往下走——今天你要修一个支付回调的 bug：

这个场景会贯穿整篇——从干净的桌子，一路跑到桌子被堆满，再到我们决定怎么处理。

2. 桌子上的东西越来越多

刚才那个支付 bug 调查继续推进：你让 Claude 看了 8 个文件，每个几百行；它跑了一次 webhook 重试测试，输出了 600 行日志；你和它来回讨论了十几轮，每轮分析至少 200 字……桌上已经堆了不少。

还有一些你看不到但确实存在的东西也在桌上：Claude Code 自身的系统提示（大约 50 条内置指令）、你的 CLAUDE.md 配置文件、Auto Memory（自动记忆）的 MEMORY.md 前 200 行。这些在每次会话开始时就自动上桌了。

flowchart TB
    Desk["📋 上下文窗口<br/>（你的工作台）"]

    System["🧠 系统级内容<br/>会话开始自动上桌"]
    User["💬 你说的话<br/>每条消息、每个追问"]
    AI["🤖 Claude 的回答<br/>通常比你的提问更长"]
    Files["📁 读取的文件<br/>500 行 ≈ 5000-7000 token"]
    Cmd["⚡ 命令执行输出<br/>测试 / 编译 / 安装日志"]

    System --> Desk
    User --> Desk
    AI --> Desk
    Files --> Desk
    Cmd --> Desk

    Desk -.->|持续累积| Full["⚠️ 桌子被堆满<br/>表现开始下降"]

    style Desk fill:#dbeafe,stroke:#3b82f6,stroke-width:2px
    style Full fill:#fef3c7,stroke:#f59e0b,stroke-width:2px
    style AI fill:#fee2e2,stroke:#ef4444

通俗讲：想象你在开一个长会。每个人说的话都在往白板上写——你说的、对方说的、中途查的资料、打开的文件。白板很大，但不是无限大。如果会开得够久，白板总会写满。

回到支付 bug 的会话。10 轮对话后，桌上已经堆了：

• 8 个源文件 ≈ 4 万 token
• 600 行日志 ≈ 8000 token
• Claude 的 10 段分析 ≈ 1.5 万 token
• 你的提问 + 系统提示 + CLAUDE.md ≈ 3000 token

加起来 7 万 token——感觉写满了？还差得远。继续往下读。

3. 这张桌子有多大

现在给桌子加一个数字：100 万 token（1 million token，词元）。

1 个 token 大约是 4 个英文字符（约 0.75 个英文单词），中文大约 2 个 token 对应 1 个汉字。所以 100 万 token 约等于 50 万中文字——5 到 6 本长篇小说的篇幅。

换算到代码场景：

回到支付 bug 的场景。我们刚才算了 7 万 token——这张桌子用了 7%。剩下 93 万 token 还能装很多东西。

但能装很多东西不等于应该装很多东西。这就引出了下一个问题。

100 万 token 和 20 万 token 的区别不只是大了 5 倍。当你能同时看到整条链路时，你能发现的问题类型发生了质变——路由传了 userId 但控制器期望 user_id 这种跨文件的字段不匹配，只看一个文件永远发现不了。100 万 token 让一类原本不可能发现的问题变得可以发现。

20 万 token 像是只能透过钥匙孔看房间——你能看清某个角落，但看不到全貌。100 万 token 像是打开了房门走进去——你能同时看到家具之间的空间关系。找一件东西的效率完全不同，不是快了 5 倍，而是从碰运气变成了一眼看到。

4. 桌子一定会满

下一个自然的问题：它会满吗？

答案是：看你怎么用。如果你只做简单问答——问个问题、得到回答、再问一个——100 万 token 可以聊很久很久。

但实际工作中不是这样。继续支付 bug 的故事——你越查越深，桌子从 7% 一路膨胀到 78%：

关键点：上下文窗口不是一个装东西的桶——东西放进去就静静待着。它更像一个每轮都要翻一遍的工作台。每一轮交互，Claude 都要把桌上所有东西扫一遍才能回答。桌上东西越多，每轮扫描越慢、成本越高。所以能用多少就用多少不是最优策略，只放需要的东西才是。

而且有一个容易忽略的点：上下文消耗不是线性的。随着对话深入，Claude 需要回顾之前的内容来保持连贯——这意味着每轮新交互，实际处理的信息量都在增长。

所以问题不是会不会满，而是满了怎么办。

5. 满了怎么办：三种策略

Claude Code 提供了三种应对策略，它们适用场景完全不同。先用一张决策树判断该走哪条路：

flowchart TD
    Start["⚠️ 觉察上下文接近上限<br/>Claude 回答变慢 / 变笨"]
    Q1{"接下来的工作<br/>跟之前有关联吗？"}
    Q2{"任务本身能不能拆<br/>成多个独立步骤？"}
    Compact["✨ /compact<br/>压缩当前对话保留精华"]
    Clear["🧹 /clear<br/>清空重来"]
    Split["🪓 拆分任务<br/>每步用独立会话"]

    Start --> Q1
    Q1 -->|有关联，要继续| Q2
    Q1 -->|完全无关，换主题| Clear
    Q2 -->|可以拆| Split
    Q2 -->|不能拆，必须连续做| Compact

    style Compact fill:#dcfce7,stroke:#22c55e
    style Clear fill:#dbeafe,stroke:#3b82f6
    style Split fill:#fef3c7,stroke:#f59e0b
    style Start fill:#fee2e2,stroke:#ef4444

三种策略各自的细节看下面的 tab：

/compact 保留 webhook 幂等性相关的所有讨论

6. 一个容易混淆的地方

到这里你可能注意到了：我一直在说桌子，没有说记忆。这是故意的。

很多人把上下文窗口类比成记忆力——100 万 token 就是记忆力超强，能记住很多东西。这个类比有一个致命的偏差：记忆是可以长期保留的，但上下文不是。

一句话理解：上下文窗口是 AI 在一次会话中同时能看到的信息总量，不是它能永久记住的东西。你一旦关掉这次会话，桌上的东西全部清空。下次打开，桌子是空的。

看到和记住是两件事。你看一本书的时候，翻开的那些页面你都看到了——但合上书之后你不一定记住了。上下文窗口决定的是 Claude 能同时翻开多少页面，不是它能永久记住多少内容。

那 AI 怎么记住你的习惯和项目信息？那是另一套系统——长期记忆。下一篇 03 · 怎么记住你的习惯 会拆。

7. 回头看全貌

把前面所有内容串起来，形成一个可操作的心智模型：

底层逻辑：上下文管理的核心原则——让桌子上永远只有当前最需要的东西。不是追求桌子多大，而是追求桌子多干净。

8. 检验你真懂了吗

费曼说，检验你是不是真的理解一件事，试试能不能解释给朋友听。

接下来去哪

不用按顺序全读。挑你最好奇的那条线走就行。