用 Nano Banana 2.1 制作并修改活动海报：逐步检查文字与细节

实用的海报工作流程，不只是生成一张好看的初稿，还要能修改标题、调整插画，并检查日期和其他重要信息在每次编辑后是否依然正确。本教程将带你了解如何在 Ofox 公开的 Playground 界面 中完成这一流程，然后展示我们将同样的三条提示词发送到 Ofox 的 Nano Banana 2.1 API 路由后得到的结果。

本文由 Ofox 发布，API 测试使用的网关也由 Ofox 提供。我们核实了 Playground 公共界面，但没有完成登录后的 Playground 生图测试。下方三张结果图来自 API 请求，并非在 Playground 界面中生成。本文由 AI 辅助撰写，根据真实 API 和界面证据核对，并在发布前经过独立的 AI 审阅。

准备一份可核对的需求说明

打开模型页面前，先把海报必需的内容与视觉偏好分开列出。真实活动的简短需求说明可以包含：

这些是占位内容，并非某个客户活动的具体信息。请与活动负责人确认拼写、日期、时区，以及场地或无障碍信息等必要内容。如果某一行必须准确无误，就把经过确认的文字直接写进提示词，不要让模型自行编造。

本例刻意只包含两行文字，这样就能检查编辑是否只更改标题、没有动到时间。提示词还要求出现 3 个苹果，数量很容易通过目测核对。正式海报如果包含场地、网址、赞助商和法律声明，则需要更全面的校对；最终稿也可能更适合在排版编辑器中完成。

打开 Playground 公共界面

1. 打开 Ofox 上的 Nano Banana 2.1 模型页面。确认页面显示的模型标识是 google/gemini-nano-banana-2.1，而不是较旧的 google/gemini-3.1-flash-image。
2. 找到嵌入的 Playground；如果系统提示，请登录。其公共界面提供提示词、图片附件和后续追问等功能；经过身份验证的生成可能需要账户和可用额度。
3. 从文本提示词开始。本例不需要附加参考图。如果你确实要附加品牌素材或现有海报，请确认你有权上传和编辑这些素材。
4. 如果界面提供正方形宽高比选项，可以选择该选项。Playground 界面会提示宽高比设置仅为尽力满足，因此不要把它当作精确像素画布或裁切结果的保证。
5. 提交第一条提示词，检查显示的图片，并使用可用的下载控件保存本地副本。如果没有下载控件，请检查图片是否提供其他保存方式。开始后续修改前，先保留原图。
6. 在同一段对话中发送下一条指令作为后续追问，并用不同文件名保存结果。第三轮也按同样方式操作。如果你希望模型基于前一张结果和对话继续编辑，就不要替换第一条提示词、重新开始。

公开模型页面可以证明界面及其提供的工作流程，但不能证明这些示例图是在经过身份验证的 Playground 会话中生成的。

从 Playground 下载的是栅格图片，而不是分层海报文档。请分别保存每个版本，不要以为之后可以把文字或碗选作独立对象单独编辑。如果你更偏好通过程序调用，或需要显式配置图片参数，请参阅 Nano Banana 2.1 API 指南。

第 1 轮：生成海报底稿

本例中请原样粘贴这条提示词：

Create a square minimalist event poster on warm cream paper. Large exact headline: ORCHARD MARKET. Smaller exact line: SATURDAY 10 AM. Draw three red apples in a blue ceramic bowl below the text. No other text, no logos, no border.

提示词指定了视觉层级、准确文字、可计数的主体、颜色和排除项。生成后，逐个检查 ORCHARD MARKET 和 SATURDAY 10 AM 的每个字母；不要只看缩略图判断文字是否正确。数一数苹果，确认碗是蓝色，并检查是否出现多余文字或标志。还要检查边缘：“不要边框”只是请求，并非保证。

以下是我们通过 Nano Banana 2.1 API 测试链生成的第一张图片：

API 测试，第 1 轮。目视检查发现了要求的文字、三个红苹果和一个蓝色碗。尽管提示词要求“不要边框”，画面仍将海报呈现为带外侧留白和阴影的纸张。

这一点会影响交付。装饰性的纸张边缘在样稿中可能看起来不错，但如果要做满版社交图片或印刷文件，就可能不合适。如果必须满版，请裁切并检查结果，或将图片放进具有明确画布设置的编辑器中。不要把好看的预览误当作已经符合印刷规格的证明。

第 2 轮：只改标题，不改需求

保留第一张结果在同一段对话中，然后发送以下后续提示词：

Change only the headline from ORCHARD MARKET to ORCHARD FAIR. Keep SATURDAY 10 AM exactly unchanged. Preserve the three red apples, blue bowl, cream background, composition and all other pixels as closely as possible.

这是一种实用的编辑方式：明确指出唯一要改动的内容，再说明哪些内容必须保持不变。“尽可能贴近原图”是有意这样写的。生成式图片编辑并不等同于在分层设计文件中替换文字；细小纹理、字形和周围像素都可能被重新生成。

API 测试，第 2 轮。目视检查发现了 ORCHARD FAIR，SATURDAY 10 AM 得以保留，画面中仍有三个红苹果和一个蓝色碗。

