上下文管理

大多數模型使用標準的 200K 上下文視窗：

• Claude 4.5 Sonnet - 在複雜任務中取得平衡
• Claude 4.5 Haiku - 快速且高效
• GPT-5 - 在推理方面表現出色（Beta）
• GPT-5-Codex - 針對程式設計最佳化（Beta）

容量：

• 約 200,000 tokens 的總記憶體容量
• 足以應對大多數開發任務和中型專案

包含內容：

• 對話中的所有訊息
• 載入上下文的檔案內容
• 工具輸出與回應
• 系統提示詞與指令
• MCP 伺服器定義

效能：

• 接近限制時會明顯下降
• 留意上下文過載的徵兆（回應變慢、輸出準確度降低）
• 更頻繁地重置上下文以獲得最佳效能

Claude Sonnet 4.5 在明確選取或輸入超過 200K tokens 時，提供延伸上下文（1M tokens）。

容量：

• 1,000,000 tokens 的總記憶體
• 是標準模型的 5 倍

優點：

• 非常適合載入整個大型程式碼庫而無需分塊
• 消除大型專案的大部分上下文管理顧慮
• 可在達到上下文限制前工作更久
• 需要更少的工作階段重置

何時使用：

• 擁有 1000+ 檔案的大型程式碼庫
• 跨整個專案的複雜多檔案重構
• 跨越多個相關任務的長時間開發工作階段
• 當你想盡量減少上下文管理開銷時

徵兆：

• 回應較不準確或不完整
• 遺漏對話中較早的重要細節
• 難以在長時間工作階段中保持一致性
• 對近期變更或上下文感到困惑

具體範例：

• 建議你在工作階段早期已經否決的解決方案
• 忽略你在 20 則訊息前建立的程式設計慣例
• 產生與對話早期變更相衝突的程式碼
• 提出與你先前討論的專案架構不符的實作方式

主要訊號： Verdent 的回應變得較不準確或不一致

徵兆：

• 回應時間明顯變慢
• 回應開始前的處理延遲變長
• 訊息之間的延遲增加

具體範例：

• 通常需要 5-10 秒的回應現在需要 30+ 秒
• 你傳送訊息後，輸入指示器出現前有明顯延遲
• 串流回應的開始比平常慢得多
• 工具執行（檔案讀取、搜尋）明顯需要更長時間

主要訊號： 回應所需時間比平常顯著更長

徵兆：

• 要求釐清已提供的資訊
• 忘記先前建立的模式或慣例
• 無法參照先前討論過的檔案或程式碼
• 對專案結構提出重複的問題

具體範例：

• 當你在 30 則訊息前已指定 React 時，仍詢問「你使用什麼框架？」
• 要求你已經提供多次的檔案路徑 @-mentioned
• 不記得你在工作階段開始時建立的命名慣例
• 重新解釋你已經附帶理由否決的概念或方法

主要訊號： Verdent 詢問已經討論過的事情

徵兆：

• 接近 200K token 限制的最後五分之一（已使用約 160K+ tokens）
• 長對話包含大量檔案讀取與工具輸出
• 啟用多個帶有龐大工具定義的 MCP 伺服器
• 重複將大型檔案載入上下文

具體範例：

• 工作階段已運行 2+ 小時，包含 100+ 則訊息
• 你在整個對話中已載入 20+ 檔案，附帶 @-mentions
• 上下文中有多個大型檔案（每個 >1000 行）
• 你啟用了 5+ MCP 伺服器，帶有大量工具定義
• 對話包含許多 grep/搜尋結果與檔案讀取

主要訊號： 非常長的工作階段，伴隨大量檔案/工具使用

• 回應時間明顯變慢
• 回應較不準確或不一致
• Verdent 忘記較早的上下文或模式
• 接近上下文視窗限制（留意下降徵兆）

行動： 當品質下降時開始新的工作階段

• 在不相關的功能或模組之間切換
• 完成一個待辦事項並進入下一個
• 在記憶體密集的任務之後（大型重構、架構工作）
• 從研究階段進入實作階段

行動： 為新的重大任務開啟新工作階段

• 將完成的功能提交到版本控制之後
• 在開發工作流程的邏輯檢查點之間
• 在測試-驗證-提交循環之後

行動： 提交 → 測試 → 新工作階段

• 在開始重大新功能之前
• 當對話歷史變得非常長時
• 在完成多檔案變更之後
• 在不同類型的工作之間（除錯 → 功能開發）

行動： 在上下文下降前主動開始新工作階段

更小、更聚焦的檔案：

