---
title: "02 · 一次能看多少程式碼"
description: "上下文視窗不是記憶，是一張會滿的工作臺。100 萬 token 聽起來巨大，但用了 78% 你就會覺察 Claude 變笨——理解這張桌子怎麼運作、怎麼管，操作上的困惑就全解開了。"
canonical: "https://xiangyugongzuoliu.com/tag/claude-code"
verifiedAt: "2026-05-08"
---

Aaron用 Claude Code 的頭一個月，有時候它分析得頭頭是道，有時候聊著聊著就**變笨了**。翻了文件才發現，這不是智力波動，是工作臺被堆滿了。搞清楚這張工作臺的運作方式之後，很多操作上的困惑就全解開了。——Aaron

> [!NOTE]
> **這一篇用 13 分鐘換什麼**：上一篇 [01](/zh-Hant/docs/claude-code/understanding/01-what-is-claude-code) 我們理解了 Claude Code 的核心是**位置**——AI 住在你電腦裡。這一篇拆它怎麼**看**你的專案：透過上下文視窗，把程式碼攤在一張大桌子上。理解了桌子怎麼滿、怎麼管，後面的 CLAUDE.md、Skills、SubAgents 才有清晰的位置感。

## 1. 從最簡單的情況開始

想象你面前有一張桌子。你和 Claude 在這張桌子上協作——你把檔案攤開，它看了之後給你建議。

**這張桌子就是上下文視窗（context window，會話工作臺）**。

最簡單的情況是這樣的：桌子是空的，你問了一個問題，Claude 回答了。桌上放了兩樣東西——你的問題和它的回答。很輕鬆，空間綽綽有餘。

這是所有人最開始用 Claude Code 的體驗：反應快、回答精準、感覺什麼都能搞定。

但隨著工作推進，事情會發生變化。我們用一個具體的會話場景往下走——**今天你要修一個支付回撥的 bug**：

> [!NOTE]
> **👤 你**：賬戶充值後金額沒到賬，支付回撥日誌在 `/logs/payment.log`，可能跟 webhook 重試有關，幫我查一下。

> [!TIP]
> **🤖 Claude**：好，我先看 `payment.log` 和 webhook 處理程式碼 *(讀 8 個檔案：`logs/payment.log` 最近 200 行、`controllers/webhook.ts`、`services/payment.ts`、`models/transaction.ts`、`queue/retry.ts` ……)*

這個場景會貫穿整篇——從乾淨的桌子，一路跑到桌子被堆滿，再到我們決定怎麼處理。

## 2. 桌子上的東西越來越多

剛才那個支付 bug 調查繼續推進：你讓 Claude 看了 8 個檔案，每個幾百行；它跑了一次 webhook 重試測試，輸出了 600 行日誌；你和它來回討論了十幾輪，每輪分析至少 200 字……桌上已經堆了不少。

還有一些你看不到但確實存在的東西也在桌上：Claude Code 自身的系統提示（大約 50 條內建指令）、你的 CLAUDE.md 配置檔案、Auto Memory（自動記憶）的 MEMORY.md 前 200 行。這些在每次會話開始時就自動上桌了。

