本文為《AI 輔助維運工程:從 Claude Code 機制到企業落地》系列第 5 篇。系列前半部講機制(Claude Code 怎麼運作、Agent Loop 怎麼跑、Context 怎麼管理、Sub-agent 怎麼分工、Agent Team 怎麼治理),這一篇開始進入後半部——你站在使用者或主管的角度,要做哪些實際決策。第一個決策就是關於錢。

當帳單比你預期的高出五倍

我想先請你想像一個場景。

一位工程師最近迷上 Claude Code。他每天早上打開,下午處理幾個 ticket,晚上偶爾還會用它整理週報。感覺很滿意,生產力明顯提升。月初收到 API 帳單的時候,他愣了一下——比他預期的高出大約五倍。

他不相信。回頭去看使用紀錄,確認沒有異常的大量呼叫、沒有惡意濫用、也沒有帳號被盜用的跡象。每天該做的事他都記得,那些事情理論上不該產生這麼多 token 消耗。但帳單就是擺在那裡。

這個情境是很多 Claude Code 新使用者的共同經驗。如果你也遇過、或擔心自己會遇到、或身為主管在審視團隊 AI 採購預算時心裡有這種疑慮——這篇文章就是為你寫的。

我會先花點時間建立「token 經濟學」的基礎觀念,然後解釋為什麼你以為自己理解的成本模型,其實跟實際發生的事情有出入。再來談 Prompt Cache 這個我自己一開始也忽略的助手、Claude Code 暗中在幫你省錢的各種設計、以及你自己能主動做的節省策略。讀完之後,我希望你能對著帳單,比較容易指出每一塊錢花在哪、哪些可以減少、哪些不能省。

先回到最基本:Token 是什麼,為什麼按這個計費

很多人聽過 token 這個詞,但沒真的弄清楚它是什麼。這裡花一點時間講清楚,因為後面所有的計算都建立在這個基礎上。

Token 是大語言模型用來處理文字的基本單位。你可以把它想成「字」,但不完全等於中文的一個字、也不完全等於英文的一個單字。實際上它比較像字元片段——一個常見的英文單字(例如 “the”)是一個 token,一個較長的單字可能被拆成兩三個 token,中文的一個字大約是一到兩個 token。

給你一個粗略的換算:一個中文字大約是 1 到 2 個 token,一個英文單字平均是 0.75 個 token。一頁 A4 中文文件大約包含 2000 到 3000 個 token。一篇 3000 字的文章大約是 4000 到 6000 個 token。這樣你看到「一百萬 tokens」的時候,大概能感覺出那是什麼規模——相當於一本中等厚度的書。

那為什麼 Anthropic 按 token 計費,不按「問幾個問題」或「用多少分鐘」計費?答案很實務:token 是模型內部處理工作的真實計量單位。不論你用什麼問題、花多少時間,模型做的事情本質上就是處理一串 token、產生另一串 token。按 token 計費是最公平、最接近成本真相的方式。

這裡有一個地方很多人沒注意:input token 和 output token 價格不一樣,output 通常比 input 貴好幾倍。以 Claude Sonnet 4.6 為例(這是寫這篇時 2026 年第二季的公開定價,請以 Anthropic 官網最新資訊為準),input 大約是每百萬 token 三美元,output 大約是每百萬 token 十五美元——差了五倍。為什麼?因為 output 的生成過程比讀取 input 更耗運算資源,模型要一個 token 一個 token 地「決定」輸出什麼,這比「理解」輸入要費力。

意識到 input 和 output 的價差之後,你對某些現象會有不一樣的解讀。例如「讓模型寫一大段詳細回答」這件事,其實比「讓模型讀一大段詳細資料後簡短回答」貴得多。寫長比讀長貴,這是一個直覺上不明顯、但帳單上很明顯的事實。

打破一個容易踩到的誤解:你不是在「用多少回多少錢」

OK,基礎打好了。現在講這篇最重要的一個觀念。

大多數人對 AI 計費的直覺是:我問一個問題、AI 回答我、這次花了某個 token 量。下次再問,又是一個新的計算。就像你打電話問客服,通話時間內收費,掛了電話就停。

