對話已經持續很久。您否決了一個解法，也說明了原因，十幾則訊息後，代理卻又提出一模一樣的方案。第一個念頭很直接：全部清掉，重新來過。
代理重提遭否決的解法，是個明顯訊號，但還不能據此下結論。單看一則回覆，無法判定問題出在對話累積太多；需求描述互相矛盾，或代理參照的是半小時前的檔案版本，也會出現相同情況。
接下來談三個直接操作對話的指令：/context 顯示上下文視窗的使用狀況，/compact 將歷史整理成摘要，/clear 則開啟新對話。比起指令語法，更重要的是如何選擇：事前要保存什麼、事後要核對什麼，以及怎麼判斷問題根本不在對話長度。
先找出問題
在壓縮或清除任何內容之前，先分清四種情況。表面看起來很像，代理似乎都"沒聽進去"，但該採取的做法各不相同。
- 缺少必要資訊。 沒有人說明獎勵的發放規則，讀過的檔案裡也找不到。壓縮對話不會憑空補出從未提供的資訊，缺少的內容還是得補上。
- 資訊已過時。 對話裡留著半小時前讀取的檔案內容，但磁碟上的版本已經不同。這時該重新讀取，而不是壓縮。
- 需求互相矛盾。 聊天中談好一件事，已保存的規格卻寫著另一件。請自行確認哪項要求才有效，並修正來源。檔案不會只因為是檔案就自動正確。
- 對話累積太多雜訊。 裡面有許多遭否決的方案、冗長的指令輸出，還討論了與任務無關的檔案。這時處理上下文才真的有幫助。
上下文視窗的使用率不是第五種問題，也無法解釋所有錯誤。比例高，不代表代理一定因此出錯；比例低，也不代表對話毫無問題。檢查順序很簡單：先看需求，再確認檔案與輸出是否最新，最後才檢查對話本身。
請 Claude Code 說明目前的任務目標、限制條件，以及建議方案依據哪些檔案。把回答和您掌握的資訊比對。如果它提到與任務無關的檔案，或說出的目標和您原本設定的不一樣，就知道該修正哪裡；而且問題很可能不在對話長度。壓縮後和開始新對話時，也可以再問一次。
查看上下文視窗的使用狀況
如果您仍懷疑問題出在對話本身，可以查看 /context。這個指令會依類別顯示上下文視窗的使用狀況：系統內容、專案指示、讀過的檔案與指令輸出、對話，以及剩餘空間。哪些資訊已經和任務無關，由您判斷。指令不會評估讀取內容的意義，訊息那一行的總計也不會告訴您哪個檔案多餘。
沒有通用的門檻，例如"超過某個百分比就該壓縮"；視窗大小也會隨模型和設定而異。請看內容組成，而不是百分比。另外，關閉編輯器分頁並不會自動移除已經讀進對話的內容。
壓縮後繼續任務
/compact 會將歷史整理成摘要，您仍留在同一個任務中。Claude Code 也會隨著視窗快滿而自動壓縮；手動執行則是為了挑選時機（例如開始一大段新工作之前），並指定摘要焦點。
主要限制是：留下的是摘要，不是原本的對話。摘要以外的細節不能當成仍保留在視窗裡。而"請保留這些條件"也不保證摘要完整，這只是請求，並非一項機制。
該保存什麼
執行指令前，先為任務整理一則簡短備註：目標、範圍、已採納的決定、已確認的事實，以及下一步。花幾分鐘整理，之後就能拿備註和檔案、檢查輸出核對，比憑印象回想對話可靠。無須另建檔案，寫在現有的任務文件就可以。
以下是"再次發放獎勵"這個練習任務目前的狀態，僅為範例，並非實際檢查報告：
目標：同一場已結束的遊戲中，獎勵只發放一次；新的一場可以再次發放。
範圍：src/reward-flow.js 和現有的獎勵檢查；不要更動畫面呈現。
已確認：第一次發放後，在同一場遊戲再次按下按鈕，分數仍會增加。
依據：TASK_SPEC.md 記載了重現步驟和初始狀態。
已否決：不修正重複點擊處理，只隱藏按鈕。
下一步：檢查處理函式並提出修改方案；尚未修正，也尚未執行測試。請留意最後一行。已確認問題可以重現，和已完成修正是兩回事；備註必須清楚區分，否則壓縮後很容易把"檢查過"說成"修好了"。這裡的任務文件是練習用的，實際使用時請換成您的路徑。
核對過備註後，就可以指定焦點來壓縮：
/compact 請專注於修正重複發放獎勵的問題。保留目標、TASK_SPEC.md 中的範圍、已確認的重現方式、遭否決的方案和下一步。註明修正和測試都尚未完成。壓縮後要核對什麼
壓縮後不要直接從剛才沒說完的地方繼續。先把必須準確的資訊帶回對話，再問一個確認問題：
請讀取 TASK_SPEC.md 和最新版 src/reward-flow.js。簡短說明限制條件和下一步。如果摘要和檔案內容不一致，請指出差異。先不要修改程式碼。請逐項核對回答和備註，不要只憑整體印象。在這個例子中要檢查三件事：
- "下一步"那一行沒有把修正和測試說成已完成；
- "範圍"中的禁止修改畫面呈現仍然保留；
- "目標"中關於新的一場遊戲的條件沒有遺失。
代理的措辭可能不同，這很正常。條件不見了，就在修改前從來源補回來。您檢查的是對話狀態，不是程式碼；這樣核對並不能證明下一次修改一定正確。
壓縮只會處理對話歷史，不會還原檔案修改，也不能取代 Git。根目錄的 CLAUDE.md 會重新載入，所以專案規則會保留下來；但不要把任務的暫時狀態寫在那裡："現在正在修正獎勵發放"這句話，任務結束後仍會留著。代理在壓縮後說出的資訊，也不會自動變成可信的事實。請確認資訊來源：摘要、重新讀取的檔案，或新的執行結果。
開始新任務
/clear 會在不帶入先前對話的情況下開啟新對話。磁碟上的檔案和專案指示都還在，已啟用的自動記憶也可能繼續使用；所以這裡的"從頭開始"指的是對話。舊對話不會被刪除，您可以用 /resume 回到它。
這個指令很容易和 claude --continue 搞混，但兩者的作用正好相反。您在工作階段中輸入 /clear，是為了離開累積的對話歷史；啟動時在終端機輸入 claude --continue，則會連同完整歷史一起回到這個資料夾最近的對話。如果問題正是出在那段對話，--continue 會把您帶回的正是那段對話。
清除前，先保存接下來會用到的資訊：備註、相關路徑、檢查輸出。新對話需要明確的任務描述，而不是暗示：目標、限制和路徑。使用 @檔案 可以指定要讀取的檔案，但請注意，這只是引導讀取，不會限制它存取其他檔案。
選擇要採取的動作
流程可以很精簡：先停下來問確認問題；不清楚視窗裡有哪些內容時，查看使用狀況；接著選一個動作，再核對結果。數訊息數量沒什麼用，該看的是對話內容，以及您接下來打算做什麼。
| 情況 | 動作與理由 |
|---|---|
| 代理沒有取得獎勵發放規則 | 提供規則和檔案；壓縮無法補上缺少的內容 |
| 回答依據的檔案後來已經修改 | 請代理重新讀取最新版；無須壓縮 |
聊天中談妥一件事，TASK_SPEC.md 卻記載另一件 | 確認哪項要求有效，並修正來源 |
| 任務相同，但遭否決的方案很多，可用空間所剩不多 | 先寫備註，再指定焦點執行 /compact，並提出確認問題 |
| 壓縮後遺失了不得修改相鄰模組的限制 | 重新讀取限制來源，修改前先確認代理理解正確 |
| 要開始與畫面呈現有關的獨立任務 | 保存必要成果，執行 /clear，再描述新任務 |
工作方式有什麼改變
這三個指令本身不會修復任何問題。改變的是您處理長任務的方式：
- 遇到奇怪的回答，先檢查需求和檔案是否最新，再檢查對話；
- 壓縮或清除前先整理備註並和檔案核對，壓縮後再逐項比對回答；
- 新任務有自己的需求描述，不會沿用上一段對話的殘留內容。
用同一個請求來看差異。原本是：
你搞混了，重新來過。改成：
目前的任務是修正 src/reward-flow.js 中重複發放獎勵的問題。
請讀取 TASK_SPEC.md，說明限制條件和下一步。先不要修改程式碼。第二種說法會得到可供檢查的回答：您可以把其中提到的限制和步驟與檔案比對，立即找出差異。第一句話則沒有可供核對的內容。
GO TO FULL VERSION