AI Token 帳單診斷：四個問題定位成本失控源頭

季末檢討會上，主管把 AI 費用曲線投上螢幕，問這一季為什麼幾乎是上一季的兩倍，負責報告的人翻著明細，答不出數字是從哪裡長出來的。另一間會議室裡，提案需要編列 AI 功能上線後的每月維運預算，負責估價的人連從哪個單位起算都還沒有著落。還有一種更安靜的狀況：自動化流程上線三週，費用無感地往上爬，沒有人按錯東西，也沒有人多打了幾個字。（三個情境皆為示意改寫）

三種煩惱引發的直覺反應幾乎一樣：回頭刪字。把提示改短、限制回覆長度、要求模型講重點，一個月後再看費用，數字幾乎不動。直覺失效不是因為不夠勤勞，而是尺用錯了：模型計量的不是字數，而是分詞器切出的片段；文字用量主要由輸入、輸出、快取三種構成，而最大宗的輸入，常是沒有打進對話框的固定內容。拿字數管理成本，等於拿一把刻度不對的尺量東西，量得再仔細，結果都是錯的。

快速重點：Token 是模型把文字切分後的計量單位，不是字數；文字用量以輸入、輸出、快取三種計價為主，上下文視窗只是容量上限。沒打進對話框的固定輸入常是最大宗，先量測，再依成本來源對症節流。

三個誤解，讓刪字直覺救不了帳單

三個場景背後，通常各站著一個誤解。第一個誤解把 token 當字數，以為兩千字就是兩千顆，一張換算表就能走天下。第二個誤解以為帳單只算自己打的字，沒注意到系統提示、檢索資料與工具回傳的內容，每一輪都跟著計費。第三個誤解以為單價低的模型一定便宜，忽略同一段工作在不同模型的切分顆數、輸出長度都不相同。三個誤解錯在同一個地方：把一個不按字數運作的計量系統，硬套上字數的直覺。

把源頭整理成一個可以帶著走的組織概念：三種用量，一道容量上限。輸入是送進模型的一切，輸出是模型生成的一切，快取是命中重複前綴時的折扣用量；上下文視窗限制單次請求能容納多少內容。用量進帳單，容量定上限，兩件事從頭到尾不能混在一起。費用翻倍要在檢討會上解釋、提案要編維運成本、流程費用無感膨脹，三種問題都能在這個框架裡找到自己的位置。

診斷路線跟著定下來：先懂切分機制與跨模型差異，再判讀帳單上的用量欄位，把隱形輸入逐一翻出來量測，依成本來源分流處理，上線前用成本與品質雙指標驗收。過程裡有兩份背景知識可以隨時對照：訂閱制服務怎麼把用量包進配額，可以看各種 AI 服務的訂閱與計費形態；模型的原理與極限，先讀LLM 的能力邊界再回頭看帳單，視角會更完整。

標題裡的「四個問題」不是修辭，是可以對著帳單照著問的檢核清單，會在判讀用量的小節具體兌現。先把承諾講在前面：接下來給的是可以照做的判斷流程，不是固定的省費倍數；每個節省主張都掛量測條件，依模型、命中率與品質要求而異，量得出來的才作數。

模型讀的不是字，是分詞器切出的片段

模型處理文字的第一站不是語意，是一個叫分詞器（tokenizer）的元件。你送出的原始文字會先被切成一串片段，每個片段對照詞表換成一個編號，模型實際運算的是這串編號，不是字。切分的依據是訓練語料裡的統計：常一起出現的字元組合被併成一顆 token，罕見的組合被拆得更碎。單位的選擇本身是一個折衷：用字元切，序列長得驚人，語意也碎；用整詞收，詞表裝不下新詞、錯字與罕用字；折衷後的子詞方案讓詞表大小可控，同時保住處理沒見過內容的能力。

切出來的片段邊界，跟人心裡的字詞邊界經常對不齊。你認為語意完整的一個詞，可能被切成兩三顆；你覺得該分開的幾個字，卻可能黏成一顆。同一段文字換到另一個模型，顆數又不一樣。這個落差是所有估算誤差的源頭，也是數字數抓不準成本的機制起點。

