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

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 。

所以真正該問的不是：「100 萬上下文會不會讓每個 prompt 都變好？」而是：「這個任務是否真的有大量彼此相關的脈絡，值得放進同一個工作階段？」

先說結論

如果只能選一種最值得使用 100 萬上下文的場景，答案會是：大型程式碼庫上的軟體工程任務，尤其是多步驟的代理式 coding（agentic coding）。

Anthropic 將 Claude Opus 4.7 定位在 professional software engineering 與 complex agentic workflows 。Claude API 文件也列出 production-level code、debugging、在 complex codebases 中進行對話式查詢等用途，並明確提到 100 萬上下文可用於 large documents 與 extensive codebases 。

需要保留一點分寸的是：目前提供的官方資料沒有公布一個「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 萬上下文為什麼有幫助
很高	大型 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 。如果你的目標是一次生成超長文件，輸出上限仍然要另外檢查，不能只看上下文視窗大小。

上下文變大，不代表不用管 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 都該開到最大的預設模式。