<!-- Canonical URL: https://ask.atlascloud.ai/zh-TW/prevent-long-coding-sessions-from-losing-context -->

# 如何避免長時間編碼工作階段遺失上下文？

> 要避免上下文遺失，應把持久資訊從聊天移到精簡任務帳本、決策記錄、測試記錄和儲存庫檢查點中。在壓縮上下文或切換模型前，先從這些成品重新載入狀態。

長時間工作階段通常不是突然失憶，而是逐漸偏離。智慧體仍記得大方向，卻遺漏一項小限制、相信過時的測試結果、重複調查，或按照已不符合儲存庫現況的計畫修改。解法是建立比聊天記錄更短、也更可靠的持久外部狀態。

把對話當作工作記憶，把儲存庫當作事實來源。每到一個有意義的檢查點，就記錄哪些內容已變更、哪些已驗證、哪些仍不確定，以及接下來要做什麼。

## 追蹤四類上下文

依功能分開記錄事實，避免摘要變成沒有層次的敘事。

| 上下文類型 | 範例 | 持久保存位置 |
|---|---|---|
| 目標 | 使用者要達成的結果與驗收條件 | 任務帳本 |
| 限制 | 相容性、安全、風格、範圍 | 任務帳本 |
| 儲存庫狀態 | 已變更檔案與目前分支 | 版本控制 |
| 證據 | 測試、記錄、螢幕截圖、基準結果 | 驗證記錄 |

只有在明確標記時才把假設作為第五類。每項假設都應附上可確認或否定它的最低成本動作。

## 維護精簡任務帳本

實用帳本應能放在一個畫面中。只在里程碑後更新，不必每則訊息都修改。

```md
Objective:
Ship model-switch support without changing existing tool behavior.

Constraints:
* Preserve the public API.
* No destructive migration.

Current state:
* Parser adapter added in src/stream.ts.
* Unit tests pass; cancellation test still fails.

Decisions:
* Buffer tool arguments until the final event.

Evidence:
* npm test: 142 passed, 1 failed.

Next action:
Fix duplicate execution after stream cancellation.
```

保留精確路徑、命令和失敗名稱。不要把帳本寫成討論過程的日記。

## 以已驗證狀態建立檢查點

檢查點應接在下一個工作階段能重現的結果之後，例如一組通過的測試、一項小型已儲存變更、確認過的 API 回應，或有夾具支援的設計決策。

在切換模型或壓縮上下文前記錄尚未提交的檔案。不能因為程式碼已寫好就聲稱功能可用，必須把結論連到測試、建置或可觀察成品。

| 聲明 | 所需證據 |
|---|---|
| 解析器支援兩個呼叫 | 含兩個正確關聯呼叫 ID 的夾具 |
| 重試安全 | 中斷連線時的冪等性測試 |
| 重構保留行為 | 新舊測試套件都通過 |
| UI 正確 | 目標尺寸下的實際渲染檢查 |

## 重新讀取原始碼，而不是重播聊天

細節重要時，重新開啟目前檔案、Schema 或官方文件。舊聊天片段可能描述已變更的程式碼。提供路徑和搜尋詞，讓智慧體檢查最新狀態。

擷取範圍應保持精簡。先載入介面、實作、失敗測試和相關記錄，再考慮整個儲存庫，為推理保留空間。

## 壓縮時保留決策與證據

好的壓縮會刪除對話重複內容，但保留限制、難以逆轉的決策、被否決的方案和驗證結果。明確區分 `verified`、`observed`、`assumed` 和 `pending`。

不要把失敗實驗摘要成最終設計。若某個誘人方案日後可能再次出現，也要保留它被否決的原因。

## 在工具輸出進入上下文前限制大小

長記錄和產生的檔案會很快消耗注意力。要求工具只回傳相關區間、數量或符合條件的行。完整輸出存為成品，只把短摘要和路徑放回上下文。

測試失敗時，保留第一段有用的堆疊追蹤、失敗斷言和環境資訊即可，避免向模型傳回數百行重複內容。

## 用確定性的流程續接

在暫停、上下文壓縮或模型切換後：

* 讀取目標和限制。
* 檢查版本控制狀態和最近變更。
* 開啟目前狀態中列出的檔案。
* 重跑最近的相關檢查。
* 確認已記錄的下一步仍然有效。

這套流程能在過時摘要造成新修改前抓出問題。

## 選擇模型時不要依賴聊天記憶

閘道讓切換模型更容易，但狀態仍由你負責。Atlas Cloud 從一個 Base URL 提供多種 LLM 協定；移動正在工作的智慧體前，先檢查[協定矩陣](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context)和目前的[模型目錄](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=prevent-long-coding-sessions-from-losing-context)。

向替代模型提供任務帳本、相關原始檔和最新驗證結果。除非已確認相同協定與行為，否則不要依賴供應商特有的狀態控制代碼。

## 結論

持久狀態精簡、有證據支援且容易重新載入時，長時間編碼工作階段才能保留上下文。維護單畫面帳本，以已驗證變更建立檢查點，重新讀取目前原始碼而不是重播聊天，限制工具輸出，並採用確定性的續接流程。更大的上下文視窗有幫助，但真正讓工作可復原的是有紀律的外部狀態。

## FAQ

### 更大的上下文視窗足以支援長時間編碼工作階段嗎？

不足。更大空間只能延後壓力，不能保證早期限制一直突出，也不能保證過時觀察會被修正。

### 編碼工作階段帳本應包含什麼？

記錄目標、限制、目前計畫、已變更檔案、重要決策、驗證結果、未解風險以及確切的下一步。

### 智慧體多久應建立一次檢查點？

在通過重要測試、完成遷移步驟、做出設計決策或發現會改變計畫的新資訊後建立。

### 應該把完整聊天記錄交給新模型嗎？

通常不應。提供整理過的檢查點、相關原始碼和記錄，讓新模型檢查目前的儲存庫狀態。

### 如何避免摘要保留舊錯誤？

把已驗證事實和假設分開，附上命令或檔案位置等證據，並在新測試推翻舊結論時撤回相關敘述。

### 中斷後最安全的續接方式是什麼？

重新載入任務帳本、檢查版本控制狀態、重跑最近的相關驗證，然後從已記錄的下一步開始。