```mermaid
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 本長篇小說的篇幅。

換算到程式碼場景：

| 單位 | 大約 token | 實際大小 | 直覺對照 |
|------|------|------|------|
| **1 行程式碼** | 10-15 | — | 1 個完整語句 |
| **1 箇中型原始檔** | 3000-7000 | 200-500 行 | 一個 controller / service |
| **20 萬 token**（舊版上限）| 200,000 | 1.5 萬行程式碼 | 能看一個模組的幾個檔案 |
| **100 萬 token**（Sonnet 4.6 / Opus 4.7 當前）| 1,000,000 | 7-8 萬行程式碼 | 能看完一箇中型專案全部原始碼 |

> [!NOTE]
> **事實基準**：Opus 4.7、Opus 4.6、Sonnet 4.6 都支援 1M context window（[官方說明](https://code.claude.com/docs/en/model-config#extended-context)）。Max / Team / Enterprise 套餐 Opus 自動啟用 1M。其它套餐 / Sonnet 1M 可能需要額外用量。模型別名加 `[1m]` 字尾顯式啟用：`/model opus[1m]`。

回到支付 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%：

### 第 1-10 輪：7% 佔用

讀 8 檔案 + 跑測試 + 討論。桌上：原始碼 + 日誌 + Claude 的初步分析。


### 第 11-25 輪：18% 佔用

讓 Claude 重讀相關 controller 全部測試。又加了 12 個檔案 + 測試輸出。


### 第 26-40 輪：28% 佔用

檢查支付閘道器 SDK 原始碼。SDK 整個 `src/` 目錄 ≈ 6 萬 token 進入工作臺。


### 第 41-60 輪：55% 佔用

讓 Claude 寫修復程式碼 + 跑全量測試。大量長 diff + 測試日誌。


### 第 61-80 輪：78% 佔用

反覆改 + 驗證 + 聯調。所有歷史持續累加，沒東西被釋放。


### 第 81+ 輪：接近上限

你開始覺察 Claude 回答**變慢**、**變笨**——它需要掃描的桌面太大了。


**關鍵點**：上下文視窗**不是一個裝東西的桶**——東西放進去就靜靜待著。它更像一個**每輪都要翻一遍的工作臺**。每一輪互動，Claude 都要把桌上所有東西掃一遍才能回答。**桌上東西越多，每輪掃描越慢、成本越高**。所以**能用多少就用多少**不是最優策略，**只放需要的東西**才是。

而且有一個容易忽略的點：**上下文消耗不是線性的**。隨著對話深入，Claude 需要回顧之前的內容來保持連貫——這意味著每輪新互動，**實際處理的資訊量都在增長**。

**為什麼 Claude 在 78% 時會"變笨"**：模型每輪都要掃一遍桌上所有內容才能決定下一步動作。桌子越滿，掃描越慢、注意力越分散、關鍵資訊越容易被淹。這跟人開會到第 4 小時記不清前面討論一個道理——不是腦子壞了，是認知頻寬被堆滿。**1M token ≠ 1M 都好用**——經驗上 60-70% 佔用就開始觸發降級（Anthropic 的 prompt cache 機制對字首重讀有快取，但全域性注意力代價是真實的）。

所以問題不是會不會滿，而是**滿了怎麼辦**。

## 5. 滿了怎麼辦：三種策略

Claude Code 提供了三種應對策略，它們適用場景完全不同。先用一張決策樹判斷該走哪條路：

```mermaid
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：

<details>
<summary>/compact 壓縮</summary>

**原理**：讓 Claude 回顧當前對話，把核心資訊提煉成精簡摘要，然後用這個摘要替代原來那一大堆內容。

**比喻**：開了兩小時的會，有人站起來說要總結一下剛才討論的要點，然後**擦掉白板上的細節，只留下幾條關鍵結論**。白板騰出了空間，核心決策沒丟。

**回到支付 bug**：已經查到 78%，但 bug 還沒修完，正在反覆聯調。這時候用 `/compact`：Claude 把前 60 輪濃縮成一段 webhook 重試丟失冪等鍵、已修 4 檔案、測試還缺一輪，桌子從 78 萬 token 縮回 8 萬。**繼續幹活，不丟上下文**。

**進階用法**：指定壓縮重點。

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

**自動觸發**：Claude Code 在上下文接近上限時會**自動**觸發壓縮，你不需要時刻盯著 token 數。但提前手動壓縮 / 清空仍然更聰明。

✅ **適合**：任務還在進行 + 不能丟上下文
❌ **不適合**：下一步跟前面無關

</details>

<details>
<summary>/clear 清空</summary>

**原理**：直接清空整個對話歷史，回到一張乾淨的桌子。

**比喻**：擦掉整塊白板，重新開會。

**回到支付 bug**：bug 修完了，你接下來要寫一個新功能使用者郵件訂閱設定頁——這兩件事**完全不相關**。繼續在同一個會話裡幹，前面的 webhook / 冪等性討論就是噪音。`/clear` 比 `/compact` 更省 token。