• 許多小檔案比少數大檔案更有效率地消耗上下文
• 更容易只載入相關模組
• 對上下文中的內容有更細緻的控制
• 減少載入整個大型檔案的需求

清晰的目錄結構：

• 邏輯化的組織有助於 Verdent 定位相關檔案
• 以功能為基礎或以模組為基礎的組織改善上下文定位
• 減少載入無關程式碼的需求

Documentation in AGENTS.md:

• 專案文件取代載入大量範例檔案的需求
• 架構模式描述一次，重複參照
• 程式設計標準集中記錄
• 減少探索性檔案讀取造成的上下文開銷

優點：

• 在不載入整個程式碼庫的情況下處理獨立模組
• 清晰的界限讓工作階段更聚焦
• 沿著模組界限分塊工作變得自然

問題：

• 單體式檔案迫使載入整個大型上下文
• 結構不清晰需要載入大量檔案才能理解架構
• 同一檔案中混合的關注點在無關程式碼上浪費上下文

影響：

• 頻繁出現上下文限制問題
• 在無關程式碼上浪費 tokens
• 難以將工作隔離至特定模組
• 更頻繁地需要重置工作階段

常見反面模式：

• 帶有多個關注點的單一 5000+ 行檔案
• 根目錄有 100+ 檔案的扁平目錄結構
• 功能/模組之間沒有清晰的分離
• 缺乏集中式文件

重構方法：

• 將大型檔案拆分為更小、更聚焦的模組
• 依功能或領域組織（而非依檔案類型）
• 建立清晰的目錄階層
• 將共用程式碼提取至獨立模組

文件：

• 建立帶有架構模式的 AGENTS.md
• 集中記錄程式設計標準
• 每個模組維護 README 檔案
• 持續記錄設計決策

上下文影響： 對於標準的 200K token 上下文，組織良好的工作區決定了你是頻繁還是很少達到限制。對於 1M token 上下文，組織的影響較小，但仍能提升效率。

留意效能徵兆：

• 在整個工作階段中監控回應品質與速度
• 注意回應何時變慢或變得較不準確
• 手動追蹤對話長度與檔案數量
• 主動開始新的工作階段

要監控什麼：

• 回應的準確度與一致性
• 首次回應的時間（輸入指示器延遲）
• 整體回應完成時間
• 對較早對話細節的記憶

子代理管理：

• 在不需要時停用未使用的自訂子代理
• 每個啟用的子代理都會在系統開銷中加入定義
• 只保留實際使用中的子代理啟用
• 在特定任務需要時重新啟用

行動門檻： 當你注意到 2-3 下降訊號時，就該開始新的工作階段了。

分塊方法：

• 將大型任務拆分為較小的部分
• 在聚焦的工作階段中完成相關工作
• 避免在長對話中混合不同的任務類型
• 在記憶體密集的工作中避免使用上下文視窗的最後五分之一

工作階段管理：

• 在重大任務之間開始新的工作階段
• 提交後清除上下文：測試 → 驗證 → 提交 → 新工作階段
• 使用待辦事項進行多步驟規劃
• 在獨立、聚焦的工作階段中逐一完成待辦事項

最佳實務模式：

1. 在 Plan Mode 中規劃任務
2. 在新的工作階段中執行聚焦的實作
3. 測試並驗證變更
4. 提交到版本控制
5. 為下一個任務開始新的工作階段

任務隔離： 將除錯與功能開發分開，將研究與實作分開。

策略性納入：

• 僅在必要時使用 @-mentions 明確納入檔案
• 善用 AGENTS.md 文件，而非載入大量檔案
• 對於大型專案，一次處理一個模組
• 將大型檔案拆分為更小、更聚焦的元件

檔案選擇原則：

• 只納入需要修改或直接參照的檔案
• 優先使用文件而非載入範例檔案
• 在不再需要時從上下文中移除檔案
• 即時載入檔案，而非預先載入

大型檔案處理：

• 考慮拆分超過 500 行的檔案
• 將工具與輔助程式提取至獨立檔案
• 使用清晰的模組界限
• 在 AGENTS.md 中記錄檔案關係

最佳化工作流程：

監控效能 → 辨識工作階段膨脹 → 停用未使用的子代理 → 主動開始新工作階段 → 專注於任務品質

日常實務：

• 為每個重大功能以新的上下文開始
• 頻繁提交並在提交之間重置
• 讓工作階段聚焦於單一目標
• 在自然的中斷點檢視上下文使用情況

For Extended Context (1M tokens): 有了 Claude Sonnet 4.5 更大的上下文視窗，最佳化變得不那麼關鍵——專注於任務品質而非積極的上下文管理。然而，良好的實務仍能提升效率與組織性。