官方文件對切分不固定這件事說得很直接。OpenAI 在token 與計數的官方說明裡寫明：一顆 token 可能是一個字元、一個詞的一部分，也可能是一個完整的詞；對英文的粗估（一顆約四個字元）不能直接套用到其他語言，也不涵蓋完整 API 請求裡的訊息包裝與工具定義等額外內容。任何沒標明來源與模型的「中文一個字等於幾顆」對照表，都應該先打上問號。

所以「中文是不是比較貴」這個問題，答案比想像中溫和：看模型。分詞器的世代與訓練語料決定多語效率，較新的詞表對繁體中文的覆蓋，通常比舊世代好；同一份文件在不同模型切出的顆數不同，沒有跨模型通用的換算率。與其糾結語言，不如拿目標模型的計數工具量一次。也不必為了省用量把提示硬翻成英文：翻譯會改變語境與細節，輸出品質的代價可能遠大於省下的輸入，先量測、再比較，才是安全順序。

各家把計數規則分開寫成文件，本身就說明差異存在。Google 在Gemini API 的 token 說明裡獨立描述自家的計數方式，與 OpenAI、Anthropic 的文件互不通用。想連模型演進一起理解，可以搭配Gemini 3 的完整介紹，看詞表與計量方式怎麼跟著世代調整。

實際的中文內容很少是純中文。一段行銷文案常混著英文品牌名、阿拉伯數字、百分比、網址與表情符號，這些內容怎麼切，完全依分詞器而定，不能假設某個數字或縮寫固定算一顆。該用數字與原文專有名詞的地方就準確使用，理由是避免歧義，不是省用量；真的要省，先刪重複背景與不必要的長參數，再用計數工具驗證。

分詞器工具還有一個用處：親眼看到邊界。部分官方工具用不同顏色標出每顆片段，把一段混著英文、數字與符號的中文貼進去，馬上看見哪些組合被合併、哪些被拆碎。顏色只代表該工具所屬模型的切法，看一個工具的畫面，推論不了另一個模型的用量。

帳單上的三種用量，與一道容量上限

帳單看不懂，多半是因為把它當成一個數字。拆開之後，文字用量進帳單的欄位是三個：輸入、輸出、快取，外加一個不進帳單、但會擋下請求的容量限制。三個欄位各自乘上費率再加總，就是多數計量服務對文字用量的計費骨架；骨架之外還有按次另計的加值項目，例如讓模型聯網查資料的搜尋工具，估總成本時要一併翻定價頁，才不會漏算。費率隨模型與時點變動，一律以官方定價頁為準，不引用固定倍數。

輸入涵蓋送進模型的一切：系統提示、使用者訊息、應用程式保留的對話歷史、檢索進來的資料片段、工具回傳的結果。它最容易被低估，因為介面上看得見的只有使用者訊息。許多模型的輸入單價低於輸出，但這不是通則，比較前要查定價頁；而在每輪重送完整歷史的實作裡，輸入會隨對話推進越滾越大。

輸出是模型生成的內容本體，部分推理模型還會把推理過程的用量計入或分開回報，估價時依官方欄位處理。輸出值得優先檢查，因為它常包含沒被用到的部分：重述問題、沒人要的解釋、超出需要的段落。輸出單價通常高於輸入，浪費在這裡的每一顆都更貴。

快取是三種用量裡最容易被忽略的一種，因為它分兩個狀態。寫入：把夠長的固定前綴放進快取，部分模型收取與一般輸入不同的寫入費；讀取：之後的請求命中相同前綴時，命中部分以折扣計算。Anthropic 在提示詞快取的官方文件列出快取前綴、最低長度、保留時間與寫入讀取的計價方式，並提醒效益應以使用的模型和實際命中率估算。快取不是固定折扣，是一樁要看命中率的生意。

↔ 左右捲動檢視完整表格

項目	涵蓋內容	與費用的關係
輸入	系統提示、訊息、保留歷史、檢索片段、工具結果	逐筆計費，每輪重送的內容會累積
輸出	回應本體，部分模型另計推理用量	逐筆計費，單價常高於輸入，依定價頁為準
快取	命中固定前綴的部分，分寫入與讀取兩種狀態	符合條件時的折扣用量，依命中率結算
上下文視窗	單次請求的容納上限	不直接計費，超載會擋下請求

