Claude Opus 4.7 的 1M context window 幾時最值得用？

不過要講清楚：目前提供的文件沒有一個獨立 benchmark 直接話「1M context 的第一名用途就是 X」。把「大型 codebase + agentic coding」視為最強候選，是根據 Anthropic 官方對 Opus 4.7 的定位同 use case 描述作出的審慎解讀 。

點解大型 codebase 特別食到 1M context？

真實軟件項目入面，一個 bug 或一次 refactor 很少只牽涉一個 function。你可能要同時睇多個 module、test、config、schema、技術文件、log，甚至之前幾輪修改留下的結果。當這些材料彼此相關，1M context 就可以讓模型在同一個 session 入面保留更多「證據」，這正好對應 Claude docs 提到的 complex codebases 與 extensive codebases 。

去到 agentic coding，優勢會更明顯。這類 workflow 不是問一句、答一句，而是可能包括：讀 file、call tool、收 tool output、改 code、跑 test、讀 log，然後再改。Claude 的 context windows 文件指出，在使用 thinking 和 tool use 的配置時，input tokens、output tokens，以及相關 token 都會影響 context window 限制 。Migration guide 亦列出 Opus 4.7 支援 tool use、Files API、prompt caching 同 memory 。簡單講：session 越長、中間資料越多而且越相關，1M context 越有意思。

邊類任務最應該優先用 1M context？

幾個最容易誤會的位

1M context 唔等於 1M output

Migration guide 寫明，Opus 4.7 有 1M token context window，但 max output 是 128k tokens 。如果你的目標是一次過生成一份超長文件，仍然要另外檢查 output limit。

Context 大，不代表可以唔理 token budget

沒有 long-context premium，不等於 token 成本同 token 計算可以忽略。Anthropic 指出，Opus 4.7 的新 tokenizer 在處理文字時，可能比之前模型使用約 1x 至 1.35x token，視乎內容而定；count_tokens endpoint 對 Opus 4.7 亦可能回傳與 Opus 4.6 不同的 token 數 。如果你有長 workflow，最好重新計 token budget，而不是假設舊 prompt 的成本同上下文佔用完全一樣。

唔好將所有資料一股腦塞入 prompt

1M context 的意思是可以放更多相關資料，不是叫你把整個資料倉、所有 log、所有文件都丟進去。尤其是用 tool 的 workflow，input、output，以及 thinking/tool use 相關部分都會影響 context window 。在 RAG 場景，更合理的做法通常是放入更多「已篩選、已排序、真正相關」的來源，而不是把未整理資料一次過塞給模型 。

快速決定：幾時值得用 Opus 4.7 的 1M context？

如果以下情況中有一項成立，就值得考慮：

1. 你需要模型讀、比較或修改大型 codebase 的多個部分，尤其是改動牽涉多個 module、test 或技術文件 。
2. Agent 要跑多輪步驟：call tool、讀 file、處理 test/log 結果，再回頭修改 code 。
3. 任務需要在同一個 session 分析多份長文件、PDF 或已選定的 file 。
4. 你擔心把任務歷史壓縮成 summary 會丟失重要細節，所以想在模型決策前保留更多原始上下文。

相反，如果只是問一條短問題、寫一段簡單文案，或者改一個細 file，1M context 通常不是選 Opus 4.7 的主要理由。最合理的用法，是把它當成一張夠大的工作枱：攤開大型 codebase、長文件、tool output 同長線 agent workflow，而不是把它當成所有 prompt 的預設必開功能。