答案可以先說清楚：Claude Opus 4.7 的 1M context window 是官方能力，但「1M」不是萬能通行證。
如果整個 repo，加上任務說明、system prompt、對話上下文、工具輸出、錯誤 log、測試結果，以及最後要輸出的報告或 patch 預留空間，全部都還在限制內，那麼一次分析有機會可行。反過來說，如果是大型 monorepo、包含大量 generated files、vendor 依賴、文件、快取或 logs，通常仍然需要篩選、分批讀取，或搭配工具式工作流程。[2][
6]
重點先看：1M context 是上限，不是工作流程
Claude Opus 4.7 官方文件列出 1M token context window，並支援最多 128k output tokens。[2] 這讓它比短上下文模型更適合長文件、長程式碼任務與大範圍 codebase 分析。
但「能否一次讀完整個 repo」不是只看 1M 這個數字，而要同時看三件事：
- 所有輸入都要放得進 context。 不能只算 source files；提示詞、對話歷史、工具結果、錯誤訊息、測試輸出與補充資料都會佔用上下文空間。[
2]
- 要替輸出保留空間。 Opus 4.7 最多支援 128k output tokens；如果你要求完整審計報告、大型修補、逐檔分析或重構計畫，就不該把輸入塞到極限。[
2]
- 要用 Opus 4.7 自己的 tokenizer 重新計算。 Anthropic 指出，Opus 4.7 的新 tokenizer 處理同一文本時，可能使用約 1x 至 1.35x tokens；
/v1/messages/count_tokens對 Opus 4.7 的結果也會不同於 Opus 4.6。[2]
官方資料實際支持哪些說法？
| 問題 | 官方資料支持 | 實務解讀 |
|---|---|---|
| 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、搜尋結果與工具輸出。這些內容加起來，才是模型實際要處理的上下文。
更麻煩的是，很多 repo 裡有大量不該進入 prompt 的內容，例如：
- build artifacts 或編譯產物
- generated files
vendor、node_modules之類的第三方依賴- 巨大的 logs、cache、測試輸出
- 重複文件或過時文件
- 大型二進位或壓縮資料的文字化描述
把這些全部塞進 context，表面上像是「完整」，實際上可能只是把寶貴空間浪費在低價值內容上，還會壓縮真正重要的程式碼、任務指令與輸出空間。
在 Opus 4.7 上，這點尤其要注意，因為 Anthropic 已提醒新 tokenizer 可能讓同一批文本使用比前代更多 tokens，最高約 1.35x。[2]
「保持穩定」應該怎麼理解？
可以樂觀，但不應講成絕對。
Anthropic 的產品頁明確把 Opus 4.7 定位在 complex agentic workflows、long-running work 與 larger codebases 等場景。[6] 官方新聞稿也稱它在處理 complex, long-running tasks 時具備 rigor and consistency。[
8]
這些資料支持一個較穩妥的結論：Anthropic 官方將 Opus 4.7 定位為更適合長上下文、長流程與大型 codebase 任務的模型。
但它們不足以證明「任何超長文件、任何 repo、任何 agent loop 都能一次穩定完成」。如果是安全審計、CI/CD 自動修復、大型重構，或長時間自動化 agent 流程，仍然應該用自己的 repo、測試套件與實際失敗案例驗證結果。[6][
8]
實務建議：想讓它掃完整個 repo，該怎麼做？
1. 先做檔案盤點，不要直接全貼
先列出 repo 的主要目錄、語言、入口點、測試、設定檔與近期改動，再決定哪些檔案真的需要進入上下文。通常應先排除 generated files、build artifacts、vendor 依賴、巨大 logs、cache 與重複文件。
2. 用 Opus 4.7 重新 count tokens
不要拿 Opus 4.6 或其他模型的 token 數直接推算。Anthropic 指出 Opus 4.7 的新 tokenizer 可能讓同一文本使用約 1x 至 1.35x tokens，/v1/messages/count_tokens 的結果也會不同。[2]
3. 不要把 1M context 塞到滿
即使輸入剛好放得進去，也不代表任務會做得好。長 repo 分析通常需要輸出架構摘要、風險列表、修改建議、測試策略，甚至 patch。Opus 4.7 的最大 output tokens 是 128k，因此任務設計時要替輸出留空間。[2]
4. 大型 repo 用分階段流程更可靠
Anthropic 將 Opus 4.7 定位為適合 complex agentic workflows 與 larger codebases 的模型。[6] 對大型 repo 來說，更合理的做法通常是：先讓模型理解架構，再逐步讀取關鍵檔案、搜尋引用、檢查測試與錯誤 log，而不是一開始把所有內容一次塞入。
5. 要求模型交代「看過什麼、沒看什麼」
做 repo 分析時，可以要求輸出包含：
- 已讀檔案與範圍
- 未讀檔案或被排除的目錄
- 主要假設
- 風險與不確定性
- 需要人工確認的部分
- 下一步測試建議
這不能保證答案完全正確，但可以避免把「模型看過一大段上下文」誤解成「模型完整理解整個 codebase」。
最終判斷
Claude Opus 4.7 確實支援 1M token context window，並支援最多 128k output tokens。[2] Anthropic 也將它定位為適合長流程、agentic workflow 與較大型 codebase 的模型。[
6][
8]
所以答案不是單純的「可以」或「不可以」。若整個 repo 連同任務上下文與輸出預留都在限制內，一次處理可以成立；若 repo 太大、雜訊太多，或任務本身需要長篇報告與大量修改，較可靠的方法仍是先篩選、再分批，並用實際測試驗證結果。
