principle-guard-the-context-window | 控制上下文的階段與容量
本頁以 pstack-claude 0.9.126 為基準。原文設定 user-invocable: false，通常由 poteto-mode 按需讀取。以自然語言要求「套用 principle-guard-the-context-window」即可表達需求，不把原則當作獨立命令。
定位與適用情境
上下文視窗（Context Window）被大量輸出占滿，會影響推理、造成壓縮資訊失真，甚至中斷工作。這項原則要求劃分階段、限制範圍，並計入工具與協調的成本。描述也提到可將大量資料交給子代理，主對話保留摘要。
本例要從三個服務的事件紀錄定位一次逾時。輸入是已去識別化的紀錄檔、事故時間窗與一個請求識別碼。目標是重建這次請求的路徑，不是把整天的紀錄全部放進對話。
準備
- 提供可讀取的紀錄路徑、服務清單、時間範圍與請求識別碼。排除憑證與個人資料。
- 確認工具能否按行、時間或關鍵字縮小輸出。若要分工，先確認子代理可用且獲准。
- 本例約定每階段最多處理一個服務，摘要保留檔案路徑、行號或事件時間，以及未解問題。這是本例的範圍設定，不是上游固定配額。
操作步驟
- 定義本輪問題。 只問「請求在哪一段開始等待」。先以識別碼與事故時間窗找出候選事件，不讀取所有無關紀錄。
- 分段取證。 先讀入口服務，再讀它實際呼叫的下游。每次限制回傳長度。需要擴大時間窗時，記錄擴大的原因，避免重複讀取同一批輸出。
- 收斂主對話。 每階段只留下時間線、直接證據與待查點。若已允許子代理，可按服務切分唯讀任務，只收有來源位置的結論。沒有子代理就循序處理，不假裝已完成獨立分工。
- 檢查餘量再展開。 把工具輸出、分工提示與摘要成本一起考量。摘要已能回答問題就停止；仍缺證據才開下一階段，並保留尚未查證的分支。
可直接使用的提示詞
套用 principle-guard-the-context-window。請用我提供的事故時間窗與請求識別碼，查核三個服務的已去識別化紀錄。
每階段先處理一個服務，只回傳相關片段。主對話保留有路徑、行號或事件時間的時間線、已證實結論與待查點，不貼整份紀錄。
本次只可唯讀，不使用子代理。先報告階段範圍與停止條件，再循序查核。若工具輸出遭截斷，要標明未讀區段，不得從摘要推測遺失內容。預期結果與驗收
預期交付短而可追溯的請求時間線，而非大量未整理輸出。
- 每個「已證實」結論都能回到原始紀錄位置。
- 摘要分開已知事實、推論與未讀區段，不把壓縮後的猜測升格成證據。
- 能說明每一輪讀了什麼、為何需要下一輪，以及何時停止。
- 無子代理時仍可執行分階段查核，不宣稱不存在的工具已完成工作。
限制與權限
常見誤用是先貼滿上下文才要求摘要，或為了節省容量刪掉支撐結論的來源位置。摘要應降低負擔，不應抹去證據與未解問題。
這份原文很短，沒有指定上下文容量百分比、固定輪數或自動壓縮工具。頁面中的分段方法是教學實作建議，不是上游保證。分工不解除資料讀取權限，也不允許把機密紀錄送到未核准的外部服務。