上下文視窗是另一回事：它限制單次請求能容納的輸入加輸出，是容量，不是第四種費用。帳單上找不到「視窗費」這個欄位；超過上限的後果是請求被拒或內容被截斷，不是多付一筆錢。費用的入口始終是用量：塞得越滿，輸入用量越大，費用從這裡進來。把容量當費用管理，會去砍一個不存在的欄位；把用量當容量管理，會誤以為刪字能換空間。分清楚這兩件事，四個問題才有問的基礎。

下次打開帳單或 usage 報表，照這四個問題依序過一遍：

• 哪一種用量占大宗？輸入、輸出或快取寫入，分布不同，該下手的地方完全不同。
• 輸入裡固定重複的部分占多少？系統提示、規範與範例若每輪重送，那是第一個該處理的數字。
• 模型生成的內容有多少沒被用到？輸出單價高，浪費在這裡最可惜。
• 單次請求距離容量上限還有多遠？逼近上限代表下一輪可能被截斷，脈絡該瘦身了。

用量與容量分開看，四問才答得動。前三問找錢花在哪，第四問提醒空間還剩多少；一個管帳單，一個管請求送不送得出去。答完這四問，成本從哪裡來已經有輪廓，下一步是把沒看見的輸入逐一翻出來。

沒打進對話框，卻每輪都計費的三種隱形輸入

帳單上最大的驚奇，通常來自從沒出現在輸入框裡的內容。系統提示是第一種：在每輪自行重送完整訊息的 API 實作裡，那段角色設定、語氣規範、背景知識，每次呼叫都計入輸入；若使用供應商的狀態管理，計費與上下文處理依該服務規則而定。具體動作很樸素：把最常用的系統提示與背景資料分別丟進計數工具，量一次，記下顆數。這個數字就是每次呼叫的固定底薪，之後任何優化都要先跟它比對（顆數依實測，換模型要重量）。

範例是系統提示的近親，常被一起忽略。為了讓輸出穩定，很多流程會在提示裡放幾組示範輸入與輸出；這些範例跟著每一次呼叫重送，是固定底薪的一部分，而且篇幅通常比規則本身更長。值得定期做消去實驗：拿掉一組範例，看輸出品質有沒有掉。沒有掉的，就是一直在付錢卻沒在做事的內容；有掉的，才留下，並考慮用更短的範例達到同樣效果。範例的數量與長度，是可以管理的變數，不是背景雜訊。

工具定義是第二種。用 MCP 或 function calling 接上工具後，可用工具的名稱、說明與參數定義會成為模型輸入的一部分，每輪都在場；工具掛得越多、定義寫得越長，固定底薪越高。這層機制的完整說明可以看MCP 的運作方式。對策不是不接工具，而是依任務提供必要的那幾個，再從 usage 驗證拿掉之後的差異。

資料注入是第三種，而且是一個架構取捨。把整份參考資料直接放進上下文，做法單純，但每一輪全額計費；用RAG 檢索增強生成只取相關片段，輸入變小，但要計入檢索本身的成本：向量資料庫、排序運算，以及錯誤召回對回應品質的干擾。判斷標準是使用型態：同一批資料被反覆查詢、每次只用其中一小部分，檢索架構才有機會回本；資料量小、每次都要整份讀，直接放進上下文反而簡單。兩條路都要量輸入用量與召回品質再定案。

三種隱形輸入的共同點：都是固定或半固定的內容，都每輪計費，都不在眼裡。把它們各自量出來，固定底薪就從「感覺很多」變成具體數字；這個數字會在後面每一節出現，因為快取、路由、精簡，全都是在跟它打交道。

越用越貴的動態輸入：對話歷史、Agent 步數與圖片

對話歷史是會長大的輸入。應用程式每輪重送前文，輪次越多，輸入越長，費用隨對話深度往上疊；這不是模型變貴了，是同一份越來越長的內容被反覆計費。有效的處理是摘要壓縮：定期把先前的過程收斂成一段精華，下一輪帶摘要加新訊息，而不是全部歷史；已經用完的中間過程直接移出。工具呼叫的歷史結果尤其佔空間，能用結論替代就別留全文。壓縮前後要比對任務表現，確認必要資訊沒有被摘掉。

Agent 把同一件事乘上次數。多步流程每走一步，固定輸入就再計一次，步數一多，成本以乘法堆高；AI Agent 的運作方式決定了它天生比單次問答多這層開銷。控制要在部署前寫進程式碼，共三種：步數上限，跑滿固定步數就停，不管任務完成與否；中途摘要，每隔幾步壓縮前文，讓脈絡回復合理大小；預算斷路，給任務一個用量或金額上限，超過就中止回報。三種裡步數上限最單純，一個計數器就能上線，也最能擋住繞圈式的失控。

