Skip to main content

​
簡短回答

當介面返回 finishReason: NO_IMAGE 且 parts 為 null 時，通常表示模型處理了請求，但沒有返回圖片內容。 這不一定代表提示詞觸發了內容安全稽核。對於“什麼是 GEO”“請介紹一下某個概念”這類更像文本問答的提示詞，模型可能無法確認使用者是否明確要求生成圖片，因此直接返回 NO_IMAGE。 建議在提示詞開頭明確說明要生成什麼圖片，並補充畫面主體、佈局、風格和輸出要求。 另一類高頻原因是提示詞在要求模型寫文字，比如「生成設計方案」「請確保分析內容深入」。在只允許輸出圖片的呼叫裡，這類請求會以一定機率返回 NO_IMAGE，同一個請求時好時壞。見下文「提示詞在要求模型輸出文字」。
如果響應裡沒有 candidates，而是出現了 promptFeedback.blockReason（例如 OTHER），那是另一類問題：輸入內容在生成前就被原廠攔截了。請看 Gemini 出圖返回 blockReason: OTHER 怎麼辦？

​
為什麼會返回 NO_IMAGE？

​
1. 提示詞更像文本問答

例如：
這段內容主要是在解釋 GEO 的概念，沒有明確說明：
  • 要生成什麼型別的圖片；
  • 畫面中應該出現哪些元素；
  • 資訊應該如何排版；
  • 是否只需要圖片，不需要文字解釋。
即使請求中包含“生成圖片”幾個字，模型仍可能將整體請求理解為文本說明或知識問答。

​
2. 圖片生成意圖不夠明確

某些平臺工具會自動在使用者輸入前新增“生成圖片：”等提示詞。但通過 API 呼叫時，平臺通常只是透明轉發請求，不一定會自動補充完整的影像生成意圖。 因此，不建議只寫：
而應直接說明圖片型別和視覺要求：

​
3. 輸入內容缺少視覺描述

如果提示詞只有概念解釋，模型不知道應該把內容轉換成什麼畫面。建議補充以下資訊：
  • 圖片型別：資訊圖、海報、流程圖或宣傳圖；
  • 畫面結構：三欄佈局、時間軸或中心輻射結構；
  • 視覺風格：科技風、商務風、簡約風或品牌風；
  • 文字要求：標題、編號、正文和排版層級；
  • 輸出要求：僅生成圖片，不要返回文字解釋。

​
4. 提示詞在要求模型輸出文字

Gemini 圖片模型同時具備看圖和寫文字的能力。如果提示詞裡有要求文字產出的句子，模型會以一定機率「先寫方案」而不是直接出圖：
這類句子適合寫給文本模型。寫給出圖模型時，一旦請求設定了只輸出圖片（responseModalities: ["IMAGE"]），模型想寫的方案無法輸出，響應就變成 finishReason: NO_IMAGE、parts: null、輸出 token 為 0。 我們對一個真實的鞋款設計請求（3 張參考圖 + 上面這類提示詞）做過複測（2026-09 (UTC+8)，gemini-3.1-flash-image，responseModalities: ["IMAGE"]）： 所以同一個請求會「連續失敗幾次又成功」，而渠道本身沒有任何變化。最簡單的修法是在提示詞末尾加一句：
參考圖裡有清晰可讀的文字或第三方標識（如鞋底上的品牌字樣）時，模型更容易進入「先分析素材」的狀態。我們在上述測試中把這類字樣模糊處理後，同一請求也是 0/36。

​
responseModalities 不同，表現也不同

同一個「意圖不明確」的請求，在不同的 responseModalities 設定下表現不一樣： 排查技巧：把出問題的請求去掉 responseModalities 再發幾次，看沒出圖時模型寫的是什麼：
  • 寫的是一篇方案、分析，或者一段出圖提示詞 → 意圖不明確，按本頁的方法改提示詞
  • 寫的是「無法生成」這類拒絕說明 → 觸發了內容稽核，參考 Nano Banana 系列出圖失敗

​
GEO 提示詞示例

可以將原始提示詞改寫為：
“生成圖片”本身通常只是一個動作提示，不能完全替代對畫面內容的描述。越明確說明圖片型別、主體、佈局和視覺風格，模型越容易判斷這是一個圖片生成請求。

