在接入 Nano Banana 2（gemini-3.1-flash-image-preview）做 AI 图片生成时，很多开发者都会遇到一个极其反直觉的问题：

✦HTTP 状态码返回 200 OK

✦请求看起来“成功”

✦但响应里根本没有图片

✦甚至还被扣费了

这类问题比 429、500、503 更让人崩溃，因为它不会像传统 API 报错那样直接失败，而是给你一个“成功”的假象。结果是：你的程序继续往下执行、前端提示生成成功、日志也没有异常，但最终用户什么都看不到，成本还照常产生。

如果你也正在被这个问题折磨，这篇文章会系统讲清楚：

✫为什么 200 OK 不代表图片生成成功

✫为什么 BLOCK_NONE 也救不了

✫SAFETY 和 IMAGE_SAFETY 到底有什么区别

✫哪些提示词最容易触发“无图成功”

✫如何在代码里准确检测

✫如何通过提示词降敏 + 自动重试提升成功率

✫如何避免“空响应也扣费”吞噬预算

---

什么是“200 OK 却无图片”？为什么它比普通报错更难排查？

在传统 API 开发里，大家默认遵循一个朴素逻辑：

✫2xx = 成功

✫4xx = 客户端问题

✫5xx = 服务端问题

所以很多开发者在接入图片模型时，会把判断逻辑写成这样：

问题就在这里。

在 Nano Banana 2 的图片生成链路里，HTTP 200 只表示“请求已被正常接收和处理”，并不等于“图片一定生成成功”。当模型经过内容安全审查后，如果命中了某些不可绕过的图片安全策略，Google 仍可能返回 200，但响应主体里不会包含图片数据，而是给出一个候选结果，finishReason 被标记为：

• SAFETY

• IMAGE_SAFETY

• PROHIBITED_CONTENT

也就是说：

• 传输成功

• 调用成功

• 但业务结果被安全系统拦截

这就是为什么你看起来“请求成功”，但最终拿不到图。原文明确指出，Nano Banana 2 最令人困惑的地方就是：被内容过滤拦截时不返回 4xx，而是仍然返回 200 OK，并通过 finishReason 字段表达拦截状态。

---

真正的根因：Nano Banana 2 采用“双层安全架构”

要彻底理解这个问题，必须先理解 Nano Banana 2 的安全机制。

根据原文拆解，Nano Banana 2 并不是只有一层内容审核，而是至少存在两层不同性质的安全过滤机制：

第一层：可配置安全层（概率型拦截）

第一层是大家在官方 SDK 或 API 文档里最容易看到的那层，它会基于常见内容类别做概率判断，比如：

✦HARASSMENT（骚扰）

✦HATE_SPEECH（仇恨）

✦SEXUALLY_EXPLICIT（露骨性内容）

✦DANGEROUS_CONTENT（危险内容）

这一层的特点是：

✦可以通过 safetySettings 调整

✦可以对某些类别设置 BLOCK_NONE

✦属于可配置层

如果你的请求在这一层被拦截，通常 finishReason 会显示为：

• SAFETY

也就是说：SAFETY = 第一层拦截，理论上可以通过安全参数、阈值或提示词方式进行调整。

---

第二层：不可配置安全层（硬编码拦截）

真正导致“200 OK 却无图”的罪魁祸首，通常是第二层。

这层安全机制的特点非常关键：

✦不可配置

✦不可关闭

✦不受 BLOCK_NONE 影响

✦属于平台级硬策略

第二层通常涉及以下类型：

• IMAGE_SAFETY

• PROHIBITED_CONTENT

• CSAM

• SPII（敏感个人身份信息）等

这意味着：哪怕你已经把第一层四大类别全部设置成 BLOCK_NONE，第二层依旧会工作。

当请求命中第二层时，最常见的返回就是：

• finishReason = "IMAGE_SAFETY"

而此时 HTTP 状态仍然可能是 200 OK。

这也是很多开发者误判的根本原因：

✦以为是 safetySettings 没配对

✦以为是 SDK bug

✦以为是图片字段解析错了

✦甚至以为是模型偶发抽风

