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

Claude Opus 4.7 的 1M context window，最好唔好理解成「模型一定更聰明」。比較準確講，它是一張更大的工作枱：你可以把更多源碼、技術文件、測試結果、工具輸出同任務歷史放在同一個 session 入面，讓模型在判斷前看到更多相關材料。

Anthropic 的 migration guide 指出，Opus 4.7 在 standard API pricing 下支援 1M token context window，沒有 long-context premium；同時有 128k max output tokens、prompt caching、Files API、PDF support、vision、tool use 同 memory 。所以真正問題不是「1M context 會唔會令所有 prompt 都更好」，而是：你的任務是否真的有大量相關上下文，值得一次過保留給模型？

一句講晒：最值錢場景係大型 codebase

如果要揀一個 1M context 最有機會發揮價值的場景，就是大型 codebase 上的 software engineering，特別是 agent 式、多步驟的 coding workflow。

Anthropic 將 Claude Opus 4.7 定位給 professional software engineering 同 complex agentic workflows 。Claude API docs 亦提到它可用於 production-level code、debugging，以及在 complex codebases 入面做 conversational querying；同時列明 1M context 適合處理 large documents 同 extensive codebases 。

不過要講清楚：目前提供的文件沒有一個獨立 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 有幫助
非常高	在大型 codebase 上 debug、refactor 或 code review	Claude docs 提到 production-level code、debugging、在 complex codebases 入面查詢，以及 1M context 可處理 extensive codebases 。
非常高	Agentic coding、多步驟 workflow	Opus 4.7 被定位給 complex agentic workflows；tool use、Files API、prompt caching 同 memory 令長 session 更有用 。
高	分析長文件、PDF 或多個已選定 file	Claude docs 指 1M context 可處理 large documents；migration guide 亦列出 PDF support 同 Files API 。
中至高	RAG 或 research，但要先篩選資料來源	1M context 可以容納更多已挑選的來源；關於 1M context 的分析亦常把它放在 RAG pipeline 同 long-running agent task 設計入面討論 。
低	短 chat、短 copywriting、只改一個小 file	如果任務本身沒有太多上下文要保留，大 context window 通常不是主要差異；input/output tokens 仍然要在 context limit 之內管理 。

幾個最容易誤會的位

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 的預設必開功能。