Claude Code + Opus 4.6 的 1M 上下文到底能干什么？5 个真实场景告诉你
用 Claude Code 写代码写到一半，AI 突然”失忆”了——你前面花了 20 分钟解释的架构设计、调试过程、文件依赖关系，全忘了。它开始重复问你同样的问题，甚至改出一堆之前已经修好的 Bug。
如果你有这个经历，说明你撞上了上下文窗口的天花板。
好消息是，这个天花板刚刚被拉高了 5 倍。Anthropic 在 3 月 13 日宣布：Claude Opus 4.6 和 Sonnet 4.6 的 1M（100 万 token）上下文窗口正式 GA，而且不加价。
100 万 token 是什么概念？大约 75 万个英文单词，相当于 4-5 本小说的长度。换成代码，一个 50 万行的项目可以一次性全部塞进去。
这不只是一个数字变大了。它改变了你和 AI 协作的方式。
为什么上下文窗口这么重要？
先说一个概念：上下文窗口就是 AI 的”工作记忆”。
你跟 AI 对话的所有内容——你的提问、它的回答、它读过的文件、执行过的命令、搜索的结果——都占用上下文窗口的空间。窗口满了，就得”压缩”（compaction）：AI 会自动把前面的对话总结一下，扔掉细节，腾出空间。
问题在于，压缩一定会丢信息。 就像你把一本书压缩成摘要，细节没了。你两小时前让它分析的那个 Bug，压缩后可能就剩一句”之前分析了一个 Bug”——具体是什么 Bug、涉及哪些文件、尝试了哪些方案，全没了。
之前 Opus 4.5 的上下文窗口是 200K token。听起来不少，但在 Claude Code 里，一次搜索 Datadog 日志就能烧掉 100K token。两次搜索，窗口就满了，压缩开始，信息丢失，你开始”原地转圈”。
1M 上下文 = 5 倍的工作记忆。 这意味着 AI 可以在一次会话里记住更多东西，做更复杂的任务，不再频繁失忆。
1M 上下文的 5 个真实使用场景
说了这么多理论，到底能用来干什么？下面是 5 个真实场景。
场景一：整个代码库一次性分析
以前你想让 AI 理解一个中大型项目，得一个文件一个文件地喂。它看完 A 文件，等看到 D 文件的时候，A 文件的细节可能已经被压缩掉了。跨文件的依赖关系？基本靠猜。
现在不一样了。一个 50 万行的代码库，打包丢进去，AI 能同时看到所有文件。
一位开发者的真实案例：他把一个遗留系统的全部代码输入 Claude，10 分钟内拿到了完整的架构文档和重构建议。传统方式？手动分析需要数周。
这对遗留系统改造特别有价值。老代码没文档、命名混乱、逻辑缠绕。以前你得一点一点理清楚，现在直接让 AI 通读全局，画出调用关系，标出问题点。
场景二：跨文件 Bug 定位
分布式系统里最头疼的 Bug 是什么？竞态条件。涉及 5 个、8 个甚至更多文件的交互，人脑很难同时 hold 住所有状态。
有开发者遇到一个跨 8 个文件的竞态条件 Bug，团队找了 3 周没找到。他把所有相关文件丢给 Claude Code，模型分析完整调用链后，5 分钟定位到缺少锁保护的关键代码段。
这就是大上下文的威力：AI 能同时看到所有相关代码，而不是分块看、拼凑猜。
场景三：长时间 Agent 任务不中断
Claude Code 的 Agent 模式很强大——它能自己搜代码、读文件、执行命令、跑测试，一步一步解决问题。但每一步都在消耗上下文。
200K 窗口下，一个复杂任务可能只跑了十几步就触发压缩。之前搜索的日志、读过的配置文件、尝试过的修复方案，压缩后都变成模糊的摘要。Agent 开始”转圈”——重复搜索同样的东西，忘记已经试过的方案。
Ramp 的软件工程师 Anton Biryukov 说得很直白：
“Claude Code 搜索 Datadog、Braintrust、数据库和源码可以轻松烧掉 100K+ token。然后压缩开始，细节消失，你在原地打转。有了 1M 上下文，我可以搜索、反复搜索、汇总边缘情况，然后在同一个窗口里提出修复方案。”
1M 上下文让 Agent 能跑 5 倍以上的步骤 才触发压缩。多文件重构、复杂调试、自动化测试，都能一口气跑完。
场景四：大规模文档和合同审查
法律科技公司 Eve 的 ML 工程师 Mauricio Wulfovich 分享了他们的用法：
“Eve 默认使用 1M 上下文，因为原告律师最难的问题就是需要它。无论是交叉引用 400 页的证词记录，还是在整个案件档案中发现关键联系，扩展的上下文窗口让我们的回答质量有了质的提升。”
不只是法律。任何需要处理长文档的场景都受益：
- 合规审计：一次性加载上千页合同，检查条款一致性
- 科研：同时分析数百篇论文、数学公式和模拟代码
- 财务分析：加载完整的财务报表和历史数据，跨年度对比
600 张图片或 PDF 页面的媒体限制（从之前的 100 张提升 6 倍），让多模态工作流也成为可能。
场景五：多 Agent 编排
这是最让我兴奋的场景。
以前 200K 窗口下，主 Agent（编排者）调度几个子 Agent 就耗尽上下文了。子 Agent 的结果汇总回来，主 Agent 已经忘了自己为什么要发起这些子任务。
1M 上下文彻底改变了游戏规则：主 Agent 有足够的空间同时管理多个子 Agent，记住每个子任务的背景、进度和结果。子 Agent 之间的状态交接也不再需要有损压缩。
一位开发者的说法很形象：”1M 上下文对多 Agent 系统是完全不同级别的能力。”
关键数据：它真的能在 1M 长度下保持准确吗？
大上下文如果不准确，就是摆设。那 Opus 4.6 的表现如何？
Anthropic 公布了 MRCR v2（Multi-needle Retrieval with Contextual Reasoning）基准测试结果。这个测试在 100 万 token 文本中藏 8 个关键信息，要求模型全部找到：
| 模型 | 1M token 准确率 |
|---|---|
| Claude Opus 4.6 | 78.3% |
| Gemini 3.1 Pro | ~26% |
| GPT-5.4 | 50% 以下（256K 后急剧下降） |
Opus 4.6 的准确率是前代最佳 Claude 的 4 倍，是 Gemini 的 3 倍。
实际体验也验证了这一点。一位开发者用 Opus 4.6 跑了几次 50 万 token 的 Claude Code 会话，反馈说”表现非常好，不需要比平时更多地重复自己，感觉就像一个正常的（短上下文）会话。”
价格：真的不加钱
这可能是最重要的变化。
以前超过 200K token 的请求会触发”长上下文溢价”——Opus 的输入价格从 $5/MTok 涨到 $10/MTok，直接翻倍。
现在呢？统一价格，全窗口适用。
| 模型 | 输入价格 | 输出价格 |
|---|---|---|
| Opus 4.6 | $5/MTok | $25/MTok |
| Sonnet 4.6 | $3/MTok | $15/MTok |
一个 90 万 token 的请求，跟一个 9K token 的请求，每个 token 的价格一样。
对于 Claude Code 用户更简单：Max、Team、Enterprise 订阅者直接包含 1M 上下文，无需额外付费。在 Claude Code 里选择 Opus 4.6 模型，1M 窗口自动启用。
1 | # 在 Claude Code 中切换到 1M 上下文模型 |
不过要注意：上下文越大，token 消耗越快。 一个 90 万 token 的会话，光输入就要 $4.5。日常使用没问题，但如果放在自动化循环里跑，费用会很快累积。
实用建议：怎么用好 1M 上下文？
给你几个实操建议：
1. 不是所有任务都需要 1M。 简单的代码补全、单文件修改，200K 绰绰有余。把 1M 留给真正需要的场景：大型重构、复杂调试、长文档分析。
2. 善用 CLAUDE.md。 把项目架构、编码规范、技术栈信息写在 CLAUDE.md 里。这些信息会自动加载，不用每次重复说明，节省上下文空间。
3. 注意 token 消耗速度。 Max 订阅用户虽然包含 1M 上下文，但 token 配额是固定的。大窗口意味着消耗更快。关注 /status 里的 token 用量。
4. 如果不需要，可以关掉。 设置环境变量 CLAUDE_CODE_DISABLE_1M_CONTEXT=1 即可禁用 1M 模型，回到 200K 窗口，节省配额。
5. 复杂任务用 Plan 模式。 先让 Claude 分析项目、制定方案（Shift+Tab 进入 Plan 模式），确认后再执行。大上下文 + 规划，效果最好。
写在最后
1M 上下文不是一个营销噱头。它解决的是 AI 辅助编程中最底层的问题——信息丢失。
以前我们总在想办法绕过上下文限制：分块处理、手动总结、反复提醒。这些 workaround 有用，但本质上都是在弥补能力不足。
现在这个限制被大幅放宽了。你可以把整个项目丢给 AI，让它从全局视角理解你的代码。你可以让 Agent 跑几个小时的复杂任务，不用担心它中途失忆。你可以在一个会话里完成过去需要拆成三四个会话才能做完的事情。
这不是说 AI 变得无所不能了。它依然会犯错，依然需要你的引导和审查。但至少，它不会再因为”忘了”而犯错。
你用过 1M 上下文了吗？在什么场景下感受最明显？或者你还在用 200K，觉得够用了？评论区聊聊你的真实体验。