Gemini API 多轮图片编辑怎么连续修改图片

版本拆分原则

多轮图片编辑不是把几条要求一次性堆进提示词，而是让每一轮只解决一个视觉问题。应用侧至少保存四类信息：版本编号、上一轮图片文件、这一轮的修改指令、接口返回的最终图片。这样出现主体变形或颜色偏移时，可以回到问题发生前的版本，而不是从头重做。

• 固定内容：产品外形、主体位置、视角、材质和品牌色等不能随意变化的部分。
• 本轮内容：只写这一次要改变的背景、光线、局部细节或留白。
• 限制内容：明确不要改变的对象，例如“产品形状和相机角度保持不变”。
• 验收内容：规定完成后要检查什么，例如主体轮廓、边缘、比例和可排版空间。

如果项目还需要保持同一产品在不同画面中的外形，可以先参考多张参考图保持产品主体一致的做法，再把本页的版本记录流程接上。

调用前准备

1. 准备一张清晰的初始图片，建议先确认产品主体完整、边缘没有明显遮挡，并保留原始文件。
2. 为图片建立唯一文件名，例如使用项目名、版本号和日期组合，避免把上一轮输出误当成当前输入。
3. 选择当前账号可用的 Gemini 图片模型。资料包记录过 gemini-3.1-flash-image 和 gemini-3.1-flash-lite-image 的图片生成或编辑更新，但模型生命周期会变化，实际调用前要重新核对官方模型列表。
4. 准备一份版本表，至少记录输入文件、修改指令、模型 ID、请求时间、响应状态和输出文件。
5. 设置失败分支：请求失败时保留上一轮图片，不要用空响应覆盖已经通过验收的版本。

单项改动流程

每一轮都遵循“读取上一版、描述一项改动、保存新版本、检查结果”的顺序。图片编辑接口的具体字段会随 SDK 和模型变化，下面的结构是便于理解的伪代码，不应直接当作固定请求格式。

current_image = original_image
history = []

for round in rounds:
    instruction = round["change"]
    constraints = round["keep"]
    result = image_edit(
        model=verified_image_model,
        image=current_image,
        prompt=instruction + "；保持：" + constraints
    )
    if result.failed:
        save_log(round, status="failed", reason=result.error)
        break
    next_image = save_image(result.image, version=round["version"])
    save_log(
        round,
        input_image=current_image,
        prompt=instruction,
        output_image=next_image,
        status="pending_review"
    )
    current_image = next_image

关键点是把上一轮的成图作为下一轮的图片输入，而不是只发送上一轮的文字。每轮只修改一个变量，例如先改背景，再改光线，最后调整留白。这样更容易判断是哪一步导致结果偏离。

商品海报三轮示例

假设初始图片是一瓶护肤品的正面商品图，目标是制作一张适合社交平台发布的竖版视觉素材，可以按下面的顺序操作：

1. 第一轮改背景：输入原始商品图，要求“将背景改为明亮的浅灰色台面，产品保持正面角度、瓶身比例和位置不变，不添加人物和文字”。保存为 v01。
2. 第二轮改光线：输入 v01，要求“只优化左上方柔和光线和产品底部自然阴影，保持背景颜色、瓶身标签区域和构图不变”。保存为 v02。
3. 第三轮留出排版区：输入 v02，要求“只在产品右侧增加干净的浅色留白，产品大小、角度、材质和阴影保持不变，不生成任何文字”。保存为 v03。

检查时不要只看第三轮。将 v00、v01、v02 和 v03 放在同一张对比表中，分别标记“背景”“光线”“留白”“主体一致性”四项结果。如果某一轮主体突然变形，就回退到前一版，从更小的修改范围重新提交。

故障排查

• 每轮都把产品重新画了一遍：原因通常是下一轮没有传入上一轮图片，或提示词只描述目标画面，没有说明哪些内容必须保留。修正动作是确认请求中确实带有上一轮文件，并把不可变特征单独列出。
• 背景改了，主体颜色也变了：原因是“换成某种氛围”同时影响了产品色彩和光线。修正动作是把背景、光线和主体颜色拆成不同轮次，并明确“产品本身颜色不变”。
• 海报比例不适合排版：原因是只说“做成海报”，没有说明最终画幅和留白位置。修正动作是先确定横版或竖版，再描述留白在左侧、右侧或顶部，最后在应用侧检查实际尺寸。
• 结果出现文字乱码或多余标识：原因是模型尝试补充海报文案，或者提示词没有禁止文字。修正动作是要求输出无文字底图，标题、价格和说明改由后期排版完成。
• 请求失败后图片被覆盖：原因是程序没有区分失败响应和有效图片。修正动作是只有在收到有效图片并完成基础检查后，才把新版本写入当前版本指针。
• 不知道哪一轮造成了偏差：原因是没有保存原始指令、输入文件和输出文件的对应关系。修正动作是为每轮生成独立记录，并在失败记录中保存错误信息和重试次数。

发布前验收

1. 主体检查：产品轮廓、比例、角度、材质和关键局部没有出现未经要求的变化。
2. 改动检查：本轮要求确实生效，且没有把上一轮已经确认的内容改坏。
3. 画幅检查：最终图片符合使用位置的横竖比例，主体没有被裁切，留白足够放置后期内容。
4. 文件检查：输出文件可以正常打开，文件名、版本号和归档路径对应，原始图与中间版本仍可找回。
5. 发布检查：图片没有多余文字、标识或水印；模型 ID、提示词、时间和审核结果已写入任务记录；未通过人工检查的版本不能进入发布目录。

完成这些检查后，再把最终版本交给排版或发布流程。对于仍需调整的图片，不要继续覆盖已验收文件，而是从最后一个合格版本创建新的分支版本。