Claude Code 上下文窗口新手指南：1M context 与 Auto Compact 怎么用

⏱️ 预计阅读 16 分钟 ｜ 🎯 目标：用新手能懂的方式讲清 Claude Code 的上下文窗口——1M context 怎么开、Auto Compact 怎么压、context rot 是什么、/compact 和 /clear 怎么选、什么时候真的该开 1M。看完你能判断自己该不该用，以及怎么管才不踩坑。

先别被术语吓住。把上下文窗口想成一张工作台：1M context 是把台面换大了，但台面再大，材料该整理还是要整理。这篇只做一件事——把这些机制讲清楚，再给你一条能动手的最小路径。

30 秒答疑：先把结论拿走

如果你只想快速判断 Claude Code 的 1M context 该不该用，一句话：默认 200K 就够用，1M 是长任务的兜底上限能力，不是日常目标。

最常见的新手误区：以为「窗口越大越好，开了 1M 就不用整理材料了」。正好反了——Anthropic 官方文档把这件事说得很直白：「更多上下文不会自动更好」，整理上下文里放了什么，和窗口有多大同样重要。

下面把这些一条条讲透。

一、先搞懂：上下文窗口到底是什么

上下文窗口（context window），指的是 Claude 这一次任务里能同时参考的全部文字——包括你贴进去的代码、和它的对话历史、读过的文档、跑出来的日志，以及它自己生成的回复。官方把它形容成模型的「工作记忆」（working memory），区别于它训练时学过的海量知识。

这里有个新手最该先记住的事实：Claude Code 每开一个新会话都是一张白纸，它不记得你上次聊过什么。它在这一次任务里能依据的，只有当前上下文窗口里的东西。所以「窗口里放了什么」直接决定它判断得准不准。

默认情况下，它大约能放 200K token（约等于十几万到二十万汉字的量级，足够装下相当多的代码和对话）。而本文的主角 1M context，就是把它扩成五倍大的版本。

二、1M context 是什么：把窗口扩到五倍

1M context 就是把上下文窗口从默认的 200K 扩到约一百万 token。能放进去的材料一下子多了五倍——一整个中型模块的代码、一长串错误日志、几份设计文档加历史讨论，都能同时摊开。

支持 1M 的是较新的几代模型。按官方 context-windows 文档，Opus 4.6 及更新版本和 Sonnet 4.6 在主流平台上都有 1M 窗口；而 Sonnet 4.5 及更早的模型仍是 200K（具体型号以官方当前文档为准）。

但要先记一句：1M context 不是记忆库。它只是「这一次任务的临时工作台变大了」，会话一结束、一清空，里面的东西就没了。真正能跨会话留下来的，是你写进项目文件的规则（比如 CLAUDE.md 项目记忆文件）。别把「窗口大」当成「Claude 会一直记得」。

新手到这里只要能复述一句话就够了：1M 解决的是「一次能看下多少」，不解决「该看什么」。真正决定结果的，永远是你有没有把目标、边界和不相关材料分清楚。

三、1M context 怎么开：四种账号的启用方式

这是搜索量最大的具体问题，先把答案前置：1M 不是默认，默认是 200K。怎么开，取决于你的账号类型。

几个关键点说清楚：

1. Max / Team / Enterprise 订阅：Opus 会自动升到 1M，不用做任何设置。这覆盖 Team Standard 和 Team Premium 两种席位。
2. Pro 订阅，以及任何计划想给 Sonnet 开 1M：需要先开通用量额度（usage credits，一种额外付费的预付额度）才能用。
3. 手动指定：在 model picker 里选 opus[1m]，或直接给模型 ID 加 [1m] 后缀。

# 会话里切换到 1M 窗口
/model opus[1m]
/model sonnet[1m]

# 或给完整模型名加 [1m] 后缀
/model claude-opus-4-8[1m]

也可以用环境变量把默认模型固定成 1M 版本（[1m] 后缀只是个开关标记，告诉 Claude Code 这次用 1M 那一版，不改别的）：

