摘要：这次升级，将上下文从原本的 20 万 Token 一口气提升 5 倍——百万上下文究竟有多大？相当于一次性放进整套《哈利·波特》全集。
深夜更新！Claude Sonnet 4 已经支持百万级上下文窗口了！
这次升级，将上下文从原本的 20 万 Token 一口气提升 5 倍——百万上下文究竟有多大？相当于一次性放进整套《哈利·波特》全集。
换算到开发场景，就是可以一次处理 超过 75,000 行代码的完整代码库，或几十篇研究论文。
这次的更新毫不意外地被技术社区热议。
目前，这一功能已在 Anthropic API 和 Amazon Bedrock 上已经可用。更令人关注的是，部分 Claude Code Max 用户已经收到了邮件通知，预计新的上下文窗口上限正在灰度推广中。
对比来看，OpenAI 最新发布的 GPT-5 API 支持 40 万 Token 上下文，总体体验虽有争议，但其编程能力升级与超低价格，被不少人视作打向 Anthropic 腹地的一记重拳。
有网友调侃，正是 GPT-5 的出现逼出了这次更新，否则 Claude 可能还不会这么快动手。
随着 Sonnet 4 升级完成，它正式跻身 百万 Token 窗口俱乐部——这个阵营中，除了它，还包括 Gemini 2.5 Pro / Flash、Qwen-Plus、Qwen-Flash 等在编程领域表现突出的选手。长上下文之战，已经开打。
为什么 Claude 要用“加长上下文”来迎战？原因很直接——长上下文对编码体验的提升是立竿见影的。它让开发者能在一次会话中处理更复杂、更庞大的任务，而百万级已是当前的关键门槛。
此前，谷歌 DeepMind 长上下文预训练联合负责人Nikolay Savinov在播客中提醒：
在当前百万 token 上下文远还没有达到完美之前，盲目追求更大规模的长上下文意义不大。
接下来，我们就来拆解 Sonnet 4 的百万上下文细节，与 Gemini 的长文本能力做对比，并分享如何在实际编码中更高效地用好这一能力。
根据 Claude 技术报告，百万级上下文主要解锁了三大核心场景：
大规模代码分析 一次性加载完整代码库，包括源码文件、测试和文档。Claude 能理解整体项目架构，识别跨文件依赖，并在改进建议中考虑到整个系统的设计。文档综合分析 可处理法律合同、研究论文、技术规范等大规模文档集，在保持全局上下文的同时，分析数百份文档间的关联与逻辑。具备上下文记忆的智能体 构建能在数百次工具调用和多步骤工作流中保持连贯性的智能体，可一次性加载完整 API 文档、工具定义和交互历史，不丢失上下文。然而，这个“长度飞跃”带来了价格的同步攀升。对于超过 20 万 Token 的请求，输入费用翻倍至 $6 / 百万 Token，输出费用更是达到 $22.5 / 百万 Token。
不少网友表示，本来看到百万上下文很激动，但一看价格立刻冷静下来：
“这一下操作得花我们 51 美元。”
“AI幻觉一次，我一个月工资没了。”
至于是否值得为如此高昂的上下文窗口买单，社区争议依然很大——即使给了更大的窗口，也未必真的能发挥出真正的价值。
尽管百万级上下文听起来令人兴奋，但开发者在实际应用中或许会感到“货不对板”——随着会话长度和上下文规模的增长，模型常常难以保持连贯性。
有工程师指出，在自己的实际工作体验中：
看到一个新模型比上一个好一点并不有趣，价格才是王炸。除非能有评估数据证明 Sonnet 在百万级上下文下依然能稳定保持上下文质量，否则“加长”未必意味着“更好”。
在 Reddit 上，也有不少用户表达了类似观点：
有报告称，当上下文长度超过 30K Token 时，部分 LLM 的表现就会急剧下降，甚至直接“崩溃”。
这种现象反映出一个核心矛盾：上下文窗口的物理长度并不等于模型的有效注意力范围。在真实的长文本或大代码库场景中，超过一定规模后，模型很可能无法在全局范围内平均分配注意力，从而导致性能下降。
模型生成的代码可能会变得杂乱、逻辑跳脱，或者开始遗漏关键信息。
因此，Claude Sonnet 4 的百万 Token 升级，虽然在技术规格上进入了“超长赛道”，但真实能力仍需要实测验证。
外媒 Every 的 CEO Dan Shipper 提前获得了 Sonnet 4 百万上下文的测试权限，并用自家内容管理系统（CMS）的代码库进行了实测。
测试方法很直接——他们将完整的 CMS 代码库（约 25 万 Token 的 Ruby on Rails 代码）配上 70 万 Token 的填充代码，总计凑满 100 万 Token，然后抛出 5 个问题：
订阅系统如何运作？数据库中有哪些关系？用户取消订阅时会运行哪些后台任务？CMS 使用什么支付处理器？找到 FooBar 类并解释其作用（陷阱题——实际并不存在）平均得分（0-100）与耗时：
Claude Sonnet 4：74.6 分 / 36 秒Gemini 2.5 Pro：89.7 分 / 39 秒Gemini 2.5 Flash：91.7 分 / 39 秒从结果来看，Claude 在速度和稳定性（少幻觉）方面有优势，但在代码分析的细节完整度上不如 Gemini。尤其是遇到复杂逻辑时，Gemini 给出的答案覆盖面更广，得分也明显更高。
价格对比（输入 Token 每百万计）
Claude（> 200K Token）：$6Gemini Pro：$2.50Gemini Flash：$0.30综合性能与价格来看，Claude Sonnet 4 的绝对表现不差，但性价比相较 Gemini 仍稍显逊色。
不过，这个实测也在一定程度上回击了上文的质疑：Claude Sonnet 4 和 Gemini 2.5 系列（Pro、Flash）在技术上都能稳定加载并处理百万 Token 级别的输入，并且在完整运行过程中没有因为上下文过大而直接崩溃。
遗憾的是，测试结果里并没有展示具体题目的完整应答，而且这些题目与真实生产环境仍有一定距离。
在百万级上下文的探索上，Gemini 是较早投入并积累经验的大模型。
在找资料的过程中，小编发现了大神 Logan 与 DeepMind 上下文预训练负责人 Nikolay Savinov 的一次深度对谈，主题正是——“深入解析长上下文”。
对话从最硬核的技术视角，解答了开发者在真实使用中最关心的问题。
比如，在实际交互中，问题到底应该放在上下文的前面，还是后面？
播客地址：
https://www.youtube.com/watch?v=NHMJ9mqKeMQ
答案是：放在后面。
Savinov 解释说，如果想利用缓存降低成本，就必须把问题放在末尾；如果放在开头，每次请求都会导致缓存失效，模型必须从头处理，既慢又贵。
除了这个“位置问题”，Savinov 还给出了四条核心建议：
1.充分利用上下文缓存（Context Caching）
首次加载长上下文成本高，但在相同上下文基础上进行的后续提问可直接命中缓存，处理速度更快、成本可降至原来的约四分之一。如果知识需要更新，应将新增内容追加到末尾，底层会匹配最长公共前缀，只处理新增部分。2.结合 RAG（检索增强生成）
当上下文达到数十亿 token 时，RAG 是唯一可行方案。即使规模较小，在需要跨多个关键信息检索的任务中，RAG 也能提升准确率。3.精选上下文内容
不要将长上下文当作“数据垃圾桶”。无关或干扰信息会与目标信息争夺模型的注意力，尤其在多关键信息检索任务中，反而降低性能。4.消除“权重内”与“上下文内”记忆冲突
模型会同时依赖权重中的固有知识与上下文中的新信息，两者可能产生矛盾。解决方法是在提示中明确信息来源，例如加上“基于以上提供的信息……”，让模型优先依赖上下文知识。最后，Savinov 也谈到了长上下文的发展趋势：
在百万级 Token 模型的质量尚未完善前，盲目追求更大规模的上下文意义有限。随着成本下降，千万级 Token 上下文将很快成为标准配置，对编码等场景将是革命性突破。如今，模型的注意力瓶颈已经追不上上下文长度的扩张速度。
因此，即便上下文窗口不断变大，“上下文工程”在短期内依然是必不可少的技能。
展望未来，如果 Savinov 预测的千万级 Token 真成了标配，长上下文或将引发开发模式的质变：
模型可以真正“端到端”地接管整个代码库，从持续开发到重构、调试全包揽，甚至变成团队的“常驻虚拟工程师”。
不过，长上下文只是 AI 编码能力跃升的一个维度。
模型架构、推理链设计、工具集成、上下文管理等，都会共同决定最终体验。
问题来了——
你愿意重金尝试， Claude 的超长上下文吗？
来源：51CTO一点号