圖片遵循另一套計量規則。多數模型依解析度、細節設定與影像尺寸計算用量，不是一張圖一顆，也沒有跨模型通用的顆數可以引用；流程會反覆傳同一張圖時，先依官方計費說明測試降解析度與裁切，只保留任務看得清楚的部分，量測確認重要細節仍可辨識，再查證該模型是否支援影像快取。驗收標準是看得清楚，不是縮到最小。

送出前估、回應後核對，成本才會從憑感覺變成數字

看不見的東西管不動，計數工具把看不見變成看得見。OpenAI 開源的 tiktoken 套件可依支援的編碼估算文字用量；Anthropic 提供 count_tokens 端點，可在送出訊息前估算輸入，工具、圖片與文件等內容的支援範圍，依token counting 的端點文件核對；Google 則有 countTokens 方法與 AI Studio 的用量顯示。三家的工具都只估算自家模型，跨模型比較要分別量。

兩個習慣把工具變成制度。上線前估價：新功能動工前，先用計數工具量出典型輸入，乘上預估輸出長度與呼叫次數，得到月度概估，數字不必精確，用意是讓設計當下就看見這個流程的用量等級；上線後核對：把每次回應的 usage 寫進紀錄，欄位與串流回應的呈現方式依服務而異，核對實際的輸入、輸出與其他計費項目再入帳。累積下來，你會有自己的成本分布圖，知道錢落在哪些任務上，而不是憑印象猜。

估價與核對是一對：估價給設計期的判斷，核對給營運期的修正。兩個數字對不上的地方，就是流程跟設想不一樣的地方，例如實際輸出比預估長、檢索片段比抽樣大、某個任務的呼叫次數遠超預期。差異本身是資訊，不是誤差；把它回饋到下一次的估價，估算會越來越貼近自己的真實用量。

每百萬 token 單價為什麼選不出最省的模型

回到採購面的問題：兩個模型，一個每百萬 token 的單價低了四成，該選它嗎？單憑單價，答不了。同一份工作交給不同模型，公平比較有四個步驟：固定同一份任務，在各自模型分別計數，乘上各自的輸入與輸出費率，再比較總成本。切分顆數與輸出長度都是變數，單價的優勢常常在路上就被吃掉。

定價差異有機制原因：能力層級、推理成本、速度定位，都是費率的成分。便宜的模型可能需要更長的提示、更多輪修正才達到品質門檻，疊起來反而更貴；高階模型一次到位，總成本未必輸。這也是「選最便宜」不成策略的原因：單價是單一變數，任務完成度才是分母。

舉一個純示意的算式（欄位為虛擬，非任何實際模型報價）：模型甲單價低，但同一份文件切出較多顆、輸出也較長；模型乙單價高，顆數少、輸出短。輸入顆數乘輸入單價，加輸出顆數乘輸出單價，兩邊的總成本可能翻轉，方向依實際數字而定。結論只有一個：先量，再選。

成本從哪裡來，就往哪裡下手

省用量的手法很多，亂抓一個就上，常常白忙。選擇的依據是成本來源：帳單大宗來自重複的固定輸入，走提示詞快取；來自模型選擇，走路由分流；來自脈絡與輸出過長，走精簡；來自時效要求不高的批量工作，走批次。判斷順序是先看 usage 分布，再挑對應手法，每一項都用前後量測驗證，而不是聽說有效就套用。

↔ 左右捲動檢視完整表格

成本來源	對應手法	驗收指標
固定輸入每輪重送	提示詞快取	快取命中率、折扣後的輸入費用
簡單任務用了高階模型	模型路由	測試集正確率、任務總成本
脈絡與輸出過長	精簡輸入與輸出	前後 usage 對比、回應品質
大量非即時工作	批次處理	完成率、折扣後總成本

提示詞快取：讓重複的前綴不再逐輪全額計費