export ANTHROPIC_DEFAULT_OPUS_MODEL='claude-opus-4-8[1m]'

怎么确认开没开：跑 /status 看当前用的是哪个模型，或者打开 /model 选择器看有没有 1M 选项；要是没看到，重启一下会话再看。想反过来彻底关掉 1M，可以设环境变量 CLAUDE_CODE_DISABLE_1M_CONTEXT=1，这会把所有 1M 模型从选择器里移除。

一句话记牢这节：Max/Team/Enterprise 的 Opus 默认就是 1M，Pro 和所有 Sonnet 要手动开用量额度，开没开跑 /status 一看便知。 但别一看到能开就全程挂着——把 1M 当「需要时再切」的能力：日常写代码、改配置用默认 200K，遇到真要跨大量材料的长任务时再 /model opus[1m] 切过去。挂着大窗口不等于干得更好，理由下面讲 context rot 时会更清楚。

四、context rot：为什么大窗口不一定更好

这是整篇最该记住的一节。context rot（上下文衰减）是 Anthropic 官方文档里的正式术语，它的定义是：随着 token 数量增长，模型的准确率和召回率会下降。

官方的意思换个说法：上下文不是越多越好；当 token 数变大，模型的准确率和召回率会退化，这种现象就叫 context rot。所以整理上下文里放了什么，和窗口有多大同样重要。

💡 通俗讲

回到开篇那张工作台：台面换大了，你一兴奋把所有抽屉里的东西全倒上去——结果真正要用的那张图纸，被一堆不相关的旧便签盖住了，反而更难找。窗口越大，越容易这样。

为什么会这样？原因很直观：

• 材料一多，关键信息容易被低相关内容稀释——你最在意的那条约束，淹没在大段无关代码里。
• 前面提过的条件、失败尝试、验收标准，在一个很长的会话里会变得不显眼，模型的注意力分散。
• 新消息和很久以前的内容竞争同一份注意力——四十万 token 之前的东西，可能和你最新这句话抢戏。

🔥 翔宇判断

这就是为什么我说「会管上下文 > 窗口够大」。一个能验证的细节是：Claude 在长上下文检索基准上拿到顶尖成绩，官方明确说这些成绩取决于上下文里放了对的东西，而不只是放得多。所以 1M 是「能承载更多材料」，不是「自动理解得更好」。新手优先要练的不是把窗口塞满，而是精准上下文：只放和当前判断有关的材料，把结论和边界写清楚。很多人以为自己需要 1M，其实只需要把材料的顺序和优先级理一理。

五、Auto Compact：长会话不中断的自动压缩

聊得越久，上下文总会接近上限。Claude Code 处理这件事的机制叫 Auto Compact（自动压缩）——先说结论：它能让长会话不中断地续下去，代价是会丢掉一部分细节。官方说法是：当对话接近上下文上限时，它会自动把较早的历史总结成摘要，再用摘要继续往下做。你可以理解成 Claude 把前半截对话归纳成一页笔记，腾出空间继续干活。

它的好处很明确：长会话不会因为顶到窗口上限而突然中断。但它也有代价——摘要会丢细节。最容易被压没的，恰恰是这几样关键信息：

• 某个方案为什么失败的具体原因；
• 你强调过的文件路径、目录边界；
• 你口头交代的「这个不要动」之类的约束。

触发点是多满才压，不用死记固定百分比，不同版本可能有差异。

⚠️ 常见踩坑

把 Auto Compact 当成自动保险箱，是新手常见的坑。它能让长会话续上，但它不知道你心里最在意哪条约束。比如你说过「这个目录不要动」，如果这句被压缩得太粗，后面就可能变成隐患。重要边界要写进任务说明或项目文件，不能只靠会话历史替你记着。

更稳的做法是：重要阶段结束后自己写一段交接，或者主动用 /compact 并带上保留指令——比如长会话写到一半，与其等它自动压、不如先跑一句 /compact 重点保留报错、文件路径和我说过不要动的目录，把你最在意的东西钉进摘要里。别把关键判断全交给自动压缩。