**和 /compact 的本質區別**：

- `/compact` = 壓縮但**保留**核心資訊
- `/clear` = **全部丟棄**

判斷標準很簡單——問自己：接下來的任務跟剛才聊的有沒有關係？有關聯用前者，無關聯用後者。

✅ **適合**：切換到完全不同的任務
❌ **不適合**：當前任務還要繼續

</details>

<details>
<summary>拆分任務</summary>

**原理**：第三種不是命令，是**工作方式**。把大任務拆成多個小任務，每個用一個獨立會話完成。

**回到支付 bug**：其實它一開始就可以拆——

- **會話 1**（30 分鐘）：分析 webhook + 冪等性，輸出根因報告 + 修復方案，儲存到 `docs/bug-payment-webhook-analysis.md`
- **會話 2**（20 分鐘，乾淨桌子）：讀分析檔案，實施第一部分修復（修 `controllers/webhook.ts`）
- **會話 3**（30 分鐘，乾淨桌子）：讀分析檔案 + 修改後的 controller，寫測試 + 跑全量回歸

每個會話都從一張乾淨的桌子開始，**只放當前步驟需要的東西**。

**為什麼高效**：一個任務的每個階段需要的資訊是不同的。**分析階段**需要看很多檔案但不需要之前的對話記錄；**實施階段**需要方案檔案和目標檔案但不需要分析過程。把所有階段塞進一個會話，大量空間被已經過時的中間資訊佔據。

✅ **適合**：任務很大 + 階段之間能傳遞檔案
❌ **不適合**：必須強連續上下文的緊密任務

</details>

> [!TIP]
> **速記**：三種策略不是互相替代——`/compact` 保留精華繼續幹，`/clear` 清桌子換任務，**拆分任務**從一開始就別讓桌子堆滿。

**新手最常踩的坑：等 95% 才 /compact**。他們盯著進度條，到 95% 才動手壓縮——這時候 Claude 已經"變笨" 半小時了，前面的判斷質量大打折扣。正確做法是 **60-70% 主動 /compact**，趁還沒明顯降級時把桌子騰乾淨；或者更早就用"拆分任務"從源頭避免堆積。

另一個常見誤區：**以為 /compact 是免費操作**。壓縮本身要讓 Claude 把整張桌子讀一遍再總結——這一輪本身就消耗大量 token + 時間。所以 /compact 不是"想壓就壓"，是"任務還要繼續 + 上下文確實滿了"才用。簡單換主題直接 `/clear` 更省。

## 6. 一個容易混淆的地方

到這裡你可能注意到了：我一直在說**桌子**，沒有說**記憶**。這是故意的。

很多人把上下文視窗類比成記憶力——100 萬 token 就是記憶力超強，能記住很多東西。這個類比有一個**致命的偏差**：記憶是可以長期保留的，**但上下文不是**。

**一句話理解**：上下文視窗是 AI 在一次會話中**同時能看到**的資訊總量，**不是它能永久記住**的東西。你一旦關掉這次會話，桌上的東西全部清空。下次開啟，桌子是空的。

**看到**和**記住**是兩件事。你看一本書的時候，翻開的那些頁面你都看到了——但合上書之後你不一定記住了。**上下文視窗決定的是 Claude 能同時翻開多少頁面，不是它能永久記住多少內容**。

那 AI 怎麼記住你的習慣和專案資訊？那是另一套系統——**長期記憶**。下一篇 [03 · 怎麼記住你的習慣](/zh-Hant/docs/claude-code/understanding/03-memory) 會拆。

## 7. 回頭看全貌

把前面所有內容串起來，形成一個**可操作的心智模型**：

| 階段 | 桌子狀態 | 你該做什麼 |
|------|---------|---------|
| **開始任務** | 空（僅 CLAUDE.md + Auto Memory 摘要）| 放心讓 Claude 讀檔案、跑命令 |
| **工作進行中** | 持續累積 | 有意識關注趨勢：Claude 回答變慢 / 變笨 = 上下文快滿訊號 |
| **覺察到訊號** | 接近上限 | 走 §5 決策樹：`/compact` / `/clear` / 拆分 |
| **整個過程** | — | 一個會話一個主題——上下文管理最省心的方式 |

