概述
gemini-3-pro-image-preview(即 Nano Banana Pro)對內容安全有嚴格控制,會在多個層級拒絕不合規的請求。簡單的「生成失敗」提示無法幫助使用者理解問題,一套好的錯誤處理需要做到:
- 精準識別拒絕原因 —— 區分內容違規、知識庫限制、技術錯誤
- 友好的使用者提示 —— 把技術錯誤轉化為可理解的說明
- 可操作的建議 —— 告訴使用者怎麼改才能成功
- 完整的技術資訊 —— 供開發者除錯排查
當請求返回 HTTP 200 但沒有圖片 時,這通常是谷歌側的安全判定。API易 透明代理只是如實轉發結果——我們同樣希望客戶成功出圖。判斷與文案處理需要在你的應用側完成。
谷歌內容稽核政策(2026 更新)
谷歌的圖片生成採用兩層安全機制:- 可調節過濾器:覆蓋騷擾、仇恨言論、露骨色情、危險內容等四類,可通過
safetySettings調整 - 內建保護:針對核心危害(如兒童安全)始終生效,無法通過引數關閉
- 生成式 AI 禁止使用政策:
policies.google.com/terms/generative-ai/use-policy - 生成式內容常見錯誤說明:
ai.google.dev/api/generate-content
三個核心判斷指標
按優先順序從高到低依次檢查:1. candidatesTokenCount(最高優先順序)⭐
- 位置:
response.usageMetadata.candidatesTokenCount - 含義:API 生成的候選內容 token 數
- 規則:等於
0表示在內容稽核階段就被直接拒絕,連候選內容都沒生成,這是最嚴格的拒絕
2. finishReason(次優先順序)
- 位置:
response.candidates[0].finishReason - 規則:不等於
STOP即為非正常結束,需要特殊處理
finishReason 取值(注意 Nano Banana 系列新增了 IMAGE_ 字首的圖片專用值):
3. 文本拒絕說明(重要)
- 位置:
response.candidates[0].content.parts[].text - 規則:
finishReason為STOP,但parts裡只有text、沒有圖片資料時,說明 API 返回的是拒絕說明而非圖片。文案可能是中文或英文,例如:
錯誤場景速查
處理流程(決策順序)
程式碼實現(核心)
將上面的判斷順序整合為一個解析函式:C 端友好提示文案
設計原則:簡潔明瞭、正面引導、可操作、避免指責。推薦模板:- C 端使用者:預設只顯示友好說明 + 修改建議
- B 端 / 工具服務商:預設展開技術詳情(
finishReason、candidatesTokenCount等) - 開發者:提供「展開/收起」檢視完整 JSON 響應
最佳實踐
- 嚴格按優先順序檢測:
candidatesTokenCount→finishReason→parts→ 提取資料 → 關鍵詞識別 - 先收集 text 再判斷 thoughtSignature,避免拒絕說明丟失
- 保留完整響應:開發/測試工具務必儲存原始 JSON,便於排查
- 支援中英文拒絕文案:谷歌可能返回中文或英文,關鍵詞匹配兩者都要覆蓋
- 友好降級:能智慧識別就給具體提示,否則直接展示 API 文本,再否則用
finishReason友好名稱,最後才是通用提示 - 永不顯示「未知錯誤」:始終帶上可操作建議或完整響應
常見問題 FAQ
為什麼同一個提示詞有時能生成有時不能?
為什麼同一個提示詞有時能生成有時不能?
谷歌的安全過濾存在隨機性和上下文相關性:參考圖內容、提示詞組合方式都會影響判斷。建議調整描述方式、使用更委婉的表達。
如何區分是內容問題還是技術問題?
如何區分是內容問題還是技術問題?
candidatesTokenCount: 0 或 finishReason: PROHIBITED_CONTENT → 內容問題;Failed to fetch 或 HTTP 錯誤 → 技術問題;有 API 文本說明 → 通常是內容問題。C 端使用者應該看到多少技術資訊?
C 端使用者應該看到多少技術資訊?
分層展示:預設顯示友好說明 + 修改建議;可選展開技術詳情;開發模式下顯示完整 JSON 響應。
是否需要為每個 finishReason 單獨寫處理?
是否需要為每個 finishReason 單獨寫處理?
不需要。用對映表 + 通用兜底即可:
reasonMessages[finishReason] || + 顯示原始值。