適用條件先看清楚再開。快取划算的場景，是高頻、重複、夠長的固定前綴：客服流程每次都帶同一份公司政策，程式助理每次都帶同一份專案規範。不划算的場景也明確：前綴常變、長度不足最低門檻、請求間隔超過保留期限，命中率低到攤不平寫入成本。寫入與讀取是兩種計費事件，費率依模型而定，先小規模測命中率，再決定要不要依賴它。

排序是讓快取命中的技術核心：固定前綴放前面，變動內容放後面，從第一顆就要完全一致，中間插入任何變動字元，都會讓後面全部失效。OpenAI 在提示詞快取的官方文件說明相同前綴的重用機制，並列出各模型不同的最低長度、寫入費率、保留期限與命中方式；依文件調整請求結構，比憑感覺調整有效。

精簡輸出：把規格寫成可驗收的邊界條件

輸出單價高的模型上，管輸出特別有效。手法是把要求寫成可驗收的邊界條件：只回 JSON、最多三點、每點一句話、不要重述問題。搭配結構化輸出（固定欄位、資料綱要），不只壓長度，後續程式也更好解析。指令的寫法可以對照Prompt 提示詞入門，輸出的打磨則與文案寫作技巧是同一種功夫：知道每個字在做事，才刪得掉不做事的字。

這件事有上限，要知道停在哪裡。節省幅度要以實際回應的 token 數比較，不能引用固定比例；限制下得太嚴，模型可能省略必要資訊，把成本問題換成品質問題。安全的做法是分階段收緊，每收一次就驗收一次，品質掉出門檻就退半步。

縮減脈絡：清掉不再需要的輸入

脈絡的清理不是一次性大掃除，是流程裡的固定動作。過期的背景資料、已經用完的工具結果、重複交代過的規則，都該在任務推進時移出或收斂成結論。清理的原則與寫作相同：留下的每段內容，都要對下一輪的判斷有貢獻；沒有貢獻的，就是純粹的費用。清理前後同樣比對品質與用量，兩個數字一起動才算數。

清理可以照一張固定清單走，不必每次重新想。逐項檢查四類內容：過期的背景資料，任務已經推進，舊版本還留在脈絡裡；重複交代的規則，同一個要求在系統提示與當輪訊息各出現一次；用完的工具結果，資料已經取回，原始回應還佔著位置；嘗試過的錯誤路線，除錯過程的痕跡對後續判斷多半沒有貢獻。四類各自對應一個處置：刪除、合併、換成結論、收進摘要。清單貼在流程旁邊，執行起來比原則容易。

模型路由與批次，把對的任務交給對的模型與對的時間

路由的前提是品質門檻，不是單價。做法是把真實任務整理成測試集，讓較小的模型先跑一輪，達標就採用，未達標就升級到更大的模型；中間不需要旗艦與輕量的二分，只有任務與門檻的對應。小模型的定位與限制可以從SLM 小型語言模型讀起，各家模型的位置則可以對照Claude 模型介紹、Claude Code 與 Cowork 的使用情境，以及GPT-5.6 的定位，用同一份測試集去問，而不是用品牌印象去猜。

批次改變的是時間，不是內容。OpenAI 在Batch API 的官方文件列出三個條件：非同步處理、二十四小時內完成的服務窗口、相較同步 API 的折扣。流程是提交批次、等待處理、依識別碼把結果對回、失敗的項目安排重試，不能假設輸出順序等於輸入順序。

適用前提同樣明確：工作能接受等待、能容忍重試與配對處理，才走批次。報表彙整、大批內容改寫、定期清理這類任務符合條件；即時問答與互動介面就不適合。路由與批次的共同點是改架構而非改文字，一次設定長期生效，也因為這樣，上線前要驗得更勤。

月費與計量的分界，在於需不需要算出單位成本

訂閱與計量的分界，本質是一個問題：你需不需要算出單位成本。訂閱把用量包進月費與配額，支出可預測，但單位成本是糊的；API 按用量拆開計價，每一顆都看得見，代價是要自己估、自己管。把訂閱額度換算成「每完成一項任務的邊際成本」，與 API 報價放進同一個單位比較，兩邊的差距才有意義，而不是拿月費對帳單直接比大小。

三個訊號出現時，計量幾乎是必然的方向：要把 AI 接進產品，訂閱服務不能當產品後端；要批量處理，配額會先撞頂；要對成本歸因，只有拆開的用量數字能支撐定價與預測。訂閱額度與 API 額度是不同產品，不能互抵；混合使用是常態而非例外，日常構思走訂閱、正式流程走計量，各自的輪廓都更清楚。