六、/compact 和 /clear：两个动作怎么选

这两个命令名字像，作用完全不同，是手动管理上下文的两个主力动作。

/compact 还能带指令，告诉 Claude 总结时重点保留什么：

/compact 重点保留代码改动和报错信息

你甚至可以把偏好写进 CLAUDE.md，让每次压缩都照办：

# 压缩指令
压缩时请重点保留测试输出和代码改动

🔥 翔宇判断

一个反直觉但很实用的经验：/clear 该用得比你以为的更勤。切到不相关的活，就果断 /clear 开干净会话——干净会话加一句清楚的提示词，往往比一个反复修正、越拖越乱的超长会话更靠谱。/compact 留给「同一件事必须连贯做下去」的场景。判断标准很简单：换主题就 clear，续主题就 compact。最常见的浪费是干完 A 任务不清场就接着干不相关的 B 任务，A 的残留既费 token 又制造 context rot。

七、什么时候 1M 才真的有用：四类场景

前面一直在劝你别滥用 1M，那它到底什么时候该上？答案是：任务需要连续保留一条很长的判断链时。具体有四类场景。

1. 跨很多文件追一个问题：错误日志、复现步骤、已经试过的方案都不能丢，一旦被压缩掉就得重来。
2. 大项目重构：需要同时看多个模块的约束和依赖关系，普通窗口来回切容易丢线索。
3. 多 Agent 协作 / 长时间任务：会不断累积材料，需要更大的缓冲空间兜底。
4. 审计、合同、长报告：这类任务要随时回到原文定位某一句，大窗口能把相关证据留在同一轮里。

反过来，多数日常修改不需要 1M：改一个小函数、查一个配置、改一段文案，开大窗口意义不大，还更容易钝。判断要不要开 1M，问自己一句：这次任务要不要「一口气把一长串线索连起来推」？要，就开；只是问一两个小问题，默认窗口绰绰有余。

八、Subagents：比 compact 更细的上下文管理工具

如果说 /compact 和 /clear 是手动整理已经堆上来的材料，那 Subagents（子智能体）就是「把脏活外包出去」，从一开始就不让啰嗦内容进主会话。它的关键价值是上下文隔离。

官方文档说得很清楚：每个 Subagent 在自己独立的上下文窗口里工作，干完只把结果摘要返回主会话，不把中间过程带回来。举个例子：你在主会话搭架构，派一个 Subagent 去读 50 个测试文件、找出哪些用了已废弃的接口——它在自己的窗口里读完，回来只说一句「12 个文件用了废弃接口，列表如下」，那 50 个文件的内容压根没进你的主线。

这正好对症 context rot：啰嗦的探索（读大量文件、跑测试、查日志）留在子 agent 那边，主线只拿一份干净的结论。判断什么活该外包很简单——凡是「过程很长、但你只要结论」的活就交出去。想系统学怎么用，看这篇 Subagents 与多 Agent 协作新手指南。同理，用 MCP 工具时工具定义默认延迟加载，不会一上来就占满上下文，也是同一个让上下文保持干净的思路。

九、context awareness：模型自己会看油表了

context awareness（上下文感知）让模型能自己跟踪还剩多少 token 预算——这是 Claude Sonnet 4.6、Sonnet 4.5 和 Haiku 4.5 具备的能力（支持型号以官方当前文档为准），也是长任务体验里新手不用动手就能受益的一项。

官方公开的机制很具体：对话开始时，模型会收到一个总预算标记（比如总量一百万）；之后每次调用工具，它都会收到一条剩余容量更新，类似「已用 35000，剩余 965000」。

💡 通俗讲

以前模型干长活像没有油表的车，凭感觉猜还能跑多远，跑着跑着突然「没油熄火」。现在仪表盘上有油表了，能看着剩余空间安排节奏。