這個直覺跟實際狀況不一樣。

實際的計費模型是這樣:每一次你按下 Enter,送到 Anthropic 的不只是你這次打的這句話,而是整段對話從第一句到現在的所有內容。系統 prompt、你之前問過的所有問題、AI 之前給過的所有回答、中間所有工具呼叫的結果——全部打包一起送。這些全部都算 input token,全部都要付費。

讓我重新說一次,因為這是理解 token 成本的關鍵樞紐:你不是在為「最近這一句」付費,你是在為「整段對話歷史」付費,而且每一輪都要重新付一次。

你可能會問:為什麼要這樣?模型不能記得我們之前聊過什麼嗎?答案是——不能。模型本身沒有記憶。每次 API 呼叫都是獨立的,模型看到什麼、就知道什麼。如果要讓它「記得」之前的對話,唯一的方法就是把之前的對話再送一次給它看。這是 LLM 運作的本質,不是 Anthropic 的設計選擇。

有了這個認知,你回頭看很多之前不理解的現象,突然都通了。

為什麼長 session 越跑越貴?因為每一輪要傳的對話歷史越來越長。前 5 輪對話可能只有 2000 token,跑到第 50 輪可能已經 30000 token,每一次新對話都要把這 30000 token 重送一次。這不是線性增長,是累積放大。

為什麼讀了一個 500 行的 log 檔之後,接下來每一輪都感覺變貴?因為那 500 行已經進入 context,變成對話歷史的一部分,每一次都要重傳。

為什麼清掉 context 或 /compact 之後會明顯感覺「變快變便宜」?因為你釋放了重傳的負擔,後面每一輪都少付那些釋放掉的 token。

這就是為什麼那位月底看到五倍帳單的工程師,沒找到任何「異常」的呼叫。他的使用沒問題,但他累積了幾個超長 session,每個 session 都把大量歷史重複傳了幾十次。五倍的帳單沒有兇手,有的只是一個被誤解的成本模型。

你的好朋友:Prompt Cache

講完壞消息,講個好消息。Anthropic 知道「每輪都重傳整段歷史」這件事很貴,所以他們提供了一個機制叫 Prompt Cache,本質上就是讓你不用每次都全額付費。

我用一個比喻讓你抓住這個機制的精神。

想像你是一家餐廳的熟客。你每次來都會點「招牌前菜套餐」這個東西——同樣的內容、同樣的作法、同樣的份量。廚師每次都要從頭備料、煎烤、擺盤、送上桌。成本很高。某天餐廳老闆跟你說:「這樣吧,你既然每次都點這個,我們幫你做個預備制度——你多付一點錢,我們會把你常點的內容預先準備好,放在保溫區,你下次來直接取,只要付一小部分錢。」

這個「預備制度」就是 Prompt Cache。

具體怎麼運作?當 Anthropic 看到你在一段時間內反覆用完全相同的前綴發起對話,它會把這個前綴「暫存」起來。下次你再用同一個前綴,Anthropic 不需要重新處理這段內容,而是從暫存直接讀取。你付的不是一般的 input 價格,而是 cache read 的價格,大約是一般 input 的十分之一。

十分之一的意思是:如果你的對話歷史已經累積到 30000 token,一般來說這一輪要付 30000 個 input token 的費用。但如果前 29000 個 token 能命中 cache,你只要付 29000 個 cache read token + 1000 個一般 input token。整體費用大約省 85% 以上。

這個機制對 Claude Code 這種「每輪都會重傳一堆歷史」的使用模式,幫助非常大。事實上,Claude Code 裡面不少工程設計都考慮了怎麼讓 cache 命中率最大化。

還記得第四篇上集講的 Fork sub-agent 機制嗎?那段「為什麼所有分身的 API request prefix 要 byte-identical」的長篇大論,從省 token 的角度重新看,意思就是:讓所有分身共用同一份 cache。十個分身平行跑,如果每個分身都要重新付一次 context 的錢,成本會爆炸。但因為 prefix 一致,後九個分身只要付 cache read 價格。這不只是技術漂亮,這是實實在在省下來的錢。