实际上，你不是“没生成出来”，而是“生成资格被安全系统撤销了”。

---

为什么 BLOCK_NONE 没用？很多人卡在这里

很多人第一次排查这个问题时，会做如下操作：

然后期待：“我都放开了，怎么还不给图？”

答案很简单：你放开的只是第一层，第二层根本不受影响。

第二层 IMAGE_SAFETY 是硬编码内容拦截机制，无法通过 BLOCK_NONE 或任何 safety setting 禁用。

所以如果你遇到的是：

✦200 OK

✦没有图片

✦finishReason = IMAGE_SAFETY

那么此时继续调 BLOCK_NONE 基本没有意义。

正确思路不是继续改配置，而是改提示词。

---

最关键的判断标准：一定要看 finishReason

如果你只记住这篇文章里的一件事，那就是：

不要再只看 HTTP 状态码，一定要检查 finishReason。

根据原文，Nano Banana 2 常见的 finishReason 可以这样理解：

1）STOP

表示正常结束，通常意味着图片生成成功，响应里应该能拿到图片数据。

2）SAFETY

表示命中第一层安全过滤。
特点：

✦可配置层

✦可尝试检查 safetySettings

✦也可以通过轻度改写 prompt 规避

3）IMAGE_SAFETY

表示命中第二层图片安全过滤。
特点：

✦不可配置

✦无法通过 BLOCK_NONE 绕过

✦必须通过提示词重写 / 风格化 / 降写实 / 弱化敏感实体来解决

4）PROHIBITED_CONTENT

表示内容触碰更强的平台政策边界。
特点：

✦通常不建议继续原样重试

✦应直接更换主题或彻底改写请求

这四类判断，是你所有错误处理逻辑的核心。原文明确给出：SAFETY 与 IMAGE_SAFETY 虽然都会导致 200 OK 无图，但修复策略完全不同。

---

哪些提示词最容易触发 IMAGE_SAFETY？

这部分非常重要，因为很多人以为自己 prompt “很正常”。

但在 Nano Banana 2 中，“正常”不等于“能过”。

原文总结了几个高频触发类别，尤其是在 2026 年 2 月 27 日之后的 Nano Banana 2 版本中，过滤明显比旧版本更严格。

1）真实人物 / 名人脸 / 公共人物相似形象

例如：

• “生成某某明星写真风格”

• “像某位演员一样的正脸特写”

• “总统演讲海报风”

即使你不直接写名字，只要描述足够接近公众人物，也可能被识别。

---

2）暗示性服装 / 边界性感描述

例如：

• 泳装

• 内衣风时尚

• 沙滩写实人物

• 紧身、暴露、贴身等描述

哪怕你主观上觉得“不色情”，也可能触发二层审查。原文提到：“时装秀模特”“沙滩游泳者”这类看似中性的描述也可能被拦截。

---

3）写实暴力 / 武器 / 战争场景

例如：

• 枪械细节

• 战斗现场

• 血腥写实

• 军事武器特写

• 动作电影式枪战海报

即使是“历史插画”或“电影感”也不一定安全，尤其是写实风格更容易中招。

---

4）货币 / 金融票据 / 仿真文件

例如：

• 美元纸币写实复制

• 支票、票据、护照、证件风格

• 高仿金融文档视觉

原文指出：真实货币或金融文件复制会稳定触发过滤，即使你想做的是虚构或风格化版本。

---

5）品牌 Logo / 商标视觉 / 高相似商业元素

例如：

• 生成某品牌广告海报

• 复刻某品牌 Logo

• 仿某品牌包装图

品牌词越明确、商标视觉越具体，越容易被拦。

---

6）医学解剖 / 人体结构 / 写实器官图

例如：

• 写实皮肤病图像

• 器官剖面图（照片风）

• 医学影像拟真重建

但如果你改成：

• 教育图表

• 科普插画

• 扁平化结构图

通常成功率会高很多。原文明确提到：医学图像在照片写实风格下更容易被拦，教育图示形式则更容易通过。

---

为什么你“明明没违规”，却还是被拦？

这是很多人最不服的一点。

