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 [16]。所以真正問題不是「1M context 會唔會令所有 prompt 都更好」，而是：你的任務是否真的有大量相關上下文，值得一次過保留給模型？
一句講晒：最值錢場景係大型 codebase
如果要揀一個 1M context 最有機會發揮價值的場景，就是大型 codebase 上的 software engineering，特別是 agent 式、多步驟的 coding workflow。
Anthropic 將 Claude Opus 4.7 定位給 professional software engineering 同 complex agentic workflows [4]。Claude API docs 亦提到它可用於 production-level code、debugging，以及在 complex codebases 入面做 conversational querying；同時列明 1M context 適合處理 large documents 同 extensive codebases [
13]。
不過要講清楚：目前提供的文件沒有一個獨立 benchmark 直接話「1M context 的第一名用途就是 X」。把「大型 codebase + agentic coding」視為最強候選，是根據 Anthropic 官方對 Opus 4.7 的定位同 use case 描述作出的審慎解讀 [4][
13]。
點解大型 codebase 特別食到 1M context？
真實軟件項目入面，一個 bug 或一次 refactor 很少只牽涉一個 function。你可能要同時睇多個 module、test、config、schema、技術文件、log，甚至之前幾輪修改留下的結果。當這些材料彼此相關，1M context 就可以讓模型在同一個 session 入面保留更多「證據」，這正好對應 Claude docs 提到的 complex codebases 與 extensive codebases [13]。
去到 agentic coding，優勢會更明顯。這類 workflow 不是問一句、答一句，而是可能包括：讀 file、call tool、收 tool output、改 code、跑 test、讀 log，然後再改。Claude 的 context windows 文件指出，在使用 thinking 和 tool use 的配置時，input tokens、output tokens，以及相關 token 都會影響 context window 限制 [14]。Migration guide 亦列出 Opus 4.7 支援 tool use、Files API、prompt caching 同 memory [
16]。簡單講：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 [16]。如果你的目標是一次過生成一份超長文件，仍然要另外檢查 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 數 [1]。如果你有長 workflow，最好重新計 token budget，而不是假設舊 prompt 的成本同上下文佔用完全一樣。
唔好將所有資料一股腦塞入 prompt
1M context 的意思是可以放更多相關資料，不是叫你把整個資料倉、所有 log、所有文件都丟進去。尤其是用 tool 的 workflow，input、output，以及 thinking/tool use 相關部分都會影響 context window [14]。在 RAG 場景，更合理的做法通常是放入更多「已篩選、已排序、真正相關」的來源，而不是把未整理資料一次過塞給模型 [
3]。
快速決定：幾時值得用 Opus 4.7 的 1M context？
如果以下情況中有一項成立，就值得考慮：
- 你需要模型讀、比較或修改大型 codebase 的多個部分，尤其是改動牽涉多個 module、test 或技術文件 [
13]。
- Agent 要跑多輪步驟：call tool、讀 file、處理 test/log 結果，再回頭修改 code [
14][
16]。
- 任務需要在同一個 session 分析多份長文件、PDF 或已選定的 file [
13][
16]。
- 你擔心把任務歷史壓縮成 summary 會丟失重要細節，所以想在模型決策前保留更多原始上下文。
相反，如果只是問一條短問題、寫一段簡單文案，或者改一個細 file，1M context 通常不是選 Opus 4.7 的主要理由。最合理的用法，是把它當成一張夠大的工作枱：攤開大型 codebase、長文件、tool output 同長線 agent workflow，而不是把它當成所有 prompt 的預設必開功能。