Prompt Cache 有一個重要但不直觀的限制:快取會過期。如果你在一段時間(通常是五分鐘)內沒有新的請求觸及這個 cache,它會被清掉。下次再用就要重新建立。這意味著如果你經常「開 Claude Code 問一個問題、關掉、過十分鐘再來」,你的 cache 命中率會很低。但如果你是連續密集使用,cache 幾乎一直維持在命中狀態,帳單會漂亮很多。

作為使用者,你基本上不用手動設定 cache,Claude Code 會自動幫你管理。你要做的只是理解 cache 存在、相信它在工作、不要做破壞它的事。

那什麼事會破壞 cache?

這個問題值得一段獨立的討論,因為了解這個,你才知道為什麼有些操作看起來沒什麼、但對你的錢包很不友善。

Cache 的命中條件是「前綴完全 byte-identical」。這個「完全一致」非常嚴格——差一個空白字元、差一個標點符號、差一個 message 順序,cache 就 miss,整個前綴要重新付費。

以下這些行為會讓 cache miss,請小心:

修改 CLAUDE.md 或 @import 的檔案。這些內容會被當成對話的一部分放進 context 前端。你改了一行文字,整個前綴就變了,所有之前累積的 cache 失效。這不代表你不該修改 CLAUDE.md,但它意味著「每次修改都會付一次 cache 重建的錢」——如果你發現自己一天改 CLAUDE.md 十幾次,這個習慣該改了。

切換不同的 MCP servers。MCP servers 的 tool description 會進入 system prompt。你切換啟用的 MCP 組合,system prompt 就變了,cache 失效。這是為什麼建議「一個專案穩定使用一組 MCP,不要頻繁切換」。

修改模型設定。如果你用 /model 切換 Claude 模型,前後兩個模型看到的 prompt 結構可能不同,cache 也可能失效。這不是經常會做的事,但知道有這個成本就好。

反過來,以下事情不會破壞 cache:

你問新的問題——這只是在對話末端追加內容,前端沒變,cache 仍然命中。

工具呼叫並拿回結果——這也是在末端追加,前端維持,cache 仍然工作。

Claude Code 做自動 context 壓縮(snip compact、micro compact 等)——這些壓縮會重寫某些訊息,理論上會影響 cache,但 Claude Code 設計時會盡量減少 cache miss。在某些情況下,壓縮的確會造成 cache 失效,但這個「失效的痛」通常遠小於「不壓縮讓 context 繼續膨脹」的痛。

這裡有一個微妙的、但值得你內化的心態:不要為了保護 cache 而不做對的事。壓縮會讓 cache miss、但可能救你下半天的 session;重寫 CLAUDE.md 會讓 cache miss、但可能讓未來一百次互動都更精準。短期的 cache 失效常常換來長期的效率提升,不要因為「怕 miss」就綁手綁腳。

Claude Code 暗中在幫你省的其他錢

除了 Prompt Cache 這個機制之外,Claude Code 還做了許多你可能沒察覺的、自動化的省錢設計。這些設計合起來,讓整個工具比你想像的精打細算。

Sub-agent 省略無關資料。第四篇上集提過 Explore 這類唯讀搜尋 agent,它們在執行時會自動省略 CLAUDE.md、省略 git status 等主 agent 本來會載入的內容。從使用者的角度這是「分身看不到某些資訊」,從成本角度這是「你不用為分身用不到的資訊付錢」。當 Claude Code 派出一百個 Explore 分身做平行搜尋,每個分身都省掉了這些多餘的輸入,整體省下的 token 量是驚人的。

Tool result 的自動截斷。當某個工具產生非常大的輸出(例如讀了一個 80MB 的 log 檔),Claude Code 會自動判斷並截斷,只把摘要放進 context、原始內容寫到磁碟。這個機制防止「一個 tool call 就把你的 context 炸掉」,同時也保護你的錢包——如果 80MB 內容全進 context,之後每一輪都要重傳。

四層 context 壓縮管線。第三篇整篇講的那套壓縮系統,從省錢角度重看就是「在對話歷史無限膨脹之前,不斷裁剪」。每裁剪 10000 token,之後每輪省 10000 token 的重傳費。這些小錢累積起來很可觀。