这带来的实际变化是：支持该能力的模型在长任务里会更坚持做到最后，而不是凭感觉猜还剩多少就草草收尾；也更不容易盲目跑一个大查询把上下文一下撑爆。这是个「躺着受益」的改进，但它替代不了你整理上下文——油表能告诉你还剩多少油，开往哪、走哪条路，还得你定。

十、新手最容易踩的 5 个坑

把前面的机制落到反模式上，这五个坑最常见：

1. 开了 1M 就不整理材料：正好反了。窗口越大，越要用短句标清楚哪些是结论、哪些是证据、哪些只是背景。
2. 把 Auto Compact 当保险箱：它能续上会话，但会丢细节。关键边界写进文件，不要只靠会话历史记着。
3. 换任务不 /clear：上一个任务的残留还占着上下文，既费钱又制造 context rot。换主题先清场。
4. 啰嗦操作全堆主会话：读 50 个文件、跑一大堆测试直接在主线干，上下文瞬间被淹。交给 Subagents 隔离。
5. 写一堆判断口号却不落到动作：真正有用的判断要能落地——哪个文件改、哪个命令跑、哪个结果算通过。没有动作的判断只是装饰。

⚠️ 常见踩坑

还有一种很容易误判的情况：以为自己需要 1M，其实只是需要更好的材料顺序。让 Claude 先读错误日志，再读入口文件，再读最近改动，通常比一开始把整个仓库塞进去更好。顺序本身就是上下文的一部分。

十一、进阶路径：跑两周后再往上走

上下文管理不是第一天就要全套上手的东西，按这个节奏走更稳：

• 第 1 天：用默认 200K 跑通一个真实小任务——给 Claude 读 3 到 5 个相关文件、一段错误日志、一条明确验收标准。先不开 1M。
• 第 1 周：开始有意识地用 /clear 切任务、用 /compact 续任务，体会什么时候是窗口不够、什么时候只是任务说明不清。
• 第 2 周起：遇到真正的长任务（跨多文件调试、大重构）再开 1M，并把读日志、跑测试这类活交给 Subagents 隔离。

把长任务分阶段也很有用：第一阶段只定位不改文件，第二阶段只做小范围修改，第三阶段只做验证和复盘。每个阶段结束写一段短交接，说明确认了什么、还没确认什么、下一步从哪开始。这样即使 Auto Compact 触发、或你主动开了新会话，思路也不会断。

十二、自检清单：你把上下文管对了吗

动手前后，拿这张清单对一遍：

• [ ] 我知道自己当前账号默认是 200K 还是已经开了 1M（跑 /status 确认）。
• [ ] 这次任务我列了「必读 / 可选 / 不要参考」三类材料，没把无关的全塞进去。
• [ ] 重要边界（哪个目录不能动、哪些结论不能猜）写进了任务说明或项目文件，不只靠会话历史。
• [ ] 换不相关任务时我用了 /clear，续同一件事时用 /compact。
• [ ] 读大量文件、跑测试这类啰嗦活，我考虑过交给 Subagents 隔离。
• [ ] 长任务我分了阶段，每段结束写了短交接。

如果这几条大多能勾上，说明你已经把上下文当成「会管理的工作资产」，而不是「越塞越多的仓库」。

一句话收官

记住一句就够：先整理，再扩大。上下文窗口越大，越要把任务主线写在最前面。1M 是兜底能力，不是日常目标；真正决定结果的，从来不是窗口多大，而是你有没有把该放进去的材料理清楚。

相关阅读

同系列下一步：

• Claude Code 是什么：新手完整总览
• Claude Code 桌面端、命令行与 IDE 怎么选
• CLAUDE.md 怎么写：项目记忆文件新手指南
• Claude Code MCP 工具新手指南
• Subagents 与多 Agent 协作新手指南

官方参考：

• Claude Code 模型配置文档（含 1M 启用）
• Claude Code 成本与上下文管理文档
• Anthropic 上下文窗口文档（含 context rot 与 context awareness）