把保存的第一张和第二张图片并排比较。逐字检查新标题，再检查据称未改动的日期和时间。也要留意下方插画、背景、边距和裁切情况。在我们的测试中，所要求的内容从视觉上得以保留，但标题以外的区域并非像素级完全一致。“只修改”应当作为引导模型的指令，而不能当作锁定区域的保证。如果某个产品或作品区域必须原封不动，另文介绍的图片编辑时保留产品的方法可能比单靠文字指令更合适。

如果编辑结果改了日期或少了一个苹果，即使标题看起来正确，也不要批准。回到已保存的第一张结果，重新尝试修改标题，或使用外部编辑器精确替换文字。保留原始对话和文件，这样才能知道每次后续编辑基于哪个版本。

第 3 轮：修改一处插画细节

在同一段对话中保留标题修改结果后，发送第三条提示词：

Now change only the bowl from blue to dark green. Preserve ORCHARD FAIR, SATURDAY 10 AM, the three red apples and the layout.

API 测试，第 3 轮。目视检查发现碗变成了深绿色，而标题、时间和苹果数量仍符合要求。

这一轮说明，单独提出一个限制条件的编辑，比“让它更好看”之类的要求更容易评估。预期变化是碗的颜色。比较第二和第三个文件，检查这一变化，再次核对标题、日期、苹果数量、对比度和裁切情况。模型仍可能重绘超出要求的部分；前后对照是一项检查步骤，并不意味着像素得到了保留。

我们的测试是 Nano Banana 2.1 的一条三轮对话链，没有重复试验。三条 API 请求都成功返回图片，但一条简短的对话链不足以说明总体成功率。我们也在较旧的 Nano Banana 2 上用同样的提示词测试了一次；两条对话链均通过了文中所列的文字、数量和颜色目视检查。这一观察结果不构成整体质量排名。Nano Banana 2.1 与 2 的对比对此有更详细的说明。

确认海报无误后再定稿

以经过确认的需求说明为准，而不是以上一张生成图为准。在最终尺寸下检查：

• 字母和数字：标题拼写、日期、时间、标点和联系信息。本例中，首版应核对 ORCHARD MARKET，标题修改版和最终版应核对 ORCHARD FAIR。三个版本都要单独核对 SATURDAY 10 AM。
• 插画要求：应有三个红苹果，而不是两个或四个；最终版本中的碗应为深绿色。
• 可读性：文字与背景之间应有足够的视觉对比度，尤其要考虑缩小用于信息流或小尺寸传单印刷后的效果。
• 边缘和位置：文字或插画不应被意外裁掉；如果交付要求满版，则不应有多余的纸张边距。
• 意外添加的内容：多余文字、标志、可能被误认为标志的装饰符号，或尚未确认来源的可见标记。

示例中时间显示正确，不代表真实活动的时间也准确。校对时请对照经过确认的活动信息。如果必须使用准确的品牌字体、标志组合或不可更改的法律文字，请先生成图片或背景，再用外部编辑器在独立图层中排版最终文字。栅格图下载并不能让文字可靠地保持可编辑状态。

制作本地化海报时，请先取得经过确认的译文。按行将核准的文字写入提示词，再请合格的审阅者逐行校对实际生成结果，包括日期和格式。本例只测试了英文文字，并不能验证模型在其他语言中的拼写表现。

API 测试证明了什么，Playground 又没有证明什么

上方图片来自 Ofox 原生的、兼容 Gemini 的 generateContent 路由，使用的模型为 google/gemini-nano-banana-2.1。测试请求了 TEXT 和 IMAGE 响应模态，并将 API 图片配置设为 aspectRatio: "1:1" 和 imageSize: "1K"。每张返回的 PNG 都是 1024 × 1024。后续请求包含上一轮的完整模型内容和新一轮的用户消息，而不是只凭一张图片重新构建对话。我们没有设置随机种子或思考级别。

这些是 API 测试条件，不是让你去公开的 Playground 界面 寻找对应控件的说明。Google 介绍了图片生成能力和配置，而 Ofox 页面展示的是自己的公共界面。即使在该界面选择正方形，结果仍只是尽力满足；我们也没有测试经过身份验证的 Playground 输出。同样，不应声称可选的 Agent 或其他图片工作流程会自动选择 Nano Banana 2.1；我们没有验证经过身份验证的 Agent 模型选择。若要了解本例这种纯文本海报之外的参考图选择，请参阅产品场景该用单张还是两张参考图。

如果某一轮没有生成可下载图片，请先检查生成是否已经完成，以及响应中是否包含图片，而不只是文字。应从已保存的上一版重新尝试，不要悄悄改动需求。未生成图片的故障排查指南将响应处理问题与提示词、网关问题分开说明；Google 也提供了 API 故障排查指南。

导出并交付正确的文件

将海报底稿、标题修改版和最终碗颜色修改版分别保存为文件，并用文件名标明顺序。然后按实际用途导出或裁切副本，并再次检查最终交付的副本。如果其他人之后还需要修改日期或赞助商信息，请一并交付经过确认的文字，以及你另行制作的分层编辑器文件，而不只是模型生成的 PNG。

你可以下载示例素材包，将这一系列文件放在一起。如果需要为反复修改海报做预算，请参考 Nano Banana 2.1 定价指南，不要把一次成功生成的图片当成固定的单张海报价格。

最后，只使用你有权使用的输入图片、标记和文案，并查看适用的 Gemini API 条款。图片的外观，或没有明显可见水印，都不能证明其归属、独占性或不侵犯第三方权利。真正的完成标准，是得到一张经过批准和校对、并且符合活动实际需要格式的海报。