Output thinking 的條件啟用。Claude 的某些模型有 extended thinking 能力,會在回答前做內部推理。這個推理是 output token,而 output token 是 input token 的五倍貴。Claude Code 在某些 sub-agent 模式下預設關閉 thinking,就是在控制這個高成本項目。你不需要每個搜尋任務都伴隨 10000 token 的深度思考——適合思考的時候啟用,不適合的時候就關掉。

這些設計合起來的效果是什麼?Claude Code 本身就是一個內建了成本意識的系統。它不需要你手動優化每一件事情,很多優化在你不察覺的情況下就發生了。你的任務不是當微觀管理者,而是了解這些機制存在,然後不做違背這些機制精神的事。

你能做的:三層節省策略

儘管 Claude Code 已經幫你做了很多自動優化,你仍然有主動能做的事。這些事分成三個層次,影響力由淺到深。

第一層:設定層

這一層是你做一次、受益長期的事情。

精簡你的 CLAUDE.md。這是我覺得比較容易見效的一件事。有些工程師把 CLAUDE.md 寫成十幾頁的長篇大論——什麼團隊規範、專案歷史、程式碼風格、所有可能的邊界條件、過去踩過的雷——全部塞進去。這會造成一個問題:你每一輪對話,都在付這十幾頁文字的 input token 費用。

想像你用這個專案一天跑五十輪對話,每輪都要重傳這十幾頁。一年下來這個「常駐稅」會是驚人的數字。解決方法是:CLAUDE.md 只寫真正每次對話都需要的核心規則,其他詳細資料放在另一個檔案,當需要時才用 @import 載入。這樣平時不需要用那些細節,就不付費;需要時才付一次。

這個優化以我自己的經驗,往往能讓單輪成本明顯下降。是我覺得比較容易先試的事。

選擇性啟用 MCP servers。每個啟用的 MCP server 都會把它的 tool descriptions 放進 system prompt。如果你一次啟用十個 MCP servers,而這個專案其實只用到其中兩個,你在為八個沒用到的 server 付常駐稅。

處理方式是:每個專案只啟用這個專案真正會用到的 MCP servers。不同專案有不同的 MCP 組合沒關係,但每個專案的 MCP 集合要精準,不要貪心。

@import 要節制使用。@import 機制很方便——你可以讓 CLAUDE.md 引用其他檔案的內容,讓模型看到完整資料。但每次 @import 的檔案內容都會變成對話的一部分,每輪都重傳。用 @import 前問自己:「這個內容真的每次對話都需要嗎?」如果答案是「只有某些時候需要」,那就不該用 @import,而是在那些特定時候手動載入。

第二層:使用層

這一層是你在每個 session 中、每天都可以做的決定。

主動 /compact,不要等自動觸發。第三篇我們談過這點,這裡從省錢角度再看一次。自動壓縮在 context 用到 83.5% 左右才觸發,意思是前 83.5% 的膨脹成本你已經付完了。如果你在完成一個子任務後主動 /compact,你可能在 30% 或 40% 就清掉多餘內容,省下 50% 以上的後續重傳費用。

主動壓縮是這個系列反覆強調的好習慣,從成本角度看,它直接翻譯成金錢。

切 session 而不硬撐。長 session 有一個「cumulative cost」的效應——到越後面,每一輪都越貴。當你發現任務其實已經換軌(例如從 debug 某個問題切到寫下週簡報),停下當前 session、開新的更便宜。不要想「我還有 context 可以用,多撐一下」,那個 context 每用一輪都在吸你的錢。

善用唯讀 sub-agent。當你讓 Claude Code 做「探索性」任務(搜尋、盤點、比對),明確引導它先派 Explore 分身。因為 Explore 省略了很多主 agent 的常駐內容,平行執行還共用 cache,整體成本遠低於主 agent 親自處理每一件事。你可以直接說「先派探索分身掃一遍」或「平行查一下這幾個」,Claude Code 會懂。

第三層:架構層

這一層是最深的,影響最大,也需要你花時間設計。

