你每天都讓 AI 做同一個專案。
但每一次都重新丟：
公司規則。
產品說明。
工作流程。
20 頁背景文件。
工具定義。
再加上今天的新問題。
看起來很完整。
問題是：
AI 可能每天都在重新讀一大堆根本沒有變的東西。
Claude Fable 5.1 把 Prompt Cache Read 價格大幅降低後，
今天只學一個動作：
把 Prompt 先拆成「固定背景」和「今天新增」。
不要每次把所有資料重新攪成一包。
先說清楚：這篇主要是給 API／Agent 工作流程
如果你只是打開一般 Claude App：
聊天。
寫文章。
問問題。
你不需要自己去找一個：
「Prompt Cache」
開關。
今天談的 Prompt Caching，
主要是 Claude API 與開發者建立 Agent、App、自動化工作流程時使用的能力。
也就是：
你的系統每次都要呼叫 Claude，
而且很多背景資料會反覆出現。
這種情況才特別值得管 Cache。
為什麼 Fable 5.1 讓這件事突然更值得注意？
Fable 5.1 的一般 Input 價格是：
每百萬 Token 10 美元。
但是已經命中的 Cache Read，
現在只要：
每百萬 Token 0.25 美元。
相較 Fable 5 原本的 1 美元，
下降：
75%。
但注意：
不是你用了 Fable 5.1，
所有 Input 就自動便宜 75%。
只有真正：
從 Cache 重複讀到的那部分 Context
才適用 Cache Read 價格。
所以第一個問題不是：
「我要不要開 Cache？」
而是：
「我的 Prompt 裡，哪些東西其實一直沒有變？」
第一步：先找出「固定背景」
假設你正在做一個客服 Agent。
每一次請求都需要知道：
公司的品牌語氣。
退款規則。
商品資訊。
客服禁止事項。
Tool Definitions。
五組回答範例。
這些東西可能：
今天一樣。
明天一樣。
下一位客人進來還是一樣。
這就是：
固定背景。
先把它們集中在 Prompt 前面。
不要散落在今天的新問題之間。
第二步：把「今天新增」留到後面
接著才放：
這位客人的問題。
這次的新訂單資料。
今天新增的文件。
這一次真正要完成的任務。
例如：
固定背景：
品牌規則。
商品規格。
退款制度。
工具說明。
客服範例。
今天新增：
「客人表示商品收到時破損，訂單資料如下……」
這樣結構就變成：
前面很大一段長期不變。
後面只有今天的新資料。
這正是 Prompt Cache 比較容易產生價值的結構。
為什麼順序很重要？
Anthropic 的 Prompt Caching 是：
Prefix Cache。
Prefix 就是：
前綴。
系統會從 Prompt 前面開始，
判斷之前是不是已經處理過相同的內容。
所以如果你的 Prompt 是：
固定規則。
固定文件。
固定範例。
今天的新問題。
下一次又是：
固定規則。
固定文件。
固定範例。
明天的新問題。
前面那一大段就有機會被重複使用。
但如果你每次都把：
日期。
使用者名稱。
今天的訂單。
放到最前面，
後面的固定資料即使完全一樣，
也可能比較難形成你原本期待的穩定 Prefix。
最簡單的整理方式
你可以先不用想程式。
拿一張紙寫：
固定背景：
角色。
長期規則。
Tool Definitions。
大型參考資料。
固定範例。
專案背景。
今天新增：
新問題。
新資料。
新文件。
本次輸出要求。
只要這一步做清楚，
後續工程師才知道：
哪一段值得 Cache。
第三步：固定背景不要每次偷偷改一點
這一點非常重要。
假設你的固定背景原本是：
產品文件 A。
產品文件 B。
產品文件 C。
下一次你只是把：
B 和 C 的順序交換。
對人類而言：
資料還是一樣。
但對 Prefix Cache 而言，
前面的內容已經改變。
Anthropic 官方說明：
Cache Entry 是依照 Prompt Prefix 建立。
如果 Cache Breakpoint 以前的內容改變，
下一次就可能產生不同的 Cache。
所以：
想重複使用，就真的讓重複部分保持穩定。
不要為了漂亮，每次重排 Prompt
很多人建立 Agent 時，
會動態產生 Prompt。
例如今天：
規則 → 文件 →範例。
明天：
範例 → 規則 → 文件。
甚至每次把文件依名稱重新排序。
內容看起來都一樣。
但 Cache 的重複利用可能因此變差。
所以可以多一條工作規則：
固定內容固定順序。
真正會變的東西，
集中放後面。
第四步：API 怎麼知道前面要 Cache？
Claude API 現在有兩種主要方式。
第一種比較簡單：
Automatic Caching。
在 Request 開啟 Cache Control，
系統會自動處理適合的 Cache Prefix。
第二種是：
Explicit Cache Breakpoint。
你明確告訴系統：
「到這裡以前是我要重複使用的固定內容。」
如果你的 Prompt 結構非常清楚，
例如：
前面 8 萬 Token 永遠都是專案背景。
最後只有今天的新問題會變。
Explicit Breakpoint 就可以更加精準。
初學者先記一個原則就夠
不要先研究所有 Cache 參數。
先把資料結構整理對。
也就是：
不變的放前面。
會變的放後面。
等到這個結構穩定，
才談：
Automatic Cache。
Breakpoint。
5 分鐘 TTL。
1 小時 TTL。
否則就算 Cache 功能打開，
Prompt 每次都亂變，
效果也可能不好。
Cache 可以放哪些東西？
Anthropic 官方目前支援 Cache 的內容很多。
包括：
Tool Definitions。
System Messages。
一般文字訊息。
圖片。
文件。
Tool Use。
Tool Results。
所以 Prompt Cache 並不只等於：
「快取一句 System Prompt。」
真正大型 Agent 裡，
最有價值的可能反而是：
很長的 Tool Definitions。
專案文件。
大量固定背景。
以及一路累積的對話 Context。
那是不是什麼東西都應該 Cache？
也不是。
如果一份資料每一次都會變，
例如：
今天股價。
即時庫存。
新的客戶訊息。
本次訂單。
今天的新聞。
硬要把它當成固定 Context，
意義不大。
真正適合的是：
重複。
穩定。
夠大。
三個條件。
只有 20 個字的固定 Prompt，
即使想 Cache，
省下來也可能沒有實際意義。
Cache 第一次使用其實不是最便宜
這也是容易誤會的地方。
第一次建立 Cache，
系統還是要先：
讀取。
處理。
再建立 Cache。
而 Cache Write 本身有成本。
Anthropic 目前的 5 分鐘 Cache Write，
是一般 Input 價格的：
1.25 倍。
所以第一次：
不一定比較便宜。
真正省錢的是：
後續再次命中同一份 Cache。
這就像辦會員卡。
如果辦完只去一次，
不一定划算。
如果會反覆使用，
價值才開始出來。
預設 Cache 可以留多久？
Anthropic Prompt Cache 預設 TTL 是：
5 分鐘。
TTL 就是：
Time To Live。
可以理解成：
這份 Cache 有效多久。
每次成功使用，
有效時間會再刷新。
如果你的工作間隔比較長，
Anthropic 也提供：
1 小時 Cache。
但 1 小時 Cache Write 成本更高。
所以不是：
時間愈長愈好。
而是要看你的 Agent：
多久會再次使用同一份背景。
什麼情況 5 分鐘就夠？
例如一個 Agent 正在：
連續做 Code Review。
連續處理一批客服案件。
反覆查同一份文件。
一個多步驟工作裡不停呼叫模型。
這些工作幾分鐘內就會一直重複使用相同 Context。
5 分鐘很合理。
什麼情況可能考慮 1 小時？
例如：
研究 Agent。
一個 Side Agent 要跑很久。
使用者平均每 20～30 分鐘才回一次。
每隔一段時間才處理下一批工作。
而每次都要重新使用同一大段 Context。
這種情況才比較值得評估 1 小時 Cache。
不是因為：
「1 小時比較高級。」
第五步：不要猜 Cache 有沒有成功，要看 Usage
設定完成後，
真正重要的一步是：
檢查。
Claude API 的 Usage 資料會提供：
Cache Creation Input Tokens。
以及：
Cache Read Input Tokens。
如果第二次呼叫後：
Cache Read Input Tokens 開始出現，
代表真的有從 Cache 讀到內容。
如果一直都是：
0。
就不要自己安慰自己：
「應該有 Cache 吧。」
可能原因包括：
Prompt 太短。
Prefix 改變。
Breakpoint 放錯。
已經超過 TTL。
或其他設定造成 Cache Miss。
所以成本優化不能只看總帳單
假設今天模型帳單：
100 美元。
明天：
80 美元。
你還不知道真正原因。
可能是：
使用量少了。
Output 變短。
模型換了。
Cache Hit 增加。
工作失敗變多。
所以比較好的做法是把：
Input Tokens。
Cache Read Tokens。
Output Tokens。
完成率。
人工修改量。
一起看。
便宜但一直做錯，並不是真的便宜。
一個最簡單的實際例子
假設你的 Agent 每次需要：
8 萬 Token 的固定產品資料。
今天新問題只有：
2,000 Token。
以前每次都重新處理：
82,000 Token 左右。
如果固定的 8 萬 Token 能成功從 Cache Read，
真正按照一般 Input 價格重新處理的，
就主要剩下：
新的那一小段內容。
注意：
實際帳單還會受到：
Cache Write。
Output。
模型。
TTL。
以及其他設定影響。
這裡只是說明：
為什麼固定背景與新增資料分開後，Cache 才有機會發揮價值。
最容易犯的錯：為了 Cache 把舊資料永遠留下
也不要走到另一個極端。
如果：
產品規則已經改版。
公司政策改了。
文件過期。
Tool Definition 更新。
就應該更新固定背景。
即使這會造成新的 Cache。
不要為了省幾個 Token，
繼續讓 AI 讀：
已經錯的舊規則。
正確性永遠比 Cache Hit Rate 重要。
所以真正要固定的是「有效版本」
固定背景不代表：
永遠不能改。
而是：
在版本沒有改變期間保持穩定。
例如：
客服規則 v3。
只要 v3 還有效，
保持相同順序與內容。
正式更新成 v4，
就建立新的固定 Context。
這樣你既能：
重複利用 Cache。
也不會把過期資料永久鎖住。
今天只做一件事
如果你有一個 Claude API 或 Agent 工作流程，
先不要急著改程式。
打開現在的 Prompt。
把每一段標記成：
固定。
或：
新增。
然後重新排列成：
固定規則。
固定工具。
固定背景文件。
固定範例。
────────
今天的新資料。
今天的新問題。
今天要的輸出。
只要做到這一步，
你就已經開始從：
「每次重新請 AI 理解整個世界」
改成：
「背景已經知道，今天只處理新的事情。」
這才是 Prompt Cache 真正值得使用的地方。
不是讓 AI 少思考。
而是：
不要一直付錢讓 AI 重讀同一份背景。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 一分鐘教學｜2026/08/10：別只記 AI 成本，每次結果先標成「可用、需修改、失敗」
今日 AI 工具｜2026/08/10：Langfuse，把 AI 每次花多少錢、跑多久、結果好不好記下來，不再只看總帳單
