我是一般 claude.ai 使用者，沒有寫程式，這篇文章跟我有關係嗎？
直接的設定操作跟你沒有關係——Prompt Caching 是 API 層級的功能，claude.ai 網頁版跟 App 的快取邏輯是平台自動處理的，一般使用者不需要也無法手動標記快取區塊。
不過如果你的工作內容涉及評估或採購某個串接 Claude API 的第三方工具（例如客服系統、內部知識庫問答機器人），理解這個概念能幫你在跟廠商討論費用時問對問題——例如「你們的系統有沒有正確設定 Prompt Caching」，或是「你們最近有沒有檢查過快取有效期限的變化」，這類問題往往能幫你判斷對方的成本控管是否到位，間接影響你實際要付的服務費用。
如果我的應用場景是每個使用者的對話都不一樣，還有辦法用 Prompt Caching 嗎？
有辦法，重點在於區分「哪些內容真的因人而異」跟「哪些內容其實是共用的」。即使每個使用者的具體問題不一樣，絕大多數應用仍然有一大塊共用內容：系統提示詞（定義角色跟規則）、產品知識庫、工具定義，這些通常對所有使用者都是一樣的，可以被快取。只有使用者這次輸入的訊息本身、跟這場對話累積的歷史紀錄，才是真正因人而異、無法共用快取的部分。
實務上的做法是把可快取的共用部分放在提示詞結構的前段（例如系統提示詞、知識庫），把因人而異的部分放在後段（使用者訊息、對話歷史），只在共用部分的區塊加上快取標記。這樣即使每個使用者的問題完全不同，共用的那一大塊內容依然能命中快取，省下的成本通常還是很可觀。
Prompt Caching 會不會影響 Claude 回答的品質或速度？
不會影響品質，命中快取的內容跟重新處理得到的結果在語意上是一致的，這不是一種「降級」或「精簡」機制，只是跳過重複的運算步驟。速度方面通常還會有正面幫助，因為讀取已經算好的快取，理論上比從頭處理一大段內容要快，這也是為什麼有些技術文章會提到快取命中率不只是成本指標，也是延遲跟使用體驗的間接指標。
真正需要注意的是快取失效的情況：如果因為內容不吻合（例如快取過期、或提示詞裡有變動的部分）導致快取沒有命中，那次請求就會被當成全新內容處理，除了成本變成標準價格甚至寫入價格之外，處理時間通常也會比命中快取時稍長，但這不是「品質下降」，只是退回沒有快取加速的正常處理速度而已。
如果我想開始檢查自己的應用有沒有把 Prompt Caching 用好，實際上該怎麼做？
最直接的起手式，是先去看 API 回應裡的 cache_read_input_tokens 跟 cache_creation_input_tokens 這兩個欄位——如果你的應用長期只看到 cache_creation_input_tokens（不斷在寫入）卻很少看到 cache_read_input_tokens（幾乎沒有命中），代表你的快取設定可能有問題，常見原因是內容裡混入了每次都會變動的東西（例如時間戳），或是請求間隔經常超過目前的 TTL 導致快取一直過期。
找到問題後，可以先檢查你的系統提示詞跟工具定義裡有沒有不必要的動態內容，把這些內容移到快取區塊之外；再評估你的請求間隔模式，判斷目前用的 5 分鐘 TTL 是否適合，或需要改用 1 小時的延長快取。做完這輪檢查，通常就能看到 cache_read_input_tokens 的比例明顯提升，這也是最直接反映快取設定是否正確的訊號。
如果你在用 Claude API 建構產品，而且系統提示詞或參考文件不算短，Prompt Caching 大概是投入產出比最高的一項優化——設定成本幾乎是零，但省下的費用是實打實的。不過這個機制裡有一個 2026 年才發生的變化，讓不少開發者在毫無防備的情況下被多收了錢，值得特別拉出來講。
每次你呼叫 Claude API，系統實際上要把這場對話從頭到尾的內容——系統提示詞、工具定義、之前所有對話紀錄、你這次新打的訊息——整個重新處理一次，才能產生回答。如果你的系統提示詞或知識庫文件很長，而且每次請求幾乎一模一樣，你等於是在為同樣的運算重複付費。
Prompt Caching 讓你可以標記出提示詞裡「不會變」的部分，Anthropic 會把這部分處理過的運算結果先儲存起來；之後只要新請求的開頭跟被快取的內容完全一致，Claude 就能直接讀取已經算好的結果，讀取的價格只要標準輸入價格的十分之一。實務上的數字很直觀：一個帶著 8,000 token 系統提示詞跟文件集的客服機器人，在 Sonnet 標準輸入費率下，每百萬則訊息光是重複的固定內容就要花 24 美元；啟用快取之後，這部分內容的成本降到每百萬則訊息 0.3 美元。
設定方式很簡單：在你想要快取的內容區塊（通常是系統提示詞、長篇文件、或工具定義）加上 `cache_control: {type: "ephemeral"}` 標記。第一次請求時，這部分內容會被寫入快取，寫入的價格是標準輸入價格的 1.25 倍（5 分鐘有效期）或 2.0 倍（1 小時有效期，屬於延長快取選項）；之後只要在有效期限內、且開頭內容完全吻合的請求，就能以標準價格的十分之一讀取，回本速度非常快——用 5 分鐘 TTL 的話，命中一次就已經打平寫入的額外成本，之後每次命中都是純粹的節省。
要特別注意的是可快取內容有最低門檻，通常是 1,024 個 token 起（依模型略有差異），低於這個門檻的內容即使標記了也不會產生快取效果，只是白白浪費一次標記的動作。
這是本文要特別提醒的重點：Anthropic 在 2026 年初，把預設的快取有效期限（TTL）從原本的 1 小時，悄悄調整為 5 分鐘。多個獨立技術部落格都記錄了這個變化帶來的實際衝擊——有開發者記錄自己某天早上打開帳單儀表板，發現單日費用高達 13.86 美元，遠超平常水準，事後追查才發現，是原本間隔設計在 1 小時內、能穩定命中快取的請求，因為新的 5 分鐘 TTL 而大量失效，被迫以完整價格（甚至是寫入價格）重新運算。
對原本針對 1 小時快取設計的應用而言，這個變化讓實質成本在毫無預警的情況下上升了三到六成。這件事最重要的啟示不是「TTL 變短了」這個單一事實，而是快取的有效期限本身是一個會隨 Anthropic 政策調整而變動的參數，不是設定一次就能終身套用的常數——過去驗證過的成本估算，換了時間點重新檢查依然有意義。
簡單的判斷原則是：如果你的應用請求頻率很高，兩次請求之間的間隔通常遠短於 5 分鐘（例如即時客服對話），標準的 5 分鐘 TTL 就足夠，因為快取幾乎不會有機會過期。如果你的應用場景是請求間隔比較分散、但仍然頻繁到能在一小時內命中至少五到七次（例如多個使用者共用同一份系統提示詞、但個別使用者的請求間隔不固定），1 小時的延長快取雖然寫入成本較高，長期來看仍然划算。
一個簡單的判斷原則是：內容本身「有實質內容、而且不常變動」的東西，幾乎都適合快取——系統提示詞、長篇知識庫文件、工具定義都是典型例子。反過來，「像中繼資料一樣、每次都會變」的東西不適合快取，最常見的地雷是有開發者習慣在系統提示詞裡塞入當下的時間戳，這種做法會讓每一次請求的開頭內容都不一樣，快取永遠命不中，等於完全喪失這項優化的效果，卻還要多付寫入的額外費用。
如果你的團隊每個月在 Claude API 上花費不少預算，檢查是否已經啟用 Prompt Caching、以及目前的 TTL 設定是否符合你的實際使用模式，通常是最快能看到成本下降的一步，不需要重寫任何 prompt 邏輯。而如果你的應用最近帳單無故上升，卻找不到明顯的程式改動，先檢查快取命中率（可以透過 API 回傳的 `cache_read_input_tokens` 跟 `cache_creation_input_tokens` 兩個欄位觀察），往往比逐行檢查程式碼更快找到問題根源——這正是本文開頭提到、讓不少開發者措手不及的那個坑。