Agent Team 設計本身就是一種省錢。還記得第四篇下集講的角色分工嗎?從治理角度它的價值是紀律,從省錢角度它的價值是切割長 session。每次角色切換都是一個天然的 session 斷點——spec-writer 完成規格後,交接給 implementer,implementer 不需要繼承 spec-writer 的完整對話,只需要讀 PROJECT_STATUS.md 和 spec 檔案。這相當於強制的 context 重置,每個角色的 session 都保持輕量。

如果你用一個長 session 從規格寫到實作寫到審查,你的對話歷史到最後可能累積十萬 token。同樣的工作用三個角色接力做,每個角色的 session 可能只有兩萬 token,總計六萬,比單一長 session 省了四成。

任務切割的邊界設計。每一個任務開始前,問一個問題:這個任務做完就能收尾,還是會自然延伸成其他任務? 如果是前者,這個任務就是一個 session 的好邊界——做完,結束,開新的。如果是後者,你要預先規劃中間的「checkpoint」,讓 session 可以在適當的地方切開。

跨 session 的狀態檔案是真正的省錢架構。把關鍵狀態寫進 PROJECT_STATUS.md、session-log.md、或任何你設計的狀態檔案,意思是「這些資訊不需要存在我的對話歷史裡」。我可以結束這個 session、明天開新的、讀一下狀態檔就能無縫接軌。狀態檔案是永久的(不消耗對話 token),對話歷史是暫時的(每輪都重傳、越傳越貴)。把重要資訊從對話搬到檔案,就是在把「持續性的 token 負擔」轉成「一次性的讀取成本」。

一個思考練習

我們停一下,做一個小練習,幫你內化到目前為止講的東西。

假設你今天要完成一個任務:用 Claude Code 盤點某個 codebase 裡所有使用了某個 deprecated API 的地方,然後逐一改掉,最後產出一份修改報告。這個任務你估計需要四小時。

請你花一分鐘,想一下:你會怎麼設計這個任務的進行方式,讓 token 成本最低?

(實際想一下再往下看。)

好,以下是一個我覺得合理的設計方式,你可以跟你的想法對照。

我會把這個任務切成三個階段,每個階段開新的 session:

**第一階段(探索):**開一個新的 session,明確請 Claude Code 派出 Explore 分身平行搜尋整個 codebase,找出所有使用該 deprecated API 的地方,產出一份清單。這個清單寫進一個 markdown 檔案。Explore 分身省略 CLAUDE.md,本身成本就低;平行執行共用 cache,更低。整段第一階段完成後,把清單檔案存好,結束這個 session。

**第二階段(修改):**開一個新的 session,讓 Claude Code 讀那份清單檔案,一個一個檔案修改。這個 session 是「implementer 角色」的工作模式,專注實作、不做規格決策。每修改完幾個檔案,就做一次 /compact 清掉過時的 tool results,保持 session 輕量。修改完所有檔案後,結束。

**第三階段(審查與報告):**再開一個新的 session,這次是「reviewer 角色」。讀修改清單、抽樣檢查改動、產出修改報告。審查分身不需要繼承前兩個 session 的完整對話歷史,只需要看最終產出和檔案 diff。

這個設計的精髓是什麼?三個短 session 比一個長 session 省得多。每個 session 都有明確的起始 context、做完就結束,不讓對話歷史無限累積。中間透過 markdown 檔案(清單、報告)接棒,避免把資訊留在易腐的對話裡。

同樣的工作,設計得當可以省下五到七成的 token 成本。這不是魔法,是工程紀律。

從「看帳單」到「有 token 意識」

講了這麼多,我希望你帶走的不是某個具體技巧,而是一種思考方式。

不少工程師在使用 AI 助理時,腦袋裡沒有 token 這個維度。他們想的是功能、是效率、是「能不能做到」。等月底帳單來了,才發現成本也是一個維度,而且是他們之前從來沒管理過的那種成本。

我自己偏好的使用方式,是讓「token 意識」成為背景思考的一部分。不是隨時在計算費用,而是當你在設計工作流、寫 CLAUDE.md、決定用哪個方案的時候,都自然會問一句:這個選擇對 token 消耗的影響是什麼?