​
如何排查 NO_IMAGE？

1

第一步：先分清失敗訊號在哪個欄位

candidates[0].finishReason 為 NO_IMAGE，屬於本頁討論的情況。如果沒有 candidates，而 promptFeedback.blockReason 有值，說明輸入在生成前就被攔截了，請看 blockReason: OTHER 排查。
2

第二步：確認響應中是否有圖片內容

檢查響應中的 parts、inlineData、image 或等效圖片欄位。如果 parts 為 null，通常表示本次響應沒有返回圖片內容。
3

第三步：檢查提示詞是否明確要求生成圖片

確認提示詞中包含“生成一張圖片”“製作一張海報”或“create an image”等明確指令，不要只提交“什麼是……”或“請解釋……”這類文本問題。同時檢查有沒有「生成方案」「深入分析」「給出說明」這類要求文字產出的句子，有的話刪掉，或在末尾追加「只輸出圖片」。
4

第四步：再排查內容安全因素

如果已經明確要求生成圖片，但仍然返回 NO_IMAGE，再檢查是否涉及 NSFW、未成年人、知名 IP、去水印、真實人物肖像或其他上游安全策略。
5

第五步：檢視呼叫日誌

檢查呼叫日誌中的完整響應、模型名稱、request ID 和消費記錄。usageMetadata 表示模型處理過請求，但不能單獨證明圖片已經生成，也不能單獨判斷是否觸發了安全攔截。

​
NO_IMAGE 和內容安全攔截有什麼區別？

finishReason: NO_IMAGE 只能說明本次沒有返回圖片，不能僅憑這個欄位斷定一定是內容違規。需要結合完整錯誤訊息、提示詞內容和呼叫日誌一起判斷。

​
常見問題

不一定。“生成圖片”只能表達基本意圖，建議同時說明圖片型別、主體、構圖、風格和輸出要求。對於抽象概念，最好明確要求生成資訊圖、海報或流程圖。
從 GEO 的概念本身來看，沒有明顯的內容安全風險。但 NO_IMAGE 並不能完全排除上游策略影響，仍需要結合完整響應和呼叫日誌判斷。就當前案例而言，提示詞更像知識解釋，圖片生成意圖不夠具體是更值得優先排查的方向。
多數情況下渠道沒有變化。意圖不明確導致的 NO_IMAGE 本身是機率性的：模型每次都在「出圖」和「先寫文字」之間做選擇。在我們的實測中，同一請求的失敗率約 21%，而且會連續出現。建議客戶端在收到 NO_IMAGE 時自動重試 1~2 次，同時從提示詞上根治。
usageMetadata 只能說明模型處理了輸入併產生了推理或文本 token，不代表響應一定包含圖片。是否生成圖片，應以響應中是否存在圖片資料為準。
不能只根據 NO_IMAGE 判斷是否扣費。請以 API易 控制台的呼叫日誌為準，確認該請求是否產生消費記錄。

​
仍然無法解決？聯絡我們

如果明確補充了圖片生成意圖後仍然返回 NO_IMAGE，請聯絡 API易 客服，並提供：
  • 模型名稱和令牌分組；
  • 完整錯誤訊息和 request ID；
  • 脫敏後的提示詞；
  • 問題發生時間；
  • 呼叫日誌中的消費記錄。
請勿傳送完整 API Key。提交截圖或日誌前，請將金鑰內容打碼。

企業微信客服

企業微信客服二維碼掃碼新增，或點選本卡片直接聯絡客服。

郵件諮詢

客服郵箱：[email protected]郵件標題建議包含「NO_IMAGE + 模型名稱」。

​
相關文件

Gemini 出圖返回 blockReason: OTHER 怎麼辦？

輸入圖在生成前被攔截時的定位方法與參考圖預處理建議

Nano Banana 系列出圖失敗

檢視內容安全、去水印、知名 IP 和未成年人等常見原因

模型呼叫報錯怎麼排查？

檢視 401、429、503、504、超時和分組問題的通用排查流程

怎麼看懂日誌裡的計費金額？

通過呼叫日誌確認請求是否成功和是否產生消費