Claude Opus 4.7 的 100 萬 token 上下文：最適合大型程式碼庫與代理式 coding

需要保留一點分寸的是：目前提供的官方資料沒有公布一個「100 萬上下文最強任務排行榜」或單獨 benchmark。因此，將大型 codebase 與 agentic coding 視為最強候選，是依據 Anthropic 官方對模型定位與使用情境的描述所做的審慎判讀 。

為什麼大型 codebase 最吃香？

真實軟體專案裡，一個 bug 或一次重構很少只牽涉單一函式。修一個問題，可能要同時讀多個 module、測試、設定檔、schema、技術文件、log，以及前幾輪修改留下的上下文。

當這些資訊都與任務有關，100 萬 token 的價值就會顯現：模型比較有空間把多個證據片段留在同一個工作階段中，而不是一直靠摘要、截斷或重新查找來拼湊。這也正好對應 Claude 文件中對 complex codebases 與 extensive codebases 的描述 。

對代理式 coding 來說，這個差異更明顯。因為模型不是只回答一個短 prompt，而是可能經歷一連串步驟：讀檔、呼叫工具、接收輸出、修改程式、跑測試、看 log，再回頭修正。Claude 的 context windows 文件說明，在使用 thinking 與 tool use 的設定中，input 與 output tokens 都會影響 context window 限制 。Migration guide 也把 tool use、Files API、prompt caching 與 memory 列在 Opus 4.7 的功能組合中 。

換句話說：工作階段越長、中間資料越多、且這些資料彼此越相關，100 萬 token 上下文就越有用。

哪些任務最應該優先使用？

幾個最容易誤會的地方

100 萬上下文不等於 100 萬輸出

Migration guide 提到，Opus 4.7 有 100 萬 token context window，但 max output 是 128k tokens 。如果你的目標是一次生成超長文件，輸出上限仍然要另外檢查，不能只看上下文視窗大小。

上下文變大，不代表不用管 token

沒有 long-context premium，並不等於 token 預算可以忽略。Anthropic 說明，Opus 4.7 的新 tokenizer 依內容不同，處理同樣文字時可能使用約 1 倍到 1.35 倍於先前模型的 token；count_tokens endpoint 對 Opus 4.7 回傳的 token 數也可能與 Opus 4.6 不同 。

如果你的 workflow 很長，最好重新檢查 token budget，不要假設舊 prompt 在新模型上會有完全相同的上下文成本。

不該把所有資料一股腦塞進 prompt

100 萬 token 讓你能放入更多「相關」資料，但它不會取代篩選檔案、log、文件或檢索結果的步驟。在使用工具的工作流程中，input、output，以及與 thinking／tool use 相關的部分仍會影響 context window 。

對 RAG 來說，比較合理的用法通常是：放入更多經過挑選、排序、去重後的來源，而不是把整個未整理的資料庫直接塞進同一個 prompt 。

快速判斷：什麼時候值得開 100 萬上下文？

可以用下面幾個問題做判斷。只要至少符合一項，就值得考慮 Claude Opus 4.7 的 100 萬上下文：

1. 你需要模型閱讀、比對或修改大型 codebase 的多個部分，尤其是變更牽涉多個 module、測試或技術文件 。
2. Agent 需要跑很多步，呼叫工具、讀檔、處理測試或 log 結果，再反覆回到程式碼中修正 。
3. 任務需要在同一個工作階段中分析多份長文件、PDF 或已挑選檔案 。
4. 如果把任務歷史摘要化，會遺失重要細節，因此你希望在模型決策前保留更多原始脈絡。

反過來說，如果只是問一個短問題、寫一小段內容，或修改單一小檔案，100 萬上下文通常不會是選擇 Opus 4.7 的主要理由。

最務實的看法是：把 100 萬 token context window 當成大型 codebase、長文件與長時間 agent 工作流程的工作空間，而不是每個 prompt 都該開到最大的預設模式。