這個意識一旦建立,你可能會自然做一些對的事——你如果寫出簡短精準的 CLAUDE.md,是因為你知道冗長會讓每輪都貴;你切 session,是因為你知道長 session 有 cumulative cost;你把狀態寫進檔案,是因為你知道對話是會腐敗的容器;你讓 Claude Code 派 sub-agent,是因為你知道這可能比主 agent 親自做還便宜。

這些行為合起來,讓你在同樣的工作量下,成本可能被控制在沒有這些意識的使用者的一定比例之下。長期下來,這個差距可能決定一個團隊是不是能永續地用 AI 輔助工作流。

最後一個問題:那,到底該付多少錢?

到目前為止,我談的都是「已經選定某個方案之後,如何在這個方案內省錢」。但有一個更上層的問題沒回答:你應該選哪個方案?

Anthropic 提供了四種不同的服務管道——個人 Pro、個人 MAX、團隊 Plan、Enterprise、API——每一種計費方式和權限差異都不同。選對方案本身就是最大的一次性節省,可能比後面所有的技術優化都更有影響。

更重要的是,方案的選擇還牽涉到一個很多人沒意識到的議題——你的對話資料會不會被用來訓練模型。不同方案在這件事上差異極大,而且個人版目前採用 opt-out 模式,意思是如果你沒去關掉那個設定,你的對話可能正在被拿去訓練。這個議題連同完整的方案選型比較,第 7 篇會專章處理。

但在那之前,還有一個更上游的問題必須先處理——你使用 Claude 不只一個入口。Claude Code、Claude.ai、API——同一個模型放在不同平台,在不同 SSDLC 階段擅長的事情不一樣。你在 SSDLC 的不同階段,該用哪個入口? 這不是方案選型,是流程對應工具的判斷。選對入口之後才談得上「選什麼方案」——各階段擅長的入口綜合起來,才是方案選型的主要輸入變數。

所以下一篇的主題就是:SSDLC 工具選擇——每個階段該用哪個 Claude 入口。接著第 7 篇再回到「方案選型」的問題。

本篇收尾

把這篇的核心觀念,用一段話總結如下。

Token 成本的真相,是你每一輪對話都在為「整段對話歷史」重新付費,不是只為最後一句話付費。這個模型讓長 session 的 cumulative cost 成為費用變貴的主因。理解這件事之後,所有的節省策略——精簡 CLAUDE.md、主動 /compact、切 session 而不硬撐、善用 sub-agent、用 Agent Team 切割任務——都有了共同的底層邏輯:減少每輪要重傳的歷史、不讓歷史無限膨脹、讓持久性的資訊留在檔案而不是對話。

Prompt Cache 是一個值得了解的機制,它讓「重傳歷史」的成本降到大約十分之一。Claude Code 本身做了大量的自動省錢設計(Fork sub-agent 共用 cache、Explore 省略無關內容、tool result 截斷、context 壓縮),你不需要微觀管理這些,只要不做違背它們精神的事就好。

最後,如果能讓「token 意識」成為你設計工作流時的背景思考,你用 AI 的總成本長期下來可能會跟沒有這些意識的人拉開不小的差距。

下一篇我們從「在一個方案內省錢」跳到更上游——「在 SSDLC 的不同階段,該用哪個 Claude 入口」。方案選型的問題還要再等一集。

本文作者:鄧景仁 (Scott Teng) | 資訊服務業 infra 工程師,專注於 Azure / Linux / 安全維運。如需討論可聯繫 st333117@gmail.com。

本系列所有內容為個人學習與實務心得整理,不代表任職機構立場。文中引用的 API 定價為 2026 年第二季的公開資訊,Anthropic 保留隨時調整權利,實際費用請以 Anthropic 官方網站為準。具體 Prompt Cache 行為與其他實作細節可能隨版本演進。

本文原刊於 https://eeit.github.io/ai-devops-blog/posts/05-token-economics/，作者：鄧景仁 (Scott Teng)。
授權條款：CC BY-NC 4.0 · 禁止商業使用；分享請署名並註明原文 URL。
商業授權請聯絡：st333117@gmail.com