Anthropic團隊把1個指標當心跳監(jiān)測

你的Claude賬單可能比鄰居貴9倍，而你們用的明明是同一套代碼。

這話不是我說的。Anthropic的Claude Code團隊上周在推特上丟了個炸彈：他們把「提示緩存命中率」當成產(chǎn)品生命線來監(jiān)控，掉一點就全員緊急響應。不是優(yōu)化項，不是省錢技巧——是承重墻。塌了，整個產(chǎn)品就埋在里面。

我花了兩周才搞懂這玩意。當時盯著Stripe后臺，測試環(huán)境燒積分的速度像小孩拿著生日禮品卡在GameStop橫沖直撞。后來才發(fā)現(xiàn)，同一套對話邏輯，調(diào)對緩存能便宜90%。

緩存命中 vs 未命中：一場90%成本的差距

每次調(diào)用Claude API，系統(tǒng)會檢查你的提示前綴是否處理過。命中：便宜10倍，快85%。未命中：原價，原速。

這個「前綴」不是隨便什么開頭都行。必須是完全一致的token序列，從第一個字符到最后一個空格，差一個標點都算miss。Anthropic內(nèi)部管這叫「KV緩存」——模型預填充階段算好的鍵值張量，存下來復用，避免每次從零開始。

他們的團隊口號是「Cache Rules Everything Around Me」。玩的是Wu-Tang Clan的梗，把「Cash」換成「KV tensors」。能量一樣，貨幣不同。無視這條的代價也一樣：掏錢。

但問題是，大多數(shù)開發(fā)者根本不知道自己在用緩存，更不知道自己的寫法正在親手打破它。

你的提示是怎么被「肢解」的

每次調(diào)用Claude，提示由四層堆疊而成：

第一層：系統(tǒng)提示（system prompt），通常幾千token，定義角色和能力邊界。第二層：工具定義（tool definitions），每個工具的描述、參數(shù)、返回值格式。第三層：多輪對話歷史，用戶和助手的往返記錄。第四層：當前用戶輸入。

沒有緩存時，Claude像條金魚——每次都要把整本書從頭讀起。8000token的系統(tǒng)提示？重算。15個工具定義？重算。前面40輪對話？全部歸零。

緩存的機制是：把前N個token的KV張量存起來，下次只要前綴匹配，直接從斷點續(xù)傳。這個N在Anthropic的文檔里寫得清楚，但很多人沒讀，或者讀了沒懂。

我的Convex項目是個典型案例。6000token系統(tǒng)提示，12個工具定義（Clerk認證、Supabase查詢、幾個自定義動作），典型對話15-20輪。調(diào)通緩存后，20輪對話的成本對比是：9倍差距。1000次對話/天的話，1350美元/月 vs 150美元/月。

開發(fā)者正在犯的5種「緩存自殺」行為

第一種：動態(tài)時間戳。有人在系統(tǒng)提示里塞了「當前時間是{{timestamp}}」。每次調(diào)用都變，緩存永遠miss。解決方式是把時間塞進用戶消息的最后一層，別讓前綴沾上動態(tài)內(nèi)容。

第二種：隨機ID。調(diào)試時生成的request_id、trace_id，順手寫進系統(tǒng)提示。結果每次請求都是全新前綴。日志和提示分離，這是基本功。

第三種：工具定義亂序。Python字典的遍歷順序不保證穩(wěn)定，工具列表每次shuffle一下，緩存就失效。顯式排序，或者干脆用數(shù)組。

第四種：對話歷史截斷策略不一致。有時候截最后10輪，有時候按token數(shù)截，有時候保留系統(tǒng)消息但去掉用戶消息。截斷點一變，前綴就變。策略必須固定、可預測。

第五種：環(huán)境變量泄露。把NODE_ENV、DEBUG_MODE這種每次部署可能變的值寫進提示。開發(fā)和生產(chǎn)環(huán)境的分支差異，會讓同一套代碼在不同地方產(chǎn)生不同的緩存鍵。

這些錯誤我全犯過。最諷刺的是，你越是「嚴謹」地在提示里塞滿上下文，越容易把緩存打碎。

為什么Anthropic敢把這事公開

緩存命中率是基礎設施的脈搏，但他們選擇推特 casually 講出來，而不是藏進付費文檔。這本身就是個信號。

競爭對手也在做提示緩存。OpenAI有類似機制，Google的Gemini也有。但Anthropic是第一個把「我們內(nèi)部怎么監(jiān)控這事」抖出來的。這意味著兩層意思：一是他們已經(jīng)把緩存層做到足夠穩(wěn)定，不怕你知道；二是他們希望生態(tài)里的開發(fā)者別再用錯，否則整個平臺的成本結構都會被拖累。

一個冷知識：Claude Code的IDE集成里，每次你按Cmd+K或者讓AI改代碼，背后都是一連串API調(diào)用。如果緩存設計得當，這些調(diào)用的邊際成本趨近于零。設計不當，每次tab補全都在燒錢。

他們的團隊說，當緩存命中率掉的時候，「suddenly everyone cares about infrastructure」。平時沒人想看的監(jiān)控面板，那一刻成了全公司最熱鬧的頁面。這種文化很有意思——不是SLA驅動，是成本脈沖驅動。

怎么驗證你的緩存有沒有生效

API響應里有個字段叫cache_creation_input_tokens和cache_read_input_tokens。前者是首次寫入緩存的token數(shù)，后者是命中緩存復用的token數(shù)。理想情況下，后者應該遠大于前者，尤其是在對話進行中。

如果你看到cache_read_input_tokens始終是0，說明你的前綴設計有問題。常見原因：系統(tǒng)提示里有動態(tài)內(nèi)容，或者你的對話歷史拼接方式每次都在變。

另一個指標是latency。命中緩存的響應，首token時間（TTFT）會明顯快于未命中。Anthropic官方數(shù)據(jù)是85%加速，實際體驗中，大提示的差距更明顯。

我的建議是：先做一個最小復現(xiàn)。固定系統(tǒng)提示，固定工具定義，發(fā)10輪完全相同的用戶消息?？碿ache_read_input_tokens是否在第二輪開始增長。如果不增長，逐層排查哪一部分在抖動。

這件事的門檻在于，緩存是「全有或全無」的。前綴匹配度99%和0%的結果一樣：都算miss。沒有近似匹配，沒有模糊容錯。這種設計保證了速度，也放大了開發(fā)者的失誤成本。

Claude Code團隊把這事攤在臺面上，等于給整個行業(yè)遞了張紙條：提示工程的下一張考卷，考的是基礎設施思維。你準備好重新檢查自己的前綴設計了嗎？