Skip to main content
「你們的 prompt 長度和 ChatGPT 不一樣,好像限了 32K」。這個 32K 不是 API易 加的,是 OpenAI Images API 的官方上限,而且按字元計不按 token。但真正值得討論的不是「能不能塞 32K」,而是該不該把 32K 資料原樣塞給圖片模型。本文講清上限從哪來、網頁版為什麼看起來沒有限制、長提示詞的兩筆賬,以及廣告圖這類「要求很多」的場景該怎麼組織提示詞。

客戶的問題:為什麼 API 限 32K,ChatGPT 不限

對話原樣(已脫敏):
客戶:你們的 prompt 長度和 ChatGPT 不一樣,好像限了 32K。 我們:是有限制的。誰會有 32K 輸入提示詞的出圖場景? 客戶:肯定有呀,廣告圖,包裝的尺寸……自己 call codex cli 算了。 我們:確認是 32000 個 tokens 的提示詞嗎? 客戶:是呀,32000 英文其實不長呀。
這幾句話裡混了三個概念,先拆開: 客戶說「32000 英文其實不長」,說的是字元數,這個判斷本身沒錯。但他拿來對比的 ChatGPT 網頁版,走的根本不是同一條鏈路。

32K 上限從哪來

OpenAI Images API 對 prompt 欄位的官方上限(/v1/images/generations/v1/images/edits 相同): 出處:OpenAI API 參考 developers.openai.com/api/reference/resources/images/methods/generate
API易 官轉鏈路不在這個上限之上再收緊。超過 32,000 字元由原廠返回 400,報錯原文以原廠為準,本頁未做逐位元組的邊界實測;要精確到哪一個字元開始報錯,用你自己的 Key 試一次即可,被拒的請求不計費。
字元不等於 token。計費和模型理解都按 token 走,usage.input_tokens_details.text_tokens 是每次呼叫實際消耗的文本 token 數。同樣 32,000 字元,英文約 8K tokens,中文因為每個字元對應的 token 更多,會明顯高於這個數,裝的資訊量也更大。所以「32K 英文不長」和「32K 中文很長」可以同時成立。

為什麼 ChatGPT 網頁版「沒有限制」

如何生成滿意的圖片內容安全排查篇 講的是同一件事:網頁版是 Agent,API 是單次原子呼叫
  • 在 ChatGPT 裡貼一份很長的資料,讀它的是對話模型,不是圖片模型。對話模型讀完後自己寫一條短的出圖提示詞去呼叫圖片工具,圖片模型拿到的從來不是那份原始資料。貼上超過 10,000 字元時網頁版還會自動轉成附件(OpenAI 幫助中心 help.openai.com),更說明那是給對話模型看的。
  • API 是你直接對圖片模型說話,中間沒有人替你讀資料、做取捨。上限是圖片模型這一層的上限,網頁版從來沒有讓圖片模型直面這個上限。
  • 客戶最後說「自己 call codex cli 算了」,這個直覺是對的:讓一個文本模型先讀資料,再產出出圖提示詞,正是網頁版在後臺做的事。下文把它寫成可以跑的兩段式。

長提示詞的兩筆賬

先算錢,再算效果。 :gpt-image 系列的文本輸入按 token 計費(gpt-image-2.5 為 $5.00 / 百萬 tokens,見 概覽定價表)。一條 32,000 英文字元的提示詞約 8K tokens,單次約 $0.04;中文 token 更多,費用更高。這個數單看不大,量產要乘張數,而且每一次重試都會再付一遍。提示詞裡 90% 是原始資料而不是畫面描述時,這筆錢大部分是白花的。 效果:更多細節不等於更高遵循度。幾百條要求同時擺在圖片模型面前時會互相競爭,真正重要的硬約束(Logo 不變形、包裝文字準確、人物數量)反而容易被埋沒。OpenAI 自己對出圖提示詞的建議是 1~3 句清晰描述起步,再補必要的構圖、光線和硬性約束(openai.com/academy/image-generation)。圖片模型需要的是優先順序明確的資訊密度,不是字數。 所以「專業廣告要求多」是對的,但細不等於長出圖進階篇 的六要素和 提示詞診斷技能 裡「不要堆形容詞把提示詞寫長」講的都是這一條。

兩段式:資料進文本模型,提示詞進圖片模型

真有 32K 的東西要交給出圖,它多半是品牌手冊、包裝規格、廣告 brief、角色設定庫。這類資料應該先進文本模型,由它提煉成一條高密度提示詞,再進圖片模型: 提煉層的輸出模板,在六要素之外加上廣告圖特有的三項:
1

把資料原樣交給文本模型

品牌手冊、規格表、brief 不用預處理,文本模型的上下文足夠大。system prompt 裡寫清輸出模板、字元上限(建議 2,500 字元以內)和「硬約束放最前」。
2

拿到提示詞先過長度閘門

檢查 len(prompt),超過 32,000 就讓文本模型再壓縮一輪。正常情況下提煉結果只有一兩千字元,這一步是防禦。
3

提示詞落庫,再調圖片模型

提煉結果存下來,出圖只重放這條提示詞。重試、換尺寸、換模型都不需要重新讀資料,也不會再為資料付 token。
4

資料變了只重跑第一段

包裝改版、brief 更新時重跑提煉,出圖這一段的程式碼和引數不動。
最小實現(OpenAI SDK,兩段共用一個 Key):
提煉結果和出圖引數一起存檔,是這條產品線上唯一可靠的復現方式(GPT-Image 系列不暴露 seed),詳見 出圖進階篇 第五節。

什麼時候真的需要長提示詞

有幾類場景提示詞確實會長一些,但都遠夠不到 32K:
  • 多圖編輯:用「圖1 / 圖2 / 圖3」逐一指代參考圖,說明各取什麼,幾百字。
  • 畫面內文字:招牌、海報、包裝上的文字要逐字給出,別讓模型編,幾十到幾百字。
  • 系列圖的固定字首:同一批圖共用的風格、光線、構圖段落,一千字以內。
這些加起來通常也就兩三千字元。提示詞真的逼近 32K,先懷疑是不是把資料塞進去了。

速查總結

  • 32,000 字元是 OpenAI Images API 的官方上限,按字元不按 token,/generations/edits 相同,API易 官轉不額外收緊。
  • 字元、token、上下文視窗是三件事:32K 英文約 8K tokens,中文更多;文本模型的上下文視窗和圖片模型的提示詞上限無關。
  • 網頁版沒有限制是錯覺:對話模型先讀資料、再自己寫短提示詞調圖片工具,圖片模型從沒直面那 32K。
  • 細不等於長:文本輸入按 token 計費且每次重試再付一遍;幾百條要求互相競爭,硬約束反而被埋。
  • 兩段式:資料進文本模型提煉成 1K~3K 字元的結構化提示詞,硬約束放最前,落庫後只重放提示詞出圖。

相關文件