Claude Opus 4.7 1M context：一次讀完整個 repo 的真相

Claude Opus 4.7 的 1M context window 是真實的官方能力，但它不等於「任何 repo 都可以原封不動塞入 prompt」。更準確的答案是：如果整個 repo 連同任務提示、對話上下文、工具結果和輸出預留都在限制內，一次分析有機會可行；如果是大型 monorepo、包含大量 generated files、vendor 依賴、文件或 logs，就仍然需要篩選、分批或配合工具流程。

先下結論：可以，但不是無條件

Claude Opus 4.7 的官方文件列出 1M token context window，並支援最多 128k output tokens。 這令它比傳統短上下文模型更適合長文件、長程式碼任務和大範圍 repo 分析。

但「一次讀完整個 repo」要同時滿足三個條件：

1. 全部輸入都要放得入 1M context。 不能只計 source files；任務提示、system prompt、對話歷史、工具輸出、錯誤 log、測試結果和後續補充都會消耗上下文空間。
2. 要為輸出留空間。 Opus 4.7 最多可輸出 128k tokens；如果你要求完整審計報告、大型 patch、重構計劃或逐檔分析，就不能把輸入塞到極限。
3. 要用 Opus 4.7 自己的 tokenizer 重算。 Anthropic 說 Opus 4.7 的新 tokenizer 處理同一文本時，可能使用約 1x 至 1.35x tokens；/v1/messages/count_tokens 對 Opus 4.7 的結果也會不同於 Opus 4.6。

官方資料實際支持甚麼？

可核查問題	官方資料支持	實務解讀
Context window 有幾大？	Opus 4.7 支援 1M token context window。	超長文件和大型上下文更可行，但仍有硬上限。
最多可輸出幾多？	Opus 4.7 支援最多 128k output tokens。	長報告、長 patch 和批量分析要預留輸出空間。
Token 計法有無變？	新 tokenizer 可能令同一文本使用約 1x 至 1.35x tokens，token counting 結果會與 Opus 4.6 不同。	不應沿用舊模型 token count，也不應只靠字數估算。
是否適合 repo 工作？	Anthropic 產品頁將 Opus 4.7 定位於 complex agentic workflows、long-running work，並稱它可在 larger codebases 中可靠運作。	支持「更適合大型程式碼任務」的判斷，但不是無條件保證。
長任務是否穩定？	Anthropic 新聞稿稱 Opus 4.7 可處理 complex, long-running tasks with rigor and consistency。	官方說法偏正面；仍應用自己的 repo、測試和失敗案例驗證。

為甚麼 1M context 不等於「全 repo 一次過」？

Repo 通常不是一份乾淨的長文件。一次真正有用的 codebase 分析，往往還要包括 README、設定檔、測試、依賴清單、CI 錯誤、stack trace、搜尋結果和工具輸出。這些內容加起來，才是模型實際要處理的上下文。

所以，1M token 應理解為「可以容納非常大的工作集」，而不是「任何 repo 都可以無篩選完整貼入」。如果 repo 本身有大量 generated files、vendor 目錄、編譯產物、巨大 logs 或重複文件，將它們全部放入 prompt 往往會浪費上下文，甚至壓縮真正重要的程式碼與輸出空間。

這點在 Opus 4.7 上尤其要留意，因為 Anthropic 已提醒新 tokenizer 可能讓同一批文本使用比前代更多 tokens，最高約 1.35x。

「保持穩定」應該怎樣理解？

可以樂觀，但不應講成絕對。

Anthropic 的產品頁明確把 Opus 4.7 放在 complex agentic workflows、long-running work 和 larger codebases 的場景中。 官方新聞稿亦稱它處理 complex, long-running tasks 時具備 rigor and consistency。

不過，這些資料主要支持一個較保守的結論：Anthropic 官方定位 Opus 4.7 更適合長上下文、長流程和大型 codebase 任務。 它們不足以證明「任何超長文件、任何 repo、任何 agent loop 都可以一次過穩定完成」。

對生產級用途，例如安全審計、CI/CD 自動修復、大型重構或長時間 agent 流程，仍應以自己的 repo、測試套件和真實失敗案例做驗證。

實務流程：想掃全 repo，應該點做？

1. 先建立檔案清單，而不是直接全貼

先列出 repo 中的主要目錄、語言、入口點、測試、設定檔和近期改動，再決定哪些檔案真的需要進入上下文。通常應先排除 build artifacts、generated files、vendor 依賴、巨大 logs、快取和重複文件。

2. 用 Opus 4.7 的 token counting 重新估算

不要用 Opus 4.6 或其他模型的 token 數直接推算。Anthropic 指出 Opus 4.7 的新 tokenizer 可能讓同一文本使用約 1x 至 1.35x tokens，/v1/messages/count_tokens 的結果也會不同。

3. 不要把 1M context 塞到盡

即使輸入剛好放得入，也不代表任務會理想完成。長 repo 分析通常需要模型輸出覆蓋範圍、風險列表、修改建議、測試策略或 patch；Opus 4.7 的最大 output tokens 是 128k，任務設計時要為輸出留空間。

4. 大 repo 用分階段或工具流程更穩陣

Anthropic 將 Opus 4.7 定位為適合 complex agentic workflows 和 larger codebases 的模型。 對大型 repo 而言，更合理的做法通常是先讓模型理解架構，再逐步讀取關鍵檔案、搜尋引用、檢查測試與錯誤 log，而不是一開始把所有內容一次塞入。

5. 要求模型明確交代覆蓋範圍

做 repo 分析時，可以要求輸出包括：已讀檔案、未讀檔案、主要假設、風險、需要人手確認的部分，以及下一步測試。這不能保證答案正確，但可以避免把「模型看過部分上下文」誤解成「模型完整理解整個 codebase」。

最終判斷

Claude Opus 4.7 確實支援 1M token context window 和最多 128k output tokens。 Anthropic 也將它定位為適合長流程、agentic workflow 和較大 codebase 的模型。

但「一次讀完整個 repo」不是單看 1M 這個數字就能回答。若整個 repo 加上任務上下文和輸出預留仍在限制內，一次處理可以成立；若 repo 太大、雜訊太多，或任務需要長報告與大量修改，較可靠的方法仍是先篩選、再分批、並用實際測試驗證結果。