編輯 | 伊風(fēng)
出品 | 51CTO技術(shù)棧（微信號：blog51cto）
深夜更新！Claude Sonnet 4 已經(jīng)支持百萬級上下文窗口了！
這次升級，將上下文從原本的 20 萬 Token 一口氣提升 5 倍——百萬上下文究竟有多大？相當(dāng)于一次性放進整套《哈利·波特》全集。
換算到開發(fā)場景，就是可以一次處理 超過 75,000 行代碼的完整代碼庫，或幾十篇研究論文。
這次的更新毫不意外地被技術(shù)社區(qū)熱議。
圖片
目前，這一功能已在 Anthropic API 和 Amazon Bedrock 上已經(jīng)可用。更令人關(guān)注的是，部分 Claude Code Max 用戶已經(jīng)收到了郵件通知，預(yù)計新的上下文窗口上限正在灰度推廣中。
圖片
對比來看，OpenAI 最新發(fā)布的 GPT-5 API 支持 40 萬 Token 上下文，總體體驗雖有爭議，但其編程能力升級與超低價格，被不少人視作打向 Anthropic 腹地的一記重拳。
有網(wǎng)友調(diào)侃，正是 GPT-5 的出現(xiàn)逼出了這次更新，否則 Claude 可能還不會這么快動手。
圖片
隨著 Sonnet 4 升級完成，它正式躋身 百萬 Token 窗口俱樂部——這個陣營中，除了它，還包括 Gemini 2.5 Pro / Flash、Qwen-Plus、Qwen-Flash 等在編程領(lǐng)域表現(xiàn)突出的選手。長上下文之戰(zhàn)，已經(jīng)開打。
為什么 Claude 要用“加長上下文”來迎戰(zhàn)？原因很直接——長上下文對編碼體驗的提升是立竿見影的。它讓開發(fā)者能在一次會話中處理更復(fù)雜、更龐大的任務(wù)，而百萬級已是當(dāng)前的關(guān)鍵門檻。
此前，谷歌 DeepMind 長上下文預(yù)訓(xùn)練聯(lián)合負責(zé)人Nikolay Savinov在播客中提醒：
在當(dāng)前百萬 token 上下文遠還沒有達到完美之前，盲目追求更大規(guī)模的長上下文意義不大。
接下來，我們就來拆解 Sonnet 4 的百萬上下文細節(jié)，與 Gemini 的長文本能力做對比，并分享如何在實際編碼中更高效地用好這一能力。
一、Claude Sonnet 4 百萬上下文詳解：更長了但也更貴了
根據(jù) Claude 技術(shù)報告，百萬級上下文主要解鎖了三大核心場景：
- 大規(guī)模代碼分析 一次性加載完整代碼庫，包括源碼文件、測試和文檔。Claude 能理解整體項目架構(gòu)，識別跨文件依賴，并在改進建議中考慮到整個系統(tǒng)的設(shè)計。
- 文檔綜合分析 可處理法律合同、研究論文、技術(shù)規(guī)范等大規(guī)模文檔集，在保持全局上下文的同時，分析數(shù)百份文檔間的關(guān)聯(lián)與邏輯。
- 具備上下文記憶的智能體 構(gòu)建能在數(shù)百次工具調(diào)用和多步驟工作流中保持連貫性的智能體，可一次性加載完整 API 文檔、工具定義和交互歷史，不丟失上下文。
然而，這個“長度飛躍”帶來了價格的同步攀升。對于超過 20 萬 Token 的請求，輸入費用翻倍至 $6 / 百萬 Token，輸出費用更是達到 $22.5 / 百萬 Token。
圖片
不少網(wǎng)友表示，本來看到百萬上下文很激動，但一看價格立刻冷靜下來：
“這一下操作得花我們 51 美元。”
“AI幻覺一次，我一個月工資沒了。”
圖片
圖片
至于是否值得為如此高昂的上下文窗口買單，社區(qū)爭議依然很大——即使給了更大的窗口，也未必真的能發(fā)揮出真正的價值。
二、爭議：百萬token已經(jīng)超出模型注意力極限
盡管百萬級上下文聽起來令人興奮，但開發(fā)者在實際應(yīng)用中或許會感到“貨不對板”——隨著會話長度和上下文規(guī)模的增長，模型常常難以保持連貫性。
有工程師指出，在自己的實際工作體驗中：
看到一個新模型比上一個好一點并不有趣，價格才是王炸。除非能有評估數(shù)據(jù)證明 Sonnet 在百萬級上下文下依然能穩(wěn)定保持上下文質(zhì)量，否則“加長”未必意味著“更好”。
圖片
在 Reddit 上，也有不少用戶表達了類似觀點：
有報告稱，當(dāng)上下文長度超過 30K Token 時，部分 LLM 的表現(xiàn)就會急劇下降，甚至直接“崩潰”。
圖片
這種現(xiàn)象反映出一個核心矛盾：上下文窗口的物理長度并不等于模型的有效注意力范圍。在真實的長文本或大代碼庫場景中，超過一定規(guī)模后，模型很可能無法在全局范圍內(nèi)平均分配注意力，從而導(dǎo)致性能下降。
模型生成的代碼可能會變得雜亂、邏輯跳脫，或者開始遺漏關(guān)鍵信息。
因此，Claude Sonnet 4 的百萬 Token 升級，雖然在技術(shù)規(guī)格上進入了“超長賽道”，但真實能力仍需要實測驗證。
三、Sonnet 4 實測：處理百萬代碼庫，與Gemini 2.5 Pro孰強孰弱？
外媒 Every 的 CEO Dan Shipper 提前獲得了 Sonnet 4 百萬上下文的測試權(quán)限，并用自家內(nèi)容管理系統(tǒng)（CMS）的代碼庫進行了實測。
測試方法很直接——他們將完整的 CMS 代碼庫（約 25 萬 Token 的 Ruby on Rails 代碼）配上 70 萬 Token 的填充代碼，總計湊滿 100 萬 Token，然后拋出 5 個問題：
- 訂閱系統(tǒng)如何運作？
- 數(shù)據(jù)庫中有哪些關(guān)系？
- 用戶取消訂閱時會運行哪些后臺任務(wù)？
- CMS 使用什么支付處理器？
- 找到 FooBar 類并解釋其作用（陷阱題——實際并不存在）
平均得分（0-100）與耗時：
- Claude Sonnet 4：74.6 分 / 36 秒
- Gemini 2.5 Pro：89.7 分 / 39 秒
- Gemini 2.5 Flash：91.7 分 / 39 秒
從結(jié)果來看，Claude 在速度和穩(wěn)定性（少幻覺）方面有優(yōu)勢，但在代碼分析的細節(jié)完整度上不如 Gemini。尤其是遇到復(fù)雜邏輯時，Gemini 給出的答案覆蓋面更廣，得分也明顯更高。
價格對比（輸入 Token 每百萬計）
- Claude（> 200K Token）：$6
- Gemini Pro：$2.50
- Gemini Flash：$0.30
綜合性能與價格來看，Claude Sonnet 4 的絕對表現(xiàn)不差，但性價比相較 Gemini 仍稍顯遜色。
不過，這個實測也在一定程度上回擊了上文的質(zhì)疑：Claude Sonnet 4 和 Gemini 2.5 系列（Pro、Flash）在技術(shù)上都能穩(wěn)定加載并處理百萬 Token 級別的輸入，并且在完整運行過程中沒有因為上下文過大而直接崩潰。
遺憾的是，測試結(jié)果里并沒有展示具體題目的完整應(yīng)答，而且這些題目與真實生產(chǎn)環(huán)境仍有一定距離。
四、開發(fā)者如何用好長上下文能力？
在百萬級上下文的探索上，Gemini 是較早投入并積累經(jīng)驗的大模型。
在找資料的過程中，小編發(fā)現(xiàn)了大神 Logan 與 DeepMind 上下文預(yù)訓(xùn)練負責(zé)人 Nikolay Savinov 的一次深度對談，主題正是——“深入解析長上下文”。
對話從最硬核的技術(shù)視角，解答了開發(fā)者在真實使用中最關(guān)心的問題。
比如，在實際交互中，問題到底應(yīng)該放在上下文的前面，還是后面？
圖片
播客地址：
https://www.youtube.com/watch?v=NHMJ9mqKeMQ
答案是：放在后面。
Savinov 解釋說，如果想利用緩存降低成本，就必須把問題放在末尾；如果放在開頭，每次請求都會導(dǎo)致緩存失效，模型必須從頭處理，既慢又貴。
除了這個“位置問題”，Savinov 還給出了四條核心建議：
1.充分利用上下文緩存（Context Caching）
- 首次加載長上下文成本高，但在相同上下文基礎(chǔ)上進行的后續(xù)提問可直接命中緩存，處理速度更快、成本可降至原來的約四分之一。
- 如果知識需要更新，應(yīng)將新增內(nèi)容追加到末尾，底層會匹配最長公共前綴，只處理新增部分。
2.結(jié)合 RAG（檢索增強生成）
- 當(dāng)上下文達到數(shù)十億 token 時，RAG 是唯一可行方案。
- 即使規(guī)模較小，在需要跨多個關(guān)鍵信息檢索的任務(wù)中，RAG 也能提升準(zhǔn)確率。
3.精選上下文內(nèi)容
- 不要將長上下文當(dāng)作“數(shù)據(jù)垃圾桶”。無關(guān)或干擾信息會與目標(biāo)信息爭奪模型的注意力，尤其在多關(guān)鍵信息檢索任務(wù)中，反而降低性能。
4.消除“權(quán)重內(nèi)”與“上下文內(nèi)”記憶沖突
- 模型會同時依賴權(quán)重中的固有知識與上下文中的新信息，兩者可能產(chǎn)生矛盾。解決方法是在提示中明確信息來源，例如加上“基于以上提供的信息……”，讓模型優(yōu)先依賴上下文知識。
最后，Savinov 也談到了長上下文的發(fā)展趨勢：
- 在百萬級 Token 模型的質(zhì)量尚未完善前，盲目追求更大規(guī)模的上下文意義有限。
- 隨著成本下降，千萬級 Token 上下文將很快成為標(biāo)準(zhǔn)配置，對編碼等場景將是革命性突破。
五、寫在最后
如今，模型的注意力瓶頸已經(jīng)追不上上下文長度的擴張速度。
因此，即便上下文窗口不斷變大，“上下文工程”在短期內(nèi)依然是必不可少的技能。
展望未來，如果 Savinov 預(yù)測的千萬級 Token 真成了標(biāo)配，長上下文或?qū)⒁l(fā)開發(fā)模式的質(zhì)變：
模型可以真正“端到端”地接管整個代碼庫，從持續(xù)開發(fā)到重構(gòu)、調(diào)試全包攬，甚至變成團隊的“常駐虛擬工程師”。
不過，長上下文只是 AI 編碼能力躍升的一個維度。
模型架構(gòu)、推理鏈設(shè)計、工具集成、上下文管理等，都會共同決定最終體驗。
問題來了——
你愿意重金嘗試， 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