↔ 左右捲動檢視完整表格

轉換訊號	計量之後才做得到的事
要接進產品或網站	程式化呼叫、快取、路由、用量上限
要批量處理大量任務	批次折扣、併發控制、失敗重試
要對成本歸因與編預算	任務級用量紀錄、部門分攤、預估模型

以一個內容團隊的估算為例（數字為示意）：每月固定產出一批文案與摘要任務，先用計數工具量出單次任務的典型輸入與輸出，乘上月任務量，得到計量制的月成本概估，再與訂閱方案能覆蓋的任務量放同一張表比較。AI 內容產製的成本與投報，應該納入內容行銷策略的整體評估，而不是只看單月發票。結論掛在用量型態上：任務量大而穩定的團隊，與用量零星的個人，答案經常不同。

成本與品質一起過關，優化才算數

優化做完不算完成，要過三關才算。第一關是品質：用固定的測試集跑分，正確率或召回率不能低於改動前的水準。第二關是成本：比對前後的 usage 分布，確認節省真的發生在預期的欄位。第三關是保險：預算上限與用量警報就位，萬一判斷錯了，有斷路器擋住。三關都過，改動才推上線。

把成本與品質放在同一張驗收單上，是因為兩者會互相偽裝。過度壓縮脈絡，費用下降，必要資訊也跟著消失；放任輸出膨脹，品質看起來豐富，帳單卻在墊底。單看任何一邊，都可能把受損誤讀成進步，雙指標同時過關，優化才成立。

保險要在部署前寫進流程，事後補救的代價總是更高。預算閘、警報、Agent 的步數與預算上限，都屬於上線前花十分鐘設定、省下事後數天排查的投資；把這類控制放進命令列工作流的做法，可以參考Claude Code 的使用教學。

收尾的動作，是把量測結果寫成團隊可重用的紀錄：任務類型、用量分布、品質分數三欄，每個專案結束時更新。下一個專案開始時，這份紀錄就是現成的估價基準與門檻參考，不必從零再猜一次。

警報的門檻也有講究。設得太鬆，等到通知時費用已經跑遠；設得太緊，每天都收到無關緊要的訊息，久了沒人再看。務實的起點是用第一個月的實際用量當基準，把警報放在基準的某個倍數上（倍數依任務波動程度決定），第二個月再依實際情況調整。門檻本身也是量測的產物，不是拍出來的數字。

Token 是成本語言，不是 SEO 分數

觀念用到搜尋與內容上，界線要先畫。Google 在AI 搜尋的官方說明裡的立場是：AI 功能仍以既有的技術條件與對讀者有用的內容為基礎，沒有要求網站提供任何 token 相關的分數或額外標記。也就是說，token 效率不是排名因素，也不存在需要供應的信號；把它寫進 SEO 檢查表，是在對一個不存在的欄位做事。

這直接否定了一種流傳的建議：為了省 token 而寫短、為了模型好讀而改寫。精簡的價值在讀者與維護，不在隱形分數。想讓內容被看見，路徑是老老實實的那幾條：補上別人沒寫過的資訊增量；讓結構化資料與頁面可見內容一致；經營LLMO時把可索引與可靠來源放在前面。這些課題的共同點是以內容與證據為本，token 在其中沒有座位。

想觀測 AI 搜尋帶來的變化，從AI Overviews的呈現邏輯看起；想把被點名當目標，則參考讓品牌被 AI 回答引用的做法。這兩條路的成效都取決於內容品質與證據密度，跟頁面用了多少顆片段無關。

回到開場的三個場景，各自有一個當天就能做的動作。要在檢討會上解釋費用的，先把輸入、輸出、快取三個數字各自占多少列出來，答案通常就在最大那個欄位裡。要編維運預算的，先量出每次呼叫的固定底薪，乘上預估次數，估價就有了骨架。流程費用無感膨脹的，先給它加上步數與預算上限，膨脹至少有邊界。

成本可控之後，值得把心力放回模型拿不走的東西：領域知識、判斷力，以及把兩者跟工具串起來的新工作模式，例如vibe coding。往後的營運節奏可以很樸素：估，送，核對，修正。每個循環都讓下一次的估更準，帳單從需要解釋的東西，慢慢變成只是反映用量的報表。