Nano Banana 2.1 与 Pro：按图片任务选择

Google 官方模型页分别使用 gemini-nano-banana-2.1 与 gemini-3-pro-image 作为标识。第三方应用可能有自己的展示名称、开放规则和积分体系，因此一个叫 Nano Banana 的按钮，并不能证明背后运行哪一个版本。

比较之前记录服务商、可见的准确模型标识、设置和日期。如果没有公开映射，就把模型身份标为未确认。仍然可以评价这个产品的结果，但不能把它写成某个 Google 模型的确定实测成绩。

Google 英文更新日志记录了 Nano Banana 2.1 发布，并将更早的 gemini-3.1-flash-image 标为弃用。本文核查时，该条目没有宣布关闭日期。弃用与确定关闭时间，是两个不同事实。

已经有可用接入时，先盘点实际模型映射再计划迁移。保存一小组已经验收的图片和需求描述，用来检查服务升级后的变化。新模型公开发布，并不能证明每个第三方应用都已经完成切换。

先确定图片的用途。社交帖子、商品详情图、演示封面和概念草图，失败标准不同。图片整体很漂亮，但品牌名称错了、商品变形了，或标题没有放置空间，仍然不能交付。

生成前写一句验收要求：必须出现什么主体、保留哪些细节、元素放在哪里、用于什么尺寸。把主观喜好与硬性条件分开，才能说明为什么接受这一张、放弃另一张。

编辑图片时，先列出必须保持不变的部分，例如人物身份、商品结构、标志文字、颜色关系和背景对象，再用另一句写修改目标。只说变得专业，模型和验收者都难以理解边界。

新建图片时，明确主体、构图、光线、受众以及必须出现的准确文字。不要在关键限制之前堆大量装饰性形容词。需求生成器应该帮助你得到简洁、可检查、能复用的描述，而不是每次失败都继续加长提示词。

一张参考图可以说明商品长什么样，另一张说明构图，第三张说明配色。把每张图负责的事情写清楚，避免一堆图片给出互相矛盾的要求。

确认有权使用素材，也确认图片本身包含需要保留的细节。很小或压缩严重的照片，可能无法提供可靠文字与纹理。验收时逐项对照对应参考图，不只凭整体看起来像。

需求里放入需要出现的准确文字，输出后逐个字检查拼写、标点、数字，并以最终展示大小检查可读性。缩略图里看着像文字，不代表实际内容正确。

测试应使用真实设计中会出现的文字量。如果经常需要修正，可以考虑先生成画面，再通过独立排版步骤添加关键文字。这是生产流程选择，不能直接推导成模型能或不能处理所有文字任务。

商品图检查形状、配件、标签和比例；有授权的人像编辑则检查身份与要求保留的特征。整体风格令人满意，也不能掩盖某个导致图片无法使用的关键细节变化。

使用一份短的逐项通过清单，再单独记录风格喜好。这样不会让漂亮但错误的图获得最高评价。被拒绝的图片也保存具体原因，这些原因能帮助下一轮更准确地调整需求。

两个候选使用同一份创作描述和等价的参考材料。服务支持对应选项时，尽量统一尺寸与设置；无法对齐的差别应记下来，不藏在一句谁赢了里面。

如果尝试多次，就记录尝试次数。一个模型从很多张里选最好的一张，另一个只看第一次，并不公平。项目决策不一定需要巨大测试集，但需要诚实说明最终图片怎样得到。

很多图片通过多轮编辑完成。选出初始图后，只提出一个受控修改，例如换背景、调整标题位置或改变光线，再检查保留清单里的细节是否仍然完整。

记录需要多少次修改，以及最后还有什么人工工作。第一张草稿出色，但每次改动都影响无关细节，实际使用可能更费力。真正需要的是合格成品，而不仅是令人惊喜的起点。

按照具体服务当前的收费方式，统计测试用到的生成与修改，并计入人工修复。Google 直接 API、订阅应用和本站可能有不同套餐，不能把服务商单位价格当成另一个产品的结账说明。

下载权限、输出规格也放进比较。如果无法导出目标平台需要的文件，图片就没有真正完成。本文不给万能最便宜结论，成本判断需要自己的合格输出和实际服务条款。

本站有自己的图片生成与编辑入口，实际可用能力以界面展示的模型、限制和积分说明为准。文章介绍 2.1，不代表 Lite 或 2 Lite 选项已经被改成 2.1 接口。

先准备需求与验收清单，再选择界面确实提供的选项。明确需要 2.1 或 Pro 时，应核实对应映射，而不是凭文章推断。不要靠不断付费生成，试图猜出服务背后使用哪一版模型。

保存需求、参考图职责、模型身份、设置、合格输出与剩余缺陷。服务商调整模型，或项目要求变化后，可以重新比较。版本名称只有能关联到真实输出时才有意义。

最终选择满足硬性要求、修改工作与费用可接受的流程。遇到新任务再评估，不要让一个版本号或 Pro 这个词代替检查观众真正会看到的图片。