100 萬 token context window 的真正價值，是把原本必須切成多輪的材料，放進同一次分析：一份長合約、一組研究文件，或一個整理過的程式碼庫。公開報導稱，GPT-4.1 家族的三個模型最高可處理 100 萬 context tokens；TestingCatalog 也把大型文件與大型 codebase 列為這類能力的應用方向。[5][
6]
但這是容量突破，不是可靠度保證。技術分析提到 GPT-4.1 針對長上下文處理與資訊查找進行訓練；同時，也有分析認為 1M context 對真實工作流仍可能不足。[1][
3] 實務上，最好的問題不是「塞不塞得下」，而是「資料是否乾淨、任務是否明確、輸出是否能回到原文驗證」。
快速判斷：三種材料能不能一次讀完？
| 場景 | 一次放進 1M context 的可行性 | 最適合的任務 | 什麼情況不建議直接全丟 |
|---|---|---|---|
| 完整單一合約 | 通常是合理候選 | 條款摘要、風險條款、付款與終止義務、版本差異 | 附件龐大、OCR 品質差、需要正式法律意見 |
| 一包研究資料 | 常常可行 | 跨文件比較、共同結論、矛盾點、證據矩陣 | 來源品質不一、需要逐句追溯、資料持續更新 |
| 整個 repo | 視大小與清理程度而定 | 架構導覽、bug 定位、API 行為追蹤、重構建議 | 大型 monorepo、依賴目錄、generated files、二進位資產或測試資料過多 |
這張表的核心意思是：1M context 讓「一次看見整體」更可行，但不代表「原封不動整包上傳」就是最好的做法。尤其是 repo，公開資料確實把大型 codebase 列為長上下文的應用方向，但大型 codebase 不等於任何未整理的專案都適合直接塞進同一個提示。[6]
合約：可以一次讀，但要問成審閱任務
完整單一合約通常是 100 萬 token context window 的合理場景，因為合約本質上是有章節、條款與定義的長文件；公開資料也把大型文件列為 1M context 可支援的方向。[6]
真正的風險不是模型讀不到，而是輸出變成一段漂亮但不可查核的摘要。不要只問「這份合約有什麼問題」。更好的方式，是把任務限制在定位、整理、引用與標示風險：
請依條款編號整理付款義務、終止權、責任限制、保密義務與違約效果。每一點都要附上原文片段，並標示需要法律專業確認的地方。
這種提示讓模型先回到條款，而不是直接下結論。對法務、採購或商務談判來說，長上下文應該是初步審閱與整理工具，不是最後的法律判斷。
研究資料：最適合做跨文件對照
研究資料的價值通常不在單篇摘要，而在跨文件整理：哪些結論一致、哪些假設不同、哪裡有數據矛盾、每份研究的限制是什麼。1M context 的優勢，就是讓模型在同一次任務中比較多份文件，而不是把每篇研究分開摘要後再人工拼接。
適合的任務包括：
- 把多份報告整理成同一張比較表。
- 找出所有文件共同支持的結論。
- 標示互相衝突的定義、假設或結果。
- 抽取每份研究的方法、樣本、限制與未回答問題。
- 產生下一輪研究問題或訪談大綱。
研究資料特別適合先要求「證據矩陣」：每個結論旁邊列出來源文件、段落位置與原文摘錄。長上下文讓模型更容易同時參考多份材料，但外部分析仍提醒，1M context 並不等於能取代檢索、分段處理與人工查核。[3]
Repo：不要整包 ZIP，先整理再讓模型讀
程式碼庫是 1M context 最吸引人的場景之一。TestingCatalog 把大型 codebase 與大型文件並列為 1M context 的應用方向；技術分析也提到 GPT-4.1 針對長上下文中的理解與資訊查找進行訓練。[6][
1]
但 repo 的問題是雜訊密度高。模型真正需要的通常不是所有檔案，而是和任務相關的架構、入口點、設定、核心模組與錯誤線索。直接把整包 repo 上傳，常會把上下文空間浪費在無關內容上。
通常應先排除或延後加入：
node_modules/、vendor/等第三方依賴目錄- 大型 generated files，除非問題正是生成結果
- build artifacts 與暫存輸出
- 二進位檔、圖片、模型權重
- 大量 fixture、snapshot 或測試資料
- 與任務無關的歷史輸出、備份檔與臨時檔
比較穩的輸入順序是：先給目錄樹、README、架構文件與主要設定檔；再加入與任務相關的核心程式碼；最後補上錯誤訊息、重現步驟、測試失敗紀錄或目標行為。這樣比整包丟入更容易讓模型建立正確的程式脈絡。
三個常見誤會
1. 1M context 不是「所有資料都該全丟」
100 萬 token 的上限讓大型文件與 codebase 任務更可行，但它不會自動幫你篩掉雜訊。[6] 如果資料裡有大量重複、生成內容、依賴、掃描錯字或與任務無關的檔案，模型仍可能把注意力花在低價值材料上。
2. 模型上限不一定等於平台上限
「模型可支援 1M context」不代表每個 API、雲端部署或產品包裝都能在同一條件下使用完整長度。Microsoft Q&A 上有使用者回報，在 Azure OpenAI 使用 gpt-4.1 時，低於 1M tokens 仍遇到 context window exceeded；這比較適合作為部署差異的警訊，而不是所有環境的通用結論。[4]
3. 長上下文不等於完美檢索
把材料放進上下文，只代表模型有機會參考它，不代表模型一定會穩定找到每個關鍵片段。針對 GPT-4.1 1M context 的批判文章，就把這項能力描述為令人印象深刻、但仍不足以覆蓋所有真實工作場景。[3]
建議工作流：先清資料，再要求證據
如果你要把合約、研究資料或 repo 放進長上下文，可以用這個順序處理：
- 先估算 token。 不要只看頁數、檔案數或 MB 大小；不同格式、語言與程式碼的 token 化結果會差很多。
- 先清資料。 刪掉重複內容、無關附件、生成檔、依賴目錄、掃描雜訊與歷史輸出。
- 保留結構。 文件要保留標題、頁碼、段落與條款編號；repo 要保留路徑、檔名與目錄樹。
- 要求先抽證據。 讓模型先列出條款、段落、檔案路徑或程式碼片段，再要求它下結論。
- 把任務問窄。 不要問「全部看完有什麼問題」；改問「找付款條款衝突」、「比較 8 份研究的結論差異」或「定位這個錯誤可能牽涉的模組」。
- 高風險結果分段驗證。 合約、財務、醫療、資安與 production code 變更，都不應只依賴一次長上下文輸出。
什麼時候該改用分段或檢索？
如果任務需要反覆更新資料、逐句可追溯引用、跨版本比對，或 repo 大到包含大量無關模組，長上下文不一定是唯一或最佳方法。這時可以把 1M context 當成「整體理解層」，再搭配檢索、分段摘要、測試紀錄或人工 review。這也符合現有分析對 1M context 的提醒：能力很強，但還不是所有真實工作流的完整解法。[3]
