AI 程式助理卡關？適時重啟會話更有效率

在使用 AI 編碼會話時，存在一種沉沒成本的陷阱。你可能已經花費四十分鐘使用 Codex CLI 或 Claude Code 處理一項任務，AI 助理累積了大量上下文，感覺丟棄這些很浪費。因此，你不斷嘗試，用「不對，再試一次」來引導它，但每次互動都變得更慢、更昂貴且更不準確。很多時候，正確的做法是終止當前會話，並以簡短摘要重新開始。以下是如何判斷何時該這麼做。

為何長時間會話會退化：AI 助理會話會將其所有歷史記錄帶入後續互動，包括每次檔案讀取、工具輸出和失敗嘗試。隨著歷史記錄的增長，每次互動的成本會更高，因為每次都會傳送更多上下文。

品質也會下降，因為模型處理龐大上下文的可靠性較低，且早期的錯誤會留在歷史記錄中，影響後續的互動。上下文壓縮會導致細節丟失，當工具為了節省空間而自動摘要時，檔案路徑或確切錯誤等特定事實可能會消失，導致重複讀取和重複犯錯。

使用限制也會更快耗盡，讓你更快達到使用上限。對於相同的任務，一個精確簡潔的新會話通常會比一個臃腫的舊會話表現更好。

七個該重啟的跡象：AI 助理重複嘗試它已經試過的修復方法，表示它已經忘記了自己的歷史記錄。它與先前的決定相矛盾，例如重新引入你已經拒絕的方法。

你已經針對相同的事情糾正它兩次。任務已經改變，例如你開始修復一個錯誤，但現在卻是重新設計一個模組，新任務就該有新會話。

花費或使用量持續攀升，卻沒有任何提交（commit），20-30 分鐘內沒有檢查點就是一個警訊。上下文壓縮已經發生不止一次，且 AI 助理詢問它已經知道的事情。回應變得越來越慢且模糊。如果出現其中兩個或更多跡象，你就應該重啟會話。

如何在不丟失進度的情況下重啟：終止會話不代表會丟失工作。請先執行以下步驟：

1. 提交或暫存有用的部分。如果部分差異是好的，請將其提交到一個分支。如果沒有任何有用的部分，請使用 git stash 或 reset。

2. 在退出前要求一份交接摘要：用少於 150 字總結目標、你做了哪些更改、哪些嘗試失敗了以及原因，以及當前的阻礙。列出相關的檔案路徑。

3. 編輯摘要。刪除錯誤的結論。添加你已知但 AI 助理不知道的資訊。

4. 以該摘要作為第一個提示詞，並加上更精確的任務陳述來開始一個新會話，例如：「只修復 auth.test.ts 中失敗的測試。不要更改會話模型。」這通常只需兩分鐘，卻能節省更多時間。

透過設計降低重啟成本：執行小型任務，將提示詞範圍設定為可在一次短會話中完成的內容。使用持久性上下文檔案，將專案規則和架構筆記放在 CLAUDE.md 或 AGENTS.md 中，這樣新會話就能免費獲得這些資訊，而無需重新發現。

建立檢查點提交，要求 AI 助理在每個通過的步驟後進行提交。使用工作樹（worktrees）進行平行嘗試，如果你不確定哪種方法有效，可以在不同的 Git 工作樹中運行兩個新的會話，而不是一個長時間嘗試兩種方法的會話。

將計量器作為決策依據：當你不確定是該繼續還是重啟時，請查看會話到目前為止的成本與其產出的成果。如果使用量在半小時內持續攀升卻沒有任何提交，這就是你的答案。

問題在於許多人從不查看這些數據，因為使用量顯示在網頁儀表板上，而會話則在終端機中進行。我使用 TokenBar，這是一個 Mac 選單列應用程式，可以追蹤 Claude Code、Codex、Cursor 和相關 AI 的使用情況，讓今日的消耗量一目了然。

它終身費用為 15 美元，並基於 MIT 授權的 CodexBar 專案開發。聲明：TokenBar 是我（Aura Technologies）開發的。它不會替你做決定，但它會將數字呈現在你眼前，讓你有時間採取行動。

一個值得添加到 AI 助理配置的規則：AI 助理很擅長遵循明確的停止條件。可以添加類似這樣的規則：「如果相同的方法失敗兩次，請停止並總結你嘗試過什麼以及目前的阻礙，而不是嘗試變體。」這會將許多原本可能很長的會話轉變為以一個有用的問題結束的短會話。

總結：長時間的會話感覺很有效率，因為你投入了其中。但上下文並非免費，且充滿失敗嘗試的歷史記錄會積極地造成負面影響。當 AI 助理開始重複自己、偏離主題或在沒有提交的情況下消耗使用量時，請保存有用的部分，取得摘要並重新開始。這樣做更便宜、更快，通常也能獲得更好的結果。