**底層邏輯**：上下文管理的核心原則——**讓桌子上永遠只有當前最需要的東西**。不是追求桌子多大，而是追求桌子多幹淨。

## 8. 檢驗你真懂了嗎

費曼說，檢驗你是不是真的理解一件事，試試能不能解釋給朋友聽。

| # | 試著用自己的話回答 | 對應章節 |
|:-:|------|------|
| 1 | 有人說 100 萬 token 就是記憶力好——你能解釋這說法錯在哪？上下文和記憶的本質區別是什麼？ | §6 |
| 2 | 上下文從 20 萬擴到 100 萬，為什麼是質變不是量變？舉一個只有看全貌才能發現的問題型別。 | §3 |
| 3 | **動手題** ⭐：在你下次 Claude Code 會話開始前，先想清楚這次任務要分幾步：① 調研 ② 設計 ③ 實現 ④ 測試。每步是同一個會話連著幹，還是開新會話？寫下你的拆分理由。提示：如果四步會議中前一步的程式碼片段對後一步**不直接相關**，就該開新會話——這就是 §5 拆分任務的核心。 | §4 + §5 |

> [!TIP]
> **過關標準**：能用一句話說清——**上下文視窗是 AI 一次會話能同時看到的資訊總量，不是永久記憶；桌子會滿，所以要主動管理。**

<details id="glossary">
<summary>📖 本篇術語速查表</summary>

| 英文 / 縮寫 | 中文 | 一句話解釋 |
|-------------|------|-----------|
| context window | 上下文視窗 | AI 一次會話中同時能看到的資訊總量，本篇主角 |
| token | 詞元 | 模型讀 / 寫文本的最小單位，1 箇中文字大約 2 token |
| 1M / 100 萬 token | 100 萬詞元 | Sonnet 4.6 / Opus 4.6 / Opus 4.7 當前的最大上下文 |
| `/compact` | 壓縮命令 | 把當前對話提煉成精簡摘要替換原內容，騰出桌面空間 |
| `/clear` | 清空命令 | 直接清空整個對話歷史，回到乾淨桌子 |
| CLAUDE.md | 專案記憶檔案 | 寫給 Claude 的長期指令，會話開始自動上桌（詳見 03 篇）|
| Auto Memory | 自動記憶 | Claude 自動維護的專案學習筆記，存在 MEMORY.md（詳見 03 篇）|
| MEMORY.md | 自動記憶主檔案 | 啟動時只載入前 200 行或 25KB（取較小）|
| prompt caching | 提示快取 | 重複字首快取機制，省 token 不省桌面空間 |

</details>

## 官方資料

- [How Claude Code works](https://code.claude.com/docs/en/how-claude-code-works)
- [Explore the context window](https://code.claude.com/docs/en/context-window)
- [Manage costs effectively](https://code.claude.com/docs/en/costs)

## 接下來去哪

<Cards>
  <Card title="➡️ 03 · 怎麼記住你的習慣" href="/zh-Hant/docs/claude-code/understanding/03-memory">
    上下文是一次性的，關機就沒。CLAUDE.md + Auto Memory 雙軌記憶系統怎麼讓 Claude 跨會話記住你的專案和偏好。
  </Card>
  <Card title="04 · 怎麼和 AI 說話" href="/zh-Hant/docs/claude-code/understanding/04-prompting">
    同樣的意思，不同的表達，消耗的 token 天差地別。提示詞不是模板遊戲，是資訊密度遊戲。
  </Card>
  <Card title="01 · Claude Code 是什麼（上一篇）" href="/zh-Hant/docs/claude-code/understanding/01-what-is-claude-code">
    複習一下：AI 住在你電腦裡這個根基，是怎麼決定後面所有功能能不能成立的。
  </Card>
</Cards>

不用按順序全讀。挑你最好奇的那條線走就行。
