AI Token 計算會把系統提示詞也算進去嗎？
- 1天前
- 讀畢需時 7 分鐘
很多人在開始用 AI API 之後，都會冒出同一個問題：我自己寫的 system prompt、system instructions，會不會也被算進 token？
答案先講在前面：通常會。只要那段內容是你在 request 裡一起送進模型的，不管它叫 system prompt、system instructions、developer instructions，原則上都屬於輸入端的一部分，會影響 input token、上下文長度，通常也會影響費用。這正是你原稿裡最核心的重點。
如果你現在會搜尋這題，通常不是想知道抽象定義，而是想搞清楚三件事：
系統提示詞會不會吃 input token
系統提示詞會不會影響成本
系統提示詞太長會不會讓上下文很快爆掉
這篇就是直接回答這三個問題，而且會盡量用最白話的方式講清楚。
先講最白話的版本
你可以把一個 API request 想成一包送進模型的資料。只要是這一包裡的內容，通常都會被模型讀到，也就通常會被算進 input side。
這包含：
你寫的 system prompt / system instructions
使用者問題
對話歷史
工具或函式定義
上傳的文件、圖片、PDF 內容
其他你主動帶進 request 的上下文
所以，系統提示詞到底算不算？
算。前提是那段 system prompt 是你自己放進 request 裡的。 這也是你在做成本估算時最該採用的原則。
為什麼 system prompt 通常會算進 token？
原因其實很簡單：因為模型不是只看使用者那一句問題，它會一起看你在 request 裡給它的整包資訊。
你可以把 system prompt 理解成「你先告訴模型的背景規則」。既然模型真的要讀這些規則，它就不可能完全不佔 token。這也是為什麼很多人明明使用者問題很短，後台 input token 卻還是很高，因為真正被送進模型的，不只是一句話，而是：
system prompt
歷史對話
工具定義
補充上下文
使用者當前問題
全部加起來才是那次 request 的 input。
很多人會搞混的地方：系統提示詞不是只有那一段「system」
很多新手以為只有標成 system 角色的那段文字，才叫系統提示詞成本。但實際上，你讓模型在一開始就知道的規則、角色、工具、格式要求，很多時候都會一起變成 input 負擔。
常見會一起吃 input token 的東西
例如：
品牌語氣說明
輸出 JSON schema
函式工具定義
安全限制
角色扮演設定
文件摘要規則
知識庫前綴說明
也就是說，不是只有使用者那一句問題才算。很多你覺得只是「先設定一下」的東西，實際上都可能在 token 計算裡面。
這也是為什麼正式產品或自動化流程做到後面，大家常常會開始研究：
怎麼縮短 system prompt
哪些規則可以抽掉
哪些內容值得快取
工具定義能不能更精簡
因為真正讓 input 變肥的，常常不是使用者，而是系統層本身。
那 system prompt 也會算進上下文限制嗎？
通常也會。
這不只是費用問題，也是 context window 問題。如果你的 system prompt 很長、工具描述很多、再加上對話歷史與文件片段，那你很快就會發現：明明使用者只問一句，整個 request 卻已經變得很重。
所以 system prompt 太長，後果通常不只是一點點成本增加，而是還可能讓你：
更快撞到 context limit
更難塞進長文件
更容易讓 output 空間被壓縮
更難做多輪對話
更容易讓長工具定義拖慢整體成本表現
對新手來說，最實用的理解方式就是：
system prompt 不只是要不要算錢，它還會吃掉模型能處理內容的空間。
那快取之後，系統提示詞還會算嗎？
會，但可能不是用一般 input 的算法來算。
如果平台有 caching，重複使用的系統提示詞或固定前綴，後續可能改以 cached input / cache read 的方式出現在 usage 裡。這也是你原稿裡提到的一個很重要的點：快取後不是「不算」，而是「還是算，但算法通常改變，而且常常比較省」。
這代表什麼？
如果你每次都用同一大段 system prompt，後台有時會看到：
一部分是正常 input
一部分是 cached input / cache read
有些平台還可能另外有 cache storage 成本
所以答案不是「快取後就不算」，而是：
快取後還是算，但通常比每次完整重送更省。
這也是為什麼固定規則、固定角色、固定背景的工作流，很值得研究 caching。
有沒有哪一種「系統內容」不算你錢？
這題很重要，因為很多人會在這裡誤會。
比較實用、也比較安全的做法是這樣理解：
你自己主動送進 request 的 system 內容
通常都先當成會算。這包含你自己寫的：
system prompt
developer instructions
tool schema
格式規則
安全規則
品牌規範
平台自己在背後加的內部最佳化 tokens
這類情況不一定會算在你的付費內容上。你原稿裡有提到一個很重要的細節：有些平台會在系統內部為了最佳化額外加入一些 tokens，但這種 provider-side 的系統最佳化 token，不一定會算在你真正被收費的內容裡。
對實務來說，最穩妥的判斷方式不是去猜平台背後加了什麼，而是直接用這個原則：
凡是你自己明確送進 request 的 system / instruction / tools / schema，都先當成會影響 input 成本與上下文。
這樣最不容易低估成本。
對成本最有影響的是哪一種 system prompt？
最容易讓成本膨脹的，通常不是一句短短的「你是一個助理」，而是以下這幾種：
很長的品牌規範
很詳細的格式與範例
大量工具 / 函式定義
長篇知識庫前綴
每次請求都重送的固定背景資料
這些東西的共同點是：它們看起來不像使用者內容，但其實每次都在吃 input。
所以很多團隊後來會發現，真正讓 input 變重的，不一定是使用者問題，而是自己設計的系統層太肥。
那後台要看哪個欄位，才知道 system prompt 有沒有算進去？
如果你要看使用量，重點通常是 input / prompt token 相關欄位。
對你來說，最實用的方法不是猜，而是直接做對照：
最簡單的檢查法
第一步，把目前的 system prompt 保留，先看一次 input token。
第二步，把 system prompt 拿掉或大幅縮短，再看一次 input token。
第三步，比較前後差值。
如果差很多，就代表你的 system prompt 本來就很吃 token。
這種檢查最適合用在哪裡？
你懷疑 system prompt 太長
你覺得使用者問題很短，但 input 卻很高
你準備把流程正式上線
你開始在意每月成本
你在做 prompt 改版前，想知道值不值得縮短
對新手來說，這比只看理論更有用。
因為你不是只知道「會算」，而是能直接知道「大概算了多少」。
一句話總結
AI Token 計算，通常會把你自己提供的系統提示詞算進去。
只要它是 request 的一部分，原則上就屬於 input side，會影響：
token 使用量
context window
通常也會影響費用
所以更實用的記法不是問「system prompt 算不算」，而是問：
這段內容是不是我主動送進模型的？如果是，就先當成會算。
這樣最不容易低估成本，也最不容易在上線後被 input token 嚇到。
FAQ
系統提示詞和使用者問題，哪個算 input？
兩個通常都算 input。只要它們都在 request 裡，模型都要一起讀。你原稿裡講得很清楚，system prompt、message input、tools 這些通常都屬於 input side。
工具 / function schema 也會算 token 嗎？
通常會。因為工具定義、函式描述、參數規則，本質上也是模型要讀的內容，不是免費背景。
快取之後 system prompt 就不算了嗎？
不是。快取之後通常還是算，只是可能改成 cached input / cache read 這種更省的計算方式。
為什麼使用者只問一句話，input 卻很高？
因為實際送進模型的通常不只那一句，還可能包含 system prompt、歷史對話、工具定義、知識片段等。
system prompt 會影響 context limit 嗎？
通常會。因為它本來就是模型要看的內容，所以會一起佔上下文空間。
最容易讓成本變高的是哪一種 system prompt？
通常是很長的品牌規範、很多範例、大量工具定義、長知識庫前綴、每次都重送的固定背景資料。
資料來源與可信度聲明
本文根據主流 AI 平台的 token counting、pricing 與 request 結構相關官方文件整理撰寫，重點參考 OpenAI、Anthropic 與 Gemini 對 input tokens、system instructions、tool definitions、cached tokens 與 prompt counting 的公開說明。內容以「request 結構 × input 成本 × context 影響」三個角度整理，目的不是只回答會不會算，而是幫讀者建立一套更不容易低估成本的理解方式。你原稿的方向是對的，我這版是把它整理成更完整、可直接上站的版本。
想更完整掌握這類內容的整理方向，可以回到 AI Token 看看。
本篇文章屬於《AI Token 計算》分類。
此分類主要整理 AI Token 的計算方式、輸入與輸出差異、字數換算、用量估算、system prompt 成本判讀與 API 計費邏輯，幫助新手在接觸 ChatGPT、Claude、Gemini 或其他 AI API 時，不只知道 token 怎麼算，也知道哪些內容會一起被算進 input。
留言