--- title: "上下文管理" description: "有效管理上下文以獲得更好的結果" --- --- 有效的上下文管理可確保 Verdent 在正確的時間擁有正確的資訊，同時避免因上下文過載而導致效能下降。 ### 你將學到什麼 - 了解上下文視窗及其限制 - 策略性地選擇檔案以獲得最佳上下文 - 辨識並回應上下文過載 - 何時重置上下文以提升效能 - 工作區組織如何影響上下文 --- ## 了解上下文視窗 Verdent for VS Code 的上下文視窗大小取決於所使用的模型。 大多數模型使用標準的 `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+` 檔案的大型程式碼庫 - 跨整個專案的複雜多檔案重構 - 跨越多個相關任務的長時間開發工作階段 - 當你想盡量減少上下文管理開銷時 --- ## 策略性檔案選擇 策略性地選擇檔案，以最佳化上下文使用並避免達到限制。 從較少的檔案開始，僅在需要時加入更多檔案，Verdent 隨時可以在對話過程中讀取額外檔案。 ### 使用 @-Mentions 進行明確納入 ``` @filename.js ``` Verdent 會自動載入相關檔案，但 `@-mentions` 可確保精確的上下文。要有所取捨——只納入與目前任務直接相關的檔案。 ### 監控上下文使用情況 - 隨著工作階段變長，留意效能下降 - 注意對話長度與檔案數量 - 在可能時從上下文中移除不必要的檔案 ### 避免上下文過載 - 將大型任務拆分為較小的部分，每個任務使用較少的檔案 - 只專注於相關檔案——不要一次載入整個程式碼庫 - 使用 MCP 伺服器管理來停用未使用的整合 ### 最佳實務 - 只納入需要修改或參照的檔案 - 參照現有的模式，而不是載入範例檔案 - 對於大型程式碼庫，一次處理一個模組 - 使用專案文件（`AGENTS.md`）而非載入大量檔案 - 在記憶體密集的任務中避免使用上下文視窗的最後五分之一 ### 對於延伸上下文 (1M tokens) 檔案選擇變得不那麼關鍵——你通常可以載入整個專案儲存庫而不會達到限制。 --- ## 辨識上下文過載 **徵兆：** - 回應較不準確或不完整 - 遺漏對話中較早的重要細節 - 難以在長時間工作階段中保持一致性 - 對近期變更或上下文感到困惑 **具體範例：** - 建議你在工作階段早期已經否決的解決方案 - 忽略你在 `20` 則訊息前建立的程式設計慣例 - 產生與對話早期變更相衝突的程式碼 - 提出與你先前討論的專案架構不符的實作方式 **主要訊號：** Verdent 的回應變得較不準確或不一致 **徵兆：** - 回應時間明顯變慢 - 回應開始前的處理延遲變長 - 訊息之間的延遲增加 **具體範例：** - 通常需要 `5-10` 秒的回應現在需要 `30+` 秒 - 你傳送訊息後，輸入指示器出現前有明顯延遲 - 串流回應的開始比平常慢得多 - 工具執行（檔案讀取、搜尋）明顯需要更長時間 **主要訊號：** 回應所需時間比平常顯著更長 **徵兆：** - 要求釐清已提供的資訊 - 忘記先前建立的模式或慣例 - 無法參照先前討論過的檔案或程式碼 - 對專案結構提出重複的問題 **具體範例：** - 當你在 `30` 則訊息前已指定 React 時，仍詢問「你使用什麼框架？」 - 要求你已經提供多次的檔案路徑 `@-mentioned` - 不記得你在工作階段開始時建立的命名慣例 - 重新解釋你已經附帶理由否決的概念或方法 **主要訊號：** Verdent 詢問已經討論過的事情 **徵兆：** - 接近 `200K` token 限制的最後五分之一（已使用約 `160K+` tokens） - 長對話包含大量檔案讀取與工具輸出 - 啟用多個帶有龐大工具定義的 MCP 伺服器 - 重複將大型檔案載入上下文 **具體範例：** - 工作階段已運行 `2+` 小時，包含 `100+` 則訊息 - 你在整個對話中已載入 `20+` 檔案，附帶 `@-mentions` - 上下文中有多個大型檔案（每個 `>1000` 行） - 你啟用了 `5+` MCP 伺服器，帶有大量工具定義 - 對話包含許多 grep/搜尋結果與檔案讀取 **主要訊號：** 非常長的工作階段，伴隨大量檔案/工具使用 **何時採取行動：** 效能下降是你的主要訊號。如果 Verdent 的回應變得較不準確、較慢或不一致——請開始新的工作階段或使用上下文管理策略。 如果 Verdent 的回應變得模糊或重複，可能正在發生上下文過載。重置對話以恢復完整效能。 **注意：** 使用 `1M` token 上下文（Claude Sonnet 4.5）時，這些問題會少很多。 --- ## 何時重置上下文 - 回應時間明顯變慢 - 回應較不準確或不一致 - Verdent 忘記較早的上下文或模式 - 接近上下文視窗限制（留意下降徵兆） **行動：** 當品質下降時開始新的工作階段 - 在不相關的功能或模組之間切換 - 完成一個待辦事項並進入下一個 - 在記憶體密集的任務之後（大型重構、架構工作） - 從研究階段進入實作階段 **行動：** 為新的重大任務開啟新工作階段 - 將完成的功能提交到版本控制之後 - 在開發工作流程的邏輯檢查點之間 - 在測試-驗證-提交循環之後 **行動：** 提交 → 測試 → 新工作階段 - 在開始重大新功能之前 - 當對話歷史變得非常長時 - 在完成多檔案變更之後 - 在不同類型的工作之間（除錯 → 功能開發） **行動：** 在上下文下降前主動開始新工作階段 **最佳實務工作流程：** 完成原子單位的工作 → 測試 → 提交 → 清除上下文 → 為下一個任務開始新的工作階段。 **注意：** 開始新的工作階段以重置上下文。對於 `1M` token 上下文，清除的需求頻率要低得多。 --- ## 工作區組織的影響 工作區組織直接影響上下文的使用效率，以及 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 更大的上下文視窗，最佳化變得不那麼關鍵——專注於任務品質而非積極的上下文管理。然而，良好的實務仍能提升效率與組織性。 --- ## 常見問題 標準模型（Claude 4.5 Sonnet、Haiku、GPT-5、GPT-5-Codex、MiniMax-M2）擁有 `200K` token 上下文視窗，足以應對大多數任務。Claude Sonnet 4.5 為擁有 `1000+` 檔案的大型程式碼庫、複雜的多檔案重構或長時間開發工作階段，提供延伸的 `1M` token 上下文（5 倍大）。`1M` 上下文會在輸入超過 `200K` tokens 時自動啟用，或可明確選取。 你必須手動開始新的工作階段才能重置上下文——Verdent 不會自動清除上下文。最佳實務：在完成原子單位的工作、測試並提交到版本控制之後重置。對於 `1M` token 上下文，重置的需求頻率要低得多。 沒有固定的檔案限制——這取決於檔案大小和總 token 數量。對於 `200K` 上下文，避免載入 `20+` 大型檔案（每個 `>1000` 行）。專注於與你目前任務直接相關的檔案。有所取捨地使用 `@-mentions`，並善用 `AGENTS.md` 文件，而非載入大量範例檔案。使用 `1M` 上下文時，檔案選擇變得不那麼關鍵。 你工作階段中的一切：對話中的所有訊息、載入上下文的檔案內容、工具輸出（grep/搜尋結果、檔案讀取）、系統提示詞與指令，以及 MCP 伺服器定義。這些都會消耗你總上下文容量中的 tokens。 不會——重置上下文只會從記憶體中清除對話歷史和已載入的檔案。你實際的程式碼變更、提交和檔案修改都會保留。為了安全起見，請務必在重置上下文前將工作提交到版本控制。重置 → 開始新工作階段 → 繼續處理下一個任務。 --- ## 另請參閱 撰寫有效提示詞的最佳實務 了解執行模式及其資源影響 監控 token 使用量、點數與效能