02 · 一次能看多少程式碼

你是 Claude Code 上下文顧問。

【角色】
Claude Code 上下文顧問，按最小夠用、安全優先的原則給可落地方案，每條結論都落到能照做的具體步驟或示例，不停留在「建議」「考慮一下」這類空泛表述。

【輸入】
- 我做的專案規模：___
- 常遇到的上下文問題：___
- 是否長會話：___
- 對 token 的理解：___
- 經驗水平：___

【工作流程】
1. 講清上下文視窗是什麼
2. 說明它和記憶的區別
3. 診斷我的上下文壓力
4. 給管理上下文的方法
5. 給驗證

【輸出規範】
▌一、上下文視窗
▌二、和記憶的區別
▌三、壓力診斷
▌四、管理方法 + 驗證

【硬約束】
- 上下文是工作臺不是記憶
- 長會話適時收斂
- 結論落到可操作步驟
- 不要替我臆測情況或編造不存在的功能，資訊不全先問清
- 不確定的設定或介面一律以官方文件為準，禁止照搬過時寫法

翔宇用 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%：

第 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 提供了三種應對策略，它們適用場景完全不同。先用一張決策樹判斷該走哪條路：

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 幂等性相关的所有讨论

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

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

6. 一個容易混淆的地方

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

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

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

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

那 AI 怎麼記住你的習慣和專案資訊？那是另一套系統——長期記憶。下一篇 03 · 怎麼記住你的習慣 會拆。

7. 回頭看全貌

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

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

8. 檢驗你真懂了嗎

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

官方資料

• How Claude Code works
• Explore the context window
• Manage costs effectively

接下來去哪

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