GPT Image 2.6 连续修图：接着上一版改，还是从原图重做？

用 GPT Image 2.6 再改一轮图片时，只有想保留上一版的变化，才把上一版作为输入。如果上一版已经改错了标签、形状或背景，应回到原图，并写出完整的最终要求，把仍然想保留的修改也说清楚。两种做法都不能保证产品细节完全不变。是否接受结果，要对照原图和修改要求检查，不能只看接口是否返回成功。

我们在 2026 年 11 月 6 日通过 Ofox 对比了这两种输入选择。两张输出都完成了目标改色，也都改变了本来要求保持不动的区域。从原图重做的结果，在三个抽样区域中的像素差异较小；但每条路径只有一张结果，不能据此得出“重做总是更好”的结论。本文提供原始文件、完整提示词、请求参数和版本核查工具，方便你自己复核。

先下载修订示例

下载完整修订示例包。其中包含四张 PNG、脱敏请求与用量记录、最终状态提示词、版本清单、离线完整性检查脚本和响应解码脚本。下载文件、运行完整性检查都不会调用 API。

原图是我们为测试绘制的合成插画，不是真实商品照片。画面有 A、B、C 三个青色杯子，每个浅色标签上都有 A-17。之前的圈选修图教程把 A 改成了橙色；那次返回的文件原样保存为本次的 previous.png，没有重新加工。它已经出现纹理等额外变化，因此只是一个候选版本，并非完美保留原图的示范。

这次的新要求是把 B 改为紫色，同时保留橙色 A 和青色 C。选择因此变得具体：是在已有橙色 A 的图片上继续改，还是回到三个杯子都为青色的原图，同时说明 A、B 最终分别是什么颜色？我们没有加入第二张参考图、蒙版或新的标注层。如果你关心的是参考图数量，应看另一个独立问题：一张与两张参考图生成产品场景的比较。

根据想保留的内容选择输入版本

保留一份不覆盖的原图，每次下载用不同文件名。不要一直把结果覆盖成 final.png：后续发现问题时，应该还能找回上一份可用候选图，以及它来自哪个输入。

这些是工作流程的选择，不是某个参数能“锁死产品”的承诺。回到原图，可以避免把已有缺陷的生成图继续作为输入，但不能阻止新一轮产生变化。接着候选图修改，可能保留喜欢的构图，也会把候选图已有的问题一并带入输入。

OpenAI 图片生成文档介绍了通过 Responses API 进行多轮对话式修改的方法。本次实验的范围更窄：两次独立的 Images API 编辑请求，上传不同的 PNG 文件。我们没有测试 previous_response_id、持续对话记忆或 Ofox Chat 内部如何选择附件。不要把 Responses 专用字段直接塞进下面的 multipart 请求，就认为它们是同一机制。

提示词写最终状态，不只写“再改一下”

两次新请求使用了完全相同的英文提示词，示例包中的 prompt.txt 就是这段原文：

Create the final revised version of this flat product illustration. Mug A on the left must have a warm orange body. Mug B in the center must have a muted violet body. Mug C on the right must remain teal. Keep all three dark lids, handles, shapes and positions, cream A-17 labels and their exact text, A B C headings, FIELD / 03 title, subtitle, pale background, bottom line and small orange dot unchanged. No additional objects, no red annotation, no texture or photographic shading. Preserve the original flat illustration style and framing.

它要求左侧 A 的杯身为暖橙色，中间 B 为柔和紫色，右侧 C 保持青色；三个杯子的深色杯盖、把手、形状、位置、浅色 A-17 标签及文字、A/B/C 标识、主副标题、背景、底部线条和橙点都应不变。同时禁止新增物体、红色标注、纹理和摄影式明暗，要求保留平面插画风格与取景。

只写“把 B 改成紫色”，对从原图重做的分支是不完整的：原图中的 A 仍然是青色。把最终状态说全，任务才不依赖上一段对话才能理解。保护清单的作用是告诉你之后要检查什么，不代表模型已经满足了要求。

换成实际产品时，用清楚的对象描述替代 A/B/C，并列出影响交付的细节：包装文字、比例、材质、颜色、裁切和背景。同一个细节的指令应保持一致；“保留原来的颜色”和“把所有物体都改成橙色”不能同时约束同一物体。先消除冲突，再考虑下一次付费请求。

图片提示词指南还提供了其他编辑模式。本次保持最终提示词一致，计划比较的变量是输入图片的来源。由于没有固定随机种子或重复抽样，生成随机性仍会影响结果。

通过 API 复现其中一条路径

实测端点为 https://api.ofox.ai/v1/images/edits，Ofox 模型 ID 为 openai/gpt-image-2.6-flare，尺寸 1024x1024，中等质量、低复杂度，一次返回一张 PNG。没有传 input_fidelity、markup 或 mask。改用其他路由前，先核对账户可用模型和 Ofox Images API 文档。

把示例包解压到新目录，私下在环境变量中设置 OFOX_API_KEY，然后选择一个输入。下面是一条会产生费用的生成请求，不会同时跑两条路径，也不会自动重试。命令采用 macOS/Linux shell 写法。

