Claude Opus 4.7 的 100 萬 token 上下文視窗，最好把它想成一張很大的工作桌：模型可以同時攤開更多程式碼、文件、工具輸出、測試結果與任務歷史。根據 Claude 的 migration guide，Opus 4.7 在標準 API pricing 下支援 100 萬 token context window，沒有 long-context premium；同時支援 128k max output tokens、prompt caching、Files API、PDF support、vision、tool use 與 memory [16]。
所以真正該問的不是：「100 萬上下文會不會讓每個 prompt 都變好？」而是：「這個任務是否真的有大量彼此相關的脈絡，值得放進同一個工作階段？」
先說結論
如果只能選一種最值得使用 100 萬上下文的場景，答案會是：大型程式碼庫上的軟體工程任務，尤其是多步驟的代理式 coding（agentic coding）。
Anthropic 將 Claude Opus 4.7 定位在 professional software engineering 與 complex agentic workflows [4]。Claude API 文件也列出 production-level code、debugging、在 complex codebases 中進行對話式查詢等用途，並明確提到 100 萬上下文可用於 large documents 與 extensive codebases [
13]。
需要保留一點分寸的是：目前提供的官方資料沒有公布一個「100 萬上下文最強任務排行榜」或單獨 benchmark。因此，將大型 codebase 與 agentic coding 視為最強候選，是依據 Anthropic 官方對模型定位與使用情境的描述所做的審慎判讀 [4][
13]。
為什麼大型 codebase 最吃香？
真實軟體專案裡，一個 bug 或一次重構很少只牽涉單一函式。修一個問題，可能要同時讀多個 module、測試、設定檔、schema、技術文件、log，以及前幾輪修改留下的上下文。
當這些資訊都與任務有關，100 萬 token 的價值就會顯現：模型比較有空間把多個證據片段留在同一個工作階段中，而不是一直靠摘要、截斷或重新查找來拼湊。這也正好對應 Claude 文件中對 complex codebases 與 extensive codebases 的描述 [13]。
對代理式 coding 來說，這個差異更明顯。因為模型不是只回答一個短 prompt，而是可能經歷一連串步驟：讀檔、呼叫工具、接收輸出、修改程式、跑測試、看 log，再回頭修正。Claude 的 context windows 文件說明，在使用 thinking 與 tool use 的設定中，input 與 output tokens 都會影響 context window 限制 [14]。Migration guide 也把 tool use、Files API、prompt caching 與 memory 列在 Opus 4.7 的功能組合中 [
16]。
換句話說：工作階段越長、中間資料越多、且這些資料彼此越相關，100 萬 token 上下文就越有用。
哪些任務最應該優先使用？
| 適合程度 | 任務 | 100 萬上下文為什麼有幫助 |
|---|---|---|
| 很高 | 大型 codebase 的 debug、refactor 或 code review | Claude 文件提到 production-level code、debugging、在 complex codebases 中查詢，以及 100 萬上下文可處理 extensive codebases [ |
| 很高 | 代理式 coding 與多步驟工作流程 | Opus 4.7 被定位於 complex agentic workflows；tool use、Files API、prompt caching 與 memory 讓大型上下文在長工作階段中更有價值 [ |
| 高 | 長文件、PDF 或多個已挑選檔案的分析 | Claude 文件提到 100 萬上下文可用於 large documents；migration guide 也列出 PDF support 與 Files API [ |
| 中高 | RAG 或研究任務，但前提是來源已先篩選 | 100 萬上下文可容納更多已挑選來源；關於 100 萬上下文的分析通常也會把它放在 RAG pipeline 與 long-running agent tasks 的設計脈絡中討論 [ |
| 低 | 短聊天、短文案、只修改一個小檔案 | 當任務本身沒有多少脈絡需要保留，大上下文通常不是關鍵差異；input 與 output tokens 仍然需要在 context window 限制內管理 [ |
幾個最容易誤會的地方
100 萬上下文不等於 100 萬輸出
Migration guide 提到，Opus 4.7 有 100 萬 token context window，但 max output 是 128k tokens [16]。如果你的目標是一次生成超長文件，輸出上限仍然要另外檢查，不能只看上下文視窗大小。
上下文變大，不代表不用管 token
沒有 long-context premium，並不等於 token 預算可以忽略。Anthropic 說明，Opus 4.7 的新 tokenizer 依內容不同，處理同樣文字時可能使用約 1 倍到 1.35 倍於先前模型的 token；count_tokens endpoint 對 Opus 4.7 回傳的 token 數也可能與 Opus 4.6 不同 [1]。
如果你的 workflow 很長，最好重新檢查 token budget，不要假設舊 prompt 在新模型上會有完全相同的上下文成本。
不該把所有資料一股腦塞進 prompt
100 萬 token 讓你能放入更多「相關」資料，但它不會取代篩選檔案、log、文件或檢索結果的步驟。在使用工具的工作流程中，input、output，以及與 thinking／tool use 相關的部分仍會影響 context window [14]。
對 RAG 來說，比較合理的用法通常是：放入更多經過挑選、排序、去重後的來源，而不是把整個未整理的資料庫直接塞進同一個 prompt [3]。
快速判斷：什麼時候值得開 100 萬上下文？
可以用下面幾個問題做判斷。只要至少符合一項，就值得考慮 Claude Opus 4.7 的 100 萬上下文：
- 你需要模型閱讀、比對或修改大型 codebase 的多個部分，尤其是變更牽涉多個 module、測試或技術文件 [
13]。
- Agent 需要跑很多步，呼叫工具、讀檔、處理測試或 log 結果，再反覆回到程式碼中修正 [
14][
16]。
- 任務需要在同一個工作階段中分析多份長文件、PDF 或已挑選檔案 [
13][
16]。
- 如果把任務歷史摘要化，會遺失重要細節，因此你希望在模型決策前保留更多原始脈絡。
反過來說，如果只是問一個短問題、寫一小段內容，或修改單一小檔案，100 萬上下文通常不會是選擇 Opus 4.7 的主要理由。
最務實的看法是：把 100 萬 token context window 當成大型 codebase、長文件與長時間 agent 工作流程的工作空間，而不是每個 prompt 都該開到最大的預設模式。
