如果你最近在用 AI 做 長對話 、 多輪對話 ，很可能已經遇過這種情況： 前面聊幾輪都還好，後面明明每次只多打一小句， AI Token 卻開始越扣越快 。很多人第一次遇到這種狀況時，直覺都會以為是不是平台算錯、模型突然變貴，或是自己不小心開了什麼額外功能。 但大多數時候，真正的原因其實比較單純： 不是你最新那一句特別貴，而是模型每一輪都在重新讀越來越長的上下文。 這篇文章的重點不是廣義地講「AI Token 為什麼會扣很快」，也不是教你怎麼看後台數字，而是專門回答一個很明確的問題： 為什麼長對話會讓 AI Token 越聊越貴？ 先講最核心的答案： 長對話越到後面越花錢，通常不是因為你後面那一句比較長，而是因為每一輪都把更多前面的對話、規則、工具內容和背景資料一起送回模型。 長對話為什麼會讓 Token 越扣越快？ 最簡單的理解方式就是： 你看到的是新增一句，模型看到的是整段對話。 在多輪對話裡，模型如果要理解你現在這一句話，通常不會只看你剛剛新增的那幾個字，而是要連同前面幾輪內容一起看。OpenAI 的 conversation state

很多人在開始用 AI API 之後，都會冒出同一個問題： 我自己寫的 system prompt、system instructions，會不會也被算進 token？ 答案先講在前面： 通常會。 只要那段內容是你在 request 裡一起送進模型的，不管它叫 system prompt、system instructions、developer instructions，原則上都屬於輸入端的一部分，會影響 input token、上下文長度，通常也會影響費用 。這正是你原稿裡最核心的重點。 如果你現在會搜尋這題，通常不是想知道抽象定義，而是想搞清楚三件事： 系統提示詞會不會吃 input token 系統提示詞會不會影響成本 系統提示詞太長會不會讓上下文很快爆掉 這篇就是直接回答這三個問題，而且會盡量用最白話的方式講清楚。 先講最白話的版本 你可以把一個 API request 想成一包送進模型的資料。 只要是這一包裡的內容，通常都會被模型讀到，也就通常會被算進 input side。 這包含： 你寫的 system prompt / syste

如果你現在正在查「 1000 字文章大概會用多少 AI Token 」，通常你真正想知道的不是抽象定義，而是很實際的事：我要寫一篇文章、叫 AI 產一篇文章，或估一篇文章的 API 成本時，到底該抓多少 Token 才合理。 先講最直接的答案： 如果你說的是 1000 個中文字符的文章，實務上通常可以先抓大約 800 到 1,200 Tokens。如果你說的是 1000 個英文單字，通常可以先抓大約 1,300 到 1,400 Tokens。 但這不是固定公式，而是 實務估算區間 。因為 OpenAI 官方明確說明，Token 不是直接等於字數，而且 非英文文本通常會有更高的 token-to-character ratio ；Gemini 官方也說，Gemini 模型以 Token 作為處理粒度，1 Token 約等於 4 個字元這件事，本質上只是粗略近似，不是每種語言都能直接套用。 所以這篇不是要把你帶去背死公式，而是直接幫你回答搜尋意圖最前面的問題： 1000 字文章，大概要抓多少 Token 才不會估太離譜？ 先講最重要的差別：你說的 1

很多人在找便宜的 AI Token 方案時，第一眼只看「每百萬 Token 幾美元」。這樣看很快，但也最容易看錯。因為現在主流平台的價格，不只分 input 和 output，還常常另外有 cached input、Batch、搜尋、Grounding、快取儲存、工具呼叫，甚至區域或模式加價。 OpenAI 官方價格頁就把 input、cached input、output、Web search、Batch API、Regional Processing 等項目分開列出；Gemini 的官方 pricing 頁也把 input、output、context caching、storage、Grounding with Google Search / Maps、Batch API 分開列價。 所以，真正比較實用的結論是： 便宜方案不是先看誰最便宜，而是先看你的用途，再看該平台怎麼計價。  如果你做的是高頻、簡單、可批次的任務，低價模型加上 Batch 或快取，通常才是真正省；如果你做的是長上下文、搜尋型助理、工具型 Agent，那最後把帳單拉高的，