先講結論：可以用，但要用得醒。 100 萬 token context window 嘅真正好處，係可以將以前要拆開十幾輪處理嘅材料，放入同一次分析：例如一份長合約、一批研究文件，或者一個已經整理過嘅程式碼庫。公開報道指，GPT-4.1 系列三個模型最高可處理 100 萬 context tokens；TestingCatalog 亦提到，大型文件同大型 codebase 係呢類能力嘅應用方向。[5][
6]
不過，100 萬 token 唔等於「有問必準」。技術分析指 GPT-4.1 針對長上下文處理、理解同資訊查找有相關訓練；但亦有分析提醒，1M context 雖然令人印象深刻，仍然未必足夠覆蓋所有真實工作流。[1][
3] 所以實務上最重要唔係問「塞唔塞得晒」，而係問：「資料乾唔乾淨？任務夠唔夠窄？答案可唔可以返去原文核對？」
三種常見材料：邊啲適合一次過讀？
| 場景 | 一次放入 1M context 嘅可行性 | 最適合做咩 | 咩情況唔好成包照入 |
|---|---|---|---|
| 單一完整合約 | 通常係合理候選 | 條款摘要、付款責任、終止權、責任限制、版本差異 | 附件太多、OCR 掃描質素差、需要正式法律意見 |
| 一批研究資料 | 好多時可行 | 跨文件比較、共同結論、矛盾點、證據矩陣 | 來源質素參差、需要逐句追溯、資料不停更新 |
| 整個 repo | 要睇大小同清理程度 | 架構導覽、bug 定位、API 行為追蹤、重構建議 | 大型 monorepo、依賴目錄、generated files、二進位檔或測試資料太多 |
呢張表嘅重點係：1M context 令「一次睇到全局」更現實，但唔代表「原封不動成個 ZIP 掟入去」就係最佳做法。尤其係 repo，公開資料確實將大型 codebase 列為長上下文用途，但大型 codebase 唔等於任何未整理嘅專案都適合一次過塞入同一個提示。[6]
合約：可以一次讀，但要問成審閱任務
單一完整合約通常幾適合長上下文，因為合約本身有章節、定義、條款編號同附件結構；公開資料亦將大型文件列為 1M context 可支援嘅方向。[6]
但最大風險唔係模型「睇唔到」，而係佢輸出一段好順口、但你核對唔到嘅摘要。唔好只問：呢份合約有咩問題？可以改成：
請按條款編號整理付款義務、終止權、責任限制、保密義務同違約後果。每一點都要附原文片段，並標示邊啲地方需要法律專業確認。
咁樣做，模型會先回到條款同原文，而唔係一開始就代你下法律結論。對法務、採購或者商務談判嚟講，長上下文應該係初步整理同審閱工具，唔係最後法律意見。
研究資料：最有價值係跨文件對照
研究資料通常唔係差一篇摘要，而係差一個整合視角：邊啲結論一致？邊啲假設唔同？有冇數據互相矛盾？每份研究有咩限制？1M context 嘅優勢，就係可以喺同一次任務入面比較多份文件，而唔使逐篇摘要完再人手拼返埋一齊。
適合嘅任務包括：
- 將多份報告整理成同一張比較表。
- 找出所有文件共同支持嘅結論。
- 標示互相衝突嘅定義、假設或者結果。
- 抽取每份研究嘅方法、樣本、限制同未回答問題。
- 產生下一輪研究問題或者訪談大綱。
呢類任務最好要求模型先做「證據矩陣」：每個結論旁邊列明來源文件、段落位置同原文摘錄。長上下文令模型更易同時參考多份材料，但外部分析仍提醒，1M context 唔等於可以完全取代檢索、分段處理同人工查核。[3]
Repo：唔好成個 ZIP 直入，先清倉再分析
程式碼庫係 1M context 最吸引人嘅場景之一。TestingCatalog 將大型 codebase 同大型文件並列為 1M context 嘅應用方向；技術分析亦提到 GPT-4.1 針對長上下文入面嘅理解同資訊查找有訓練。[6][
1]
但 repo 最大問題係雜訊多。模型真正需要嘅，通常唔係所有檔案，而係同任務有關嘅架構、入口點、設定、核心模組同錯誤線索。直接上傳全個專案，好容易將寶貴 context 浪費喺無關內容。
通常應該先排除或者延後加入：
node_modules/、vendor/呢類第三方依賴目錄- 大型 generated files，除非問題正正同生成結果有關
- build artifacts、cache 同暫存輸出
- 二進位檔、圖片、模型權重
- 大量 fixture、snapshot 或測試資料
- 同任務無關嘅備份檔、舊輸出同臨時檔
比較穩陣嘅做法係：先畀目錄樹、README、架構文件同主要設定檔；再加入同任務相關嘅核心程式碼；最後補上錯誤訊息、重現步驟、測試失敗紀錄或者目標行為。咁樣比「全 repo 一次過丟入去」更容易令模型建立正確脈絡。
三個最易中招嘅誤會
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. 長上下文唔等於完美搜尋
將材料放入 context，只代表模型有機會參考，唔代表佢一定穩定搵到每個關鍵片段。針對 GPT-4.1 1M context 嘅批判文章，就形容呢項能力雖然 impressive，但仍然不足以解決所有真實使用場景。[3]
建議工作流：先清資料，再要求證據
如果你要用 1M context 處理合約、研究資料或者 repo，可以照呢個順序做：
- 先估 token。 唔好只睇頁數、檔案數或者 MB；唔同格式、語言同程式碼，token 化結果可以差好遠。
- 先清資料。 刪走重複內容、無關附件、生成檔、依賴目錄、掃描雜訊同舊輸出。
- 保留結構。 文件要留標題、頁碼、段落同條款編號；repo 要留路徑、檔名同目錄樹。
- 先抽證據。 要求模型先列條款、段落、檔案路徑或者程式碼片段，再要求佢摘要、比較或者判斷。
- 將問題問窄。 唔好問「全部睇完有咩問題」；改問「搵付款條款衝突」、「比較 8 份研究嘅結論差異」或者「定位呢個錯誤可能牽涉邊幾個模組」。
- 高風險結果要覆核。 合約、財務、醫療、資安同 production code 變更，都唔應該只靠一次長上下文輸出拍板。
幾時應該改用分段或者檢索？
如果資料會不停更新、需要逐句可追溯引用、要做跨版本比對，或者 repo 大到包含大量無關模組，長上下文未必係唯一或者最佳方案。更實際嘅做法，係將 1M context 當成「整體理解層」，再配合檢索、分段摘要、測試紀錄同人工 review。呢個取態亦符合現有分析對 1M context 嘅提醒：能力好強，但仲未係所有真實工作流嘅完整解法。[3]
