突襲GPT-5！Claude甩出百萬上下文王炸！開發者吵翻：超出LLM極限，貴還沒價值？ 原創
編輯 | 伊風
出品 | 51CTO技術棧（微信號：blog51cto）
深夜更新！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 Sonnet 4 百萬上下文詳解：更長了但也更貴了
根據 Claude 技術報告，百萬級上下文主要解鎖了三大核心場景：
- 大規模代碼分析 一次性加載完整代碼庫，包括源碼文件、測試和文檔。Claude 能理解整體項目架構，識別跨文件依賴，并在改進建議中考慮到整個系統的設計。
- 文檔綜合分析 可處理法律合同、研究論文、技術規范等大規模文檔集，在保持全局上下文的同時，分析數百份文檔間的關聯與邏輯。
- 具備上下文記憶的智能體 構建能在數百次工具調用和多步驟工作流中保持連貫性的智能體，可一次性加載完整 API 文檔、工具定義和交互歷史，不丟失上下文。
然而，這個“長度飛躍”帶來了價格的同步攀升。對于超過 20 萬 Token 的請求，輸入費用翻倍至 $6 / 百萬 Token，輸出費用更是達到 $22.5 / 百萬 Token。
圖片
不少網友表示，本來看到百萬上下文很激動，但一看價格立刻冷靜下來：
“這一下操作得花我們 51 美元。”
“AI幻覺一次，我一個月工資沒了。”
圖片
圖片
至于是否值得為如此高昂的上下文窗口買單，社區爭議依然很大——即使給了更大的窗口，也未必真的能發揮出真正的價值。
二、爭議：百萬token已經超出模型注意力極限
盡管百萬級上下文聽起來令人興奮，但開發者在實際應用中或許會感到“貨不對板”——隨著會話長度和上下文規模的增長，模型常常難以保持連貫性。
有工程師指出，在自己的實際工作體驗中：
看到一個新模型比上一個好一點并不有趣，價格才是王炸。除非能有評估數據證明 Sonnet 在百萬級上下文下依然能穩定保持上下文質量，否則“加長”未必意味著“更好”。
圖片
在 Reddit 上，也有不少用戶表達了類似觀點：
有報告稱，當上下文長度超過 30K Token 時，部分 LLM 的表現就會急劇下降，甚至直接“崩潰”。
圖片
這種現象反映出一個核心矛盾：上下文窗口的物理長度并不等于模型的有效注意力范圍。在真實的長文本或大代碼庫場景中，超過一定規模后，模型很可能無法在全局范圍內平均分配注意力，從而導致性能下降。
模型生成的代碼可能會變得雜亂、邏輯跳脫，或者開始遺漏關鍵信息。
因此，Claude Sonnet 4 的百萬 Token 升級，雖然在技術規格上進入了“超長賽道”，但真實能力仍需要實測驗證。
三、Sonnet 4 實測：處理百萬代碼庫，與Gemini 2.5 Pro孰強孰弱？
外媒 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）：$6
- Gemini Pro：$2.50
- Gemini 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 的超長上下文嗎？
參考鏈接：
1.https://news.ycombinator.com/item?id=44878147
2.https://www.anthropic.com/news/1m-context
3.https://every.to/vibe-check/vibe-check-claude-sonnet-4-now-has-a-1-million-token-context-window
本文轉載自??51CTO技術棧??，作者：伊風