: "${OFOX_API_KEY:?Set OFOX_API_KEY privately first}"
INPUT='previous.png'
RESPONSE='my-chain-response.json'
test -f "$INPUT" && test -f prompt.txt || exit 1
test ! -e "$RESPONSE" || exit 1
curl --silent --show-error --fail-with-body \
  --connect-timeout 15 --max-time 240 \
  'https://api.ofox.ai/v1/images/edits' \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -F 'model=openai/gpt-image-2.6-flare' \
  -F "image=@${INPUT};type=image/png" \
  -F 'size=1024x1024' -F 'quality=medium' \
  -F 'complexity=low' -F 'n=1' -F 'output_format=png' \
  -F 'prompt=<prompt.txt' -o "$RESPONSE"

如果要单独测试从原图重做，把 INPUT 改为 source.png，响应文件改用 my-reset-response.json 等新名字。最终提示词和其他参数保持一致。每次执行都可能单独计费；下载慢时先核对第一次请求状态及已保存响应，不要立即再发一次。

本次成功响应包含 base64 编码的 PNG。使用示例包中只依赖 Python 标准库的脚本解码：

python3 decode_edit.py my-chain-response.json my-chain.png

输出文件要用新名字，脚本会拒绝覆盖已有文件。JSON 错误、空 data 数组和其他响应格式都不是 PNG。如果路由返回图片 URL，应按该格式另行处理，不能把 JSON 文件改成 .png 后缀就算完成。不要把密钥写入文件名、版本清单或截图。

两张新输出实际说明了什么

这是本地证据查看页的真实截图，不是 Ofox Chat 界面。细节应以下面的原始尺寸图片及下载文件为准。

两次请求均返回 HTTP 200 和 1024 × 1024 PNG。本次接着上一版修改耗时 11.104 秒，从原图重做耗时 10.558 秒；每次报告 1,153 个输入 token，其中图片输入 1,024 个，以及 1,449 个图片输出 token。这是单次请求记录，不是速度基准，也不是当前价格报价。

从画面看，两张图都实现了 A 橙、B 紫、C 青的要求，A-17 标签和标题仍然可读。同时，两张都存在明暗、纹理，以及本应保持不变区域的细微差异。因此，HTTP 成功只能说明交付了响应，不能替代图片验收。

我们取三个固定区域，与 source.png 比较，没有进行图像配准。表中为 0–255 通道范围上的 RGB 平均绝对差，不是身份一致性、准确率或画质得分。即使肉眼认为可接受，边缘稍有移动也可能改变这个数值。

这些区域没有一处与原图像素完全一致。从原图重做的分支，在这几个测量值上更接近原图。这足以提醒我们不能宣称“完全保留”，却不足以推广成适用于所有产品、提示词或模型的优劣结论。本次只有一份合成插画、两张新输出，没有重试。真实商标、小号法律文字、人脸和摄影材质都需要另行评估。

留下能核查的版本记录

示例包中的 versions.json 记录了原图、之前的改图和两条新分支。每项都有父版本 ID、文件名、SHA-256 哈希和审核状态。生成候选图刻意保留为 review-required，不会因为文件存在就被自动标记通过。

source
├── previous
│   └── chain-result
└── reset-result

在解压目录运行离线检查：

python3 verify_versions.py .

预期输出为 PASS: 4 version files and parent links verified. Visual review still required.，表示四个版本文件及父版本关系通过核对，仍需检查画面。脚本验证的是文件字节和记录中的父子关系，不能证明模型实际使用了该文件，不能判断颜色是否正确，也不能替代视觉验收。请求记录提供另一层输入来源证据。

用于自己的任务时，将确切的源文件、提示词、模型和参数与响应一起保存，并记录谁接受了候选图、检查过哪些要求。验收后又改过文件，应创建新版本并计算新的哈希。如果出现哈希不匹配，先查原因，不要直接重写预期哈希让检查“通过”。

下一轮修改前，检查整张图

先区分请求失败和结果不合格：如果接口拒绝了 complexity、GIF 或 SVG 参数，查看Image 2.6 参数报错与适用接口；如果已经返回图片，但颜色、标签或版本不对，继续使用本节的图像验收与版本检查。不要用参数排错替代结果检查。

把原图和候选图按原始分辨率打开。先看指定改动，再看要求不动的部分。本例需要核对 A 是否仍为橙色、B 是否紫色、C 是否青色，三个标签是否仍是 A-17，杯子有没有缺失或重复，标题和取景是否可以接受。

实际交付时，区分“接受”“拒绝”“需要进一步检查”三种状态。背景好看，不能抵消产品标签错误。如果产品像素必须完全保留，应保留原始产品图层，在图片编辑器里检查合成结果；蒙版与产品保护教程讨论了对应的检查。合成本身仍然需要核对边缘、透视和阴影。

在 Ofox Chat 中使用同一份修订要求

如果不想编写 multipart 请求，可以到 Ofox Chat处理图片任务。上传确切的待修改图片，在指令里用文件名说明对象，写出完整的最终状态和保护要求。先前结果不合适时，重新附上原图，并明确它是新的起点。核对账户中可用的图片模型，拿到真实输出后再保存新版本。

本文两张新结果来自 API，并非在 Chat 中实测得到。我们没有验证 Chat 是否开放 API 的 complexity 参数，也没有验证它内部选择附件的机制是否与本例相同。可以复用的是版本记录和验收方法，不能据此假定隐藏参数或完全保留能力。

后续需要准确指向某个物体，可以继续看markup 圈选修图教程；想把已接受的设计制作成动图，则看独立的 Image 2.6 GIF 教程。进入新的输出格式前，先把已接受的静态图保留为独立版本。