原因在于：Nano Banana 2 的第二层不是“人工判断你有没有违规”，而是“系统判断你是否接近高风险视觉边界”。

也就是说，它并不是在判断你“主观意图是否恶意”，而是在判断：

✦是否容易生成敏感视觉结果

✦是否可能映射到平台高风险场景

✦是否与政策保护对象过于接近

因此，以下内容可能都被误伤：

✦艺术摄影

✦电影海报

✦时尚模特

✦医疗科普

✦历史战争重现

✦品牌案例教学

所以，被拦不等于你违规，而是模型认为“这类图像生成风险太高，不适合直接放行”。

原文还指出，相比原始 Nano Banana 模型，Nano Banana 2 在二层过滤上明显更严格，一些旧版可通过的 prompt，在新版中会直接触发 IMAGE_SAFETY。社区反馈甚至认为约 15%–25% 原本有效的提示词在 NB2 中会失败。

---

计费陷阱：最痛的不是失败，而是“失败也扣钱”

这件事之所以让开发者破防，不只是因为“没图”，而是因为：

很多 200 OK 无图请求，仍然会被正常计费。

• 只要是 200 OK + IMAGE_SAFETY 这种情况，通常仍按正常 token / 图片处理成本计费

• 与之不同的是：

  • 429（限流）

  • 500（服务端错误）

  • 503（服务不可用）

这些一般不会按同样逻辑计入有效生成成本。

• 1K 图像约 $0.067

• 4K 图像约 $0.151

即使没拿到图，也可能照扣。

举个非常现实的例子

如果你每天生成 10,000 张 1K 图片：

• 假设 20% 被 IMAGE_SAFETY 拦截

• 失败数 = 2,000 张

• 单张成本 = $0.067

那么每天浪费：

• 2,000 × 0.067 = $134

一个月就是：

• 约 $4,000

如果是 4K 图：

• 2,000 × 0.151 = $302 / 天

• 月度可超 $9,000

这不是“小误差”，而是足以让很多中小团队预算失控的坑。原文就用类似思路提醒：中等失败率在规模化后会迅速变成高额浪费。

---

正确修复思路：不是继续重试，而是“重写 Prompt”

很多人遇到 200 OK 无图后，会本能地做：retry same prompt

因为如果是 IMAGE_SAFETY，说明问题不在网络、不在偶发、不在算力，而在提示词本身的触发特征。

原文明确提醒：盲目重复提交相同提示词，只会产生同样的费用并得到同样的结果。

所以正确做法应该是：

重试 ≠ 原样重试

重试 = “改写后再试”

---

代码层面怎么修：必须做“业务成功”判断，而不是只做“HTTP 成功”判断

如果你是工程接入方，这部分必须做。

错误示范

这会把“空成功”误判成真成功。

---

正确思路

1. 先检查 response.candidates

2. 再检查 candidate.finish_reason

3. 只有 STOP 才认为生成成功

4. 其他情况根据原因分类处理

 Python 生产级示例，其核心逻辑是：

• STOP → 提取图片数据

• SAFETY → 认为是第一层问题

• IMAGE_SAFETY → 自动 soften prompt 再重试

• PROHIBITED_CONTENT → 直接终止，不建议继续同主题重试

---

推荐的生产级伪代码

下面给你一个更通用、更适合工程落地的伪代码：

for attempt in range(max_retries):
resp = call_nano_banana_2(current_prompt)

if not resp.candidates:
log(“NO_CANDIDATES”, charged=True)
return fail(“NO_CANDIDATES”)

reason = resp.candidates[0].finishReason

if reason == “STOP”:
image_data = extract_image(resp)
return success(image_data)

elif reason == “SAFETY”:
log(“SAFETY”, charged=True)
current_prompt = soften_prompt(current_prompt, mode=“light”)
continue

elif reason == “IMAGE_SAFETY”:
log(“IMAGE_SAFETY”, charged=True)
current_prompt = soften_prompt(current_prompt, mode=“strong”)
continue

elif reason == “PROHIBITED_CONTENT”:
log(“PROHIBITED_CONTENT”, charged=True)
return fail(“PROHIBITED_CONTENT”)

else:
log(f”UNKNOWN_REASON: {reason}“, charged=True)
return fail(reason)

return fail(“MAX_RETRIES_EXCEEDED”)

---

如何设计“自动降敏重试”机制？

如果你做的是 SaaS、批量生成、工作流平台，建议做一个多层重试策略。

第一次请求：原始 Prompt

尽量保持用户原意。

第二次请求：轻度降敏

自动添加：

• illustration

• editorial

• non-photorealistic

第三次请求：强度降敏

自动移除：

• 名人/品牌/武器/暴露服装等敏感词

• 真实人脸、写实、特写、仿真等关键词

第四次（可选）：回退到替代模型

如果你的产品允许，可以考虑：

• 降级到更宽容的图像模型

• 或提示用户“当前内容过于接近平台安全边界，建议改写描述”

原文也建议：对高过滤率应用，应考虑多模型降级策略，以降低总体成本。

---

上线后必须监控的 5 个指标

如果你是产品/工程负责人，这 5 个指标一定要埋点：

1）IMAGE_SAFETY 命中率

核心指标。超过 8% 就值得优化。

2）有效成功率（真正拿到图）

不是 HTTP 成功率，而是：

finishReason == STOP 的比例

3）每张成功图的真实成本

公式：

总调用成本 ÷ 成功出图数

如果 IMAGE_SAFETY 高，这个数会非常难看。

4）高风险 Prompt 模板 Top 20

找出最常失败的模板/场景。

5）改写重试后的恢复率

衡量你的自动降敏策略是否真的有效。

原文建议：对 IMAGE_SAFETY 拒绝率做监控，以尽早发现提示词问题或平台侧过滤收紧。

---

常见误区汇总

误区 1：HTTP 200 就是成功

错。
在 Nano Banana 2 里，HTTP 成功 ≠ 图片成功。

---

误区 2：开了 BLOCK_NONE 就一定能出图

错。
BLOCK_NONE 只能影响第一层，不能绕过 IMAGE_SAFETY。

---

误区 3：多重试几次总会好

错。
如果 prompt 不变，只会重复花钱。

---

误区 4：是 SDK 解析图片字段出问题

有时确实可能有解析问题，但如果 finishReason = IMAGE_SAFETY，那就不是解析问题，而是业务结果被拦。

---

误区 5：我没违规，所以模型不该拦

现实是：
模型拦的是“视觉风险边界”，不是“主观道德判断”。

---

一套推荐的最终解决方案

如果你想把这件事真正做好，我建议采用下面这套组合拳：

A. 接口层

• 永远检查 finishReason

• 只有 STOP 才算成功

B. Prompt 层

• 建立模板库

• 默认带风格化前缀

• 尽量减少写实敏感元素

C. 重试层

• 不做原样重试

• 只做“改写后重试”

D. 监控层

• 统计 IMAGE_SAFETY 率

• 计算单张有效成本

• 持续迭代失败模板

E. 产品层

• 前端提示不要写“生成失败”

• 建议改成：

  • “内容触发图片安全策略，请尝试更抽象或艺术化描述”

  • “建议移除真实人物、品牌、写实敏感元素后重试”

这比单纯报错更友好，也更专业。

Nano Banana 2 的“200 OK 无图”不是 Bug，而是设计

Nano Banana 2 返回 200 OK 却没有图片，绝大多数情况下不是接口异常，而是 Google 图片生成链路中的第二层安全系统主动拦截。

你需要牢牢记住这三点：

1）HTTP 200 不等于图片成功

一定要检查 finishReason。
原文明确指出：被过滤时也可能返回 200，只能靠响应体判断。

2）IMAGE_SAFETY 不能靠 BLOCK_NONE 解决

它是第二层硬编码安全策略。
不能关闭，只能改写提示词。

3）失败也可能扣费

所以你真正要优化的不是“请求成功率”，而是：

有效出图率 + 单张成功图真实成本

如果你把 Nano Banana 2 当成传统 REST API 来接，肯定会踩坑；
但如果你把它当成一个“带多层安全仲裁的生成系统”来设计，你就能把问题变成可控的工程策略。