理解 Deep Code 嘅上下文同工作階段管理機制
喺前面嘅文章入面，我哋使用 Deep Code 執行一次完整任務嘅全過程，並教大家點樣睇明佢嘅各種輸出資訊。
喺利用 Deep Code 開展人工智能輔助程式設計嘅過程中，好多開發者會發現 AI 嘅回應速度隨任務推進而逐漸減慢。
呢個並唔係由於 AI 性能下降，而係受限於上下文（Context）冗餘及其背後嘅業務邏輯。本文將解釋 Deep Code 嘅上下文處理機制，並介紹點樣透過工作階段管理優化開發效率。
一、理解「上下文」嘅本質
喺人工智能領域，「上下文」係模型理解目前任務嘅基礎。由於目前嘅大型語言模型（LLM）多以公共基礎設施嘅形式提供服務，其本質上並不具備針對特定用戶嘅長期記憶。
- 專家會診邏輯：我哋可以將 LLM 嘅工作流程類比為醫院嘅專家會診。每一次下達指令時，Deep Code 必須將目前任務連同相關嘅歷史資訊一併提交畀模型。
- 「病歷卡」隱喻：呢啲歷史資訊構成咗 AI 嘅「病歷卡」。若該記錄中充斥住大量無關資訊（例如喺同一對話中頻繁切換唔相關嘅程式設計模組），AI 專家喺分析問題時便會因資訊干擾而導致處理效率大幅下降，甚至出現邏輯偏差。
二、自動壓縮機制嘅局限性
為咗紓緩資訊冗餘，Deep Code 內建咗自動壓縮上下文嘅功能。當歷史記錄達到一定長度，系統會自動提取重點並剔除重複嘅檔案引用。然而，呢個機制存在以下局限：
- 資源消耗高：自動壓縮過程通常會佔用 20% 以上嘅輸入字元（Token）空間，呢個喺處理大型項目時會造成顯著嘅資源浪費。
- 無法應對需求劇變：壓縮機制本質上係基於歷史數據對用戶意圖進行預測，而唔係真正嘅上下文切換。如果開發者喺單一工作階段中突然提出跨度極大嘅新需求（例如從後端邏輯重構轉向前端 UI 微調），模型往往會因為無法準確「讀心」而陷入思維混亂。
三、基於「工作階段機制」嘅優化策略
實現高效人機協作嘅關鍵在於確保 AI 能夠**「一心一意，一事一辦」。Deep Code 建議將每個獨立嘅開發任務分配到特定嘅工作階段（Session）**中。
透過規範嘅工作階段管理，開發者可以利用以下指令靈活控制 AI 嘅專注度：
- 初始化新任務（
/clear）： 呢個指令用於清除目前對話內容並建立一個全新嘅工作階段。呢個等如為 AI 專家提供咗一份空白嘅病歷卡，使其能夠完全專注於目前嘅新任務，唔受歷史干擾。
- 恢復歷史進度（
/resume）： 當需要重回之前嘅開發分支時，透過/resume指令可列出項目中所有嘅歷史工作階段記錄。系統會為每個工作階段提供一句話摘要，開發者可透過方向鍵精確選擇並回溯到特定任務節點。若需終止選擇，按ESC鍵即可退出。
總結
高效使用 Deep Code 嘅核心在於主動管理上下文。透過將工作階段粒度精細化，唔單止能節省寶貴嘅 Token 空間，更能確保 AI 嘅回應速度同邏輯準確性。
呢個就好似： 管理 AI 嘅上下文如同打理一個精密嘅檔案櫃。如果你將所有嘅草稿、方案同合約都堆疊喺一個資料夾入面，搵資訊時必然步履維艱；但如果你為每個獨立項目建立專屬檔案盒（Session），並喺開啟新業務時清空桌面，你嘅工作流將變得高效且井然有序。