Prompt Compression

Prompt 壓縮是一組技術的統稱，目標是在維持輸出品質的前提下，減少每次 API 呼叫的輸入 Token 數量，從而降低費用和提升回應速度。

為什麼需要 Prompt 壓縮？

Claude API 按 Token 計費——你輸入多少、Claude 輸出多少，加起來就是費用。輸入 Token 的費用通常低於輸出（Sonnet 4.6 的輸入是 $3/M，輸出是 $15/M），但在高頻率的應用裡，輸入的累積費用非常可觀：

假設你的應用有一個 2,000 Token 的 System Prompt，每天 10,000 次 API 呼叫，光是 System Prompt 每天就是 2,000 × 10,000 = 2,000 萬 Token，每月費用約 $180。如果你能把 System Prompt 精簡到 800 Token（效果不變），同樣的計算結果是每月約 $72，省了 $108。

四個主要的 Prompt 壓縮方向：

一、System Prompt 精簡：去掉冗余的解釋和範例，只保留 Claude 真正需要的規則和背景。

二、對話歷史壓縮：多輪對話累積的歷史越來越長，用摘要壓縮舊的輪次。

三、文件截斷和過濾：不需要把整份文件都放進去，只放和當前任務最相關的部分。

四、結構化輸入：把冗長的自然語言描述改成結構化格式（JSON、表格、條列），同樣的資訊用更少的 Token 表達。

怎麼有效地精簡 System Prompt，同時確保輸出品質不降級？

精簡 System Prompt 有幾個有效的原則和方法：

原則一：用例子代替規則的解釋

冗長版：「你需要以一個親切但不過分正式的語氣和用戶說話。這意味著你應該避免使用太多技術術語，但也不要用太口語化的用語。回答應該清晰明確，讓沒有技術背景的人也能理解，同時也不能過於簡化以至於讓有一定技術知識的用戶感覺被輕視。」（約 80 Token）

精簡版：「語氣：親切，避免技術術語，適合中等技術背景的讀者。範例：『每次打開應用程式都會重新開始』而非『每次工作階段重置後狀態清除』。」（約 30 Token）

原則二：刪掉不影響行為的背景資訊

很多 System Prompt 裡有大量「公司介紹」「背景說明」，但 Claude 不需要這些來完成任務。只保留真正影響 Claude 行為的資訊（怎麼說話、做什麼、不做什麼）。

原則三：用結構化格式取代段落

一段 100 Token 的段落解釋，通常可以用一個 40 Token 的條列清單達到同樣甚至更好的效果——因為結構化格式讓 Claude 更容易「掃描和遵循」規則。

驗證方法：精簡後，用你最常用的 10-20 個測試案例，比較精簡前後的輸出品質。如果差距可接受，就是有效壓縮；如果品質降低，找出是哪些被刪的規則導致的，選擇性恢復。

多輪對話的歷史壓縮應該怎麼做？什麼時候壓縮，怎麼壓縮？

對話歷史是 Prompt 膨脹最快的部分——每輪對話都在累積，如果不加控制，長對話最終會把 Context Window 完全佔滿。

什麼時候應該壓縮：

建議設定一個觸發條件，如「對話歷史超過 15 輪」或「當前 Context 使用量超過 50%」。在觸發條件達到之前不壓縮（壓縮需要額外的 API 呼叫），觸發後執行一次壓縮。

怎麼壓縮：

方法一：滾動摘要 把最早的 N 輪（如前 10 輪）用 Claude 生成一個摘要（「前面的對話裡，你告訴我你的需求是 X，我們決定用 Y 方案，主要設計決策是 A、B、C...」），用這個摘要替換那 10 輪的原文，新的對話繼續累積在後面。

方法二：重要資訊保留 對每輪對話做「重要性評估」：包含關鍵決策、用戶明確偏好、重要的錯誤修正的輪次保留原文；只是過程討論、重複確認的輪次壓縮成一行摘要。

壓縮提示詞範例： 「以下是對話的前 10 輪，請生成一個 150 字以內的摘要，包含：1. 用戶的核心需求；2. 已確認的重要決策；3. 任何我（Claude）做過的重要承諾。不需要包含過程討論。」

注意：壓縮後的摘要要放在對話歷史的最前面（在 System Prompt 之後），讓 Claude 先讀到背景摘要再繼續對話。

除了 System Prompt 和對話歷史，文件輸入的 Token 怎麼控制？

在需要分析長篇文件的應用裡，文件本身往往是最大的 Token 消耗來源。幾個有效的控制方法：

方法一：分層過濾

不要把整份文件放入，先做一個「相關性過濾」：用 Haiku（費用極低）先對文件做一個快速的段落級相關性評分（「哪些段落和這個問題最相關？評分 1-5 分」），只把評分 4 分以上的段落放入主要的 API 呼叫。這讓你能在一個 10,000 Token 的文件裡，只提取最相關的 2,000-3,000 Token 給 Sonnet 或 Opus 分析。

方法二：結構化提取

對有固定格式的文件（合約、財報、履歷），預處理時把關鍵欄位抽取成結構化格式，而不是放入原始文件全文。

例如，一份 5,000 Token 的合約，提取後的結構化關鍵資訊可能只需要 500 Token：

{
  "parties": ["A公司", "B公司"],
  "value": "$500萬",
  "term": "2024-2027",
  "key_clauses": ["不競爭條款（第5條）", "獨家代理（第7條）"],
  "risk_flags": ["自動續約條款（第12條）"]
}

方法三：滑動窗口

對很長的文件，設計一個滑動窗口——每次只把和當前問題最相關的「窗口」（如前後各 2,000 Token）放入 API 呼叫，而不是整份文件。這在保持相關性的同時，把每次呼叫的輸入 Token 控制在固定範圍內。