用变更契约验收 AI 图像局部编辑

精修商品图时，最麻烦的往往不是改得不好看，而是价签改对了，瓶身文字、手部或阴影也跟着变了。原文提出的办法，是把每次编辑写成一份可审计的「变更契约」：明确哪里能改、什么必须保留，再用检查和审核决定是否接收结果。

这套思路对商品图、营销本地化和 UI 样稿都有用。不过，文章属于 Ace Data Cloud 推广内容，代码没有执行，也没有生产实测。值得借鉴的是工程流程，具体模型与接口能力仍需核实。

提示词之外，还要约定哪些东西不能变

原文围绕 GPT Image 2.6 讨论精准编辑，但核心问题并不只属于某个模型：一句「替换杯子」很难完整表达边界，HTTP 200 也只能证明请求完成，不能证明图片改对了。

作者建议在生成提示词之前，先保存结构化的变更契约。它要回答三个问题：要改什么、要保留什么、禁止出现什么。

下面这段代码把「替换价签」变成了可以检查的任务：

type ChangeContract = {
  assetId: string;
  sourceSha256: string;
  markupSha256: string;
  change: string[];
  preserve: string[];
  forbid: string[];
};
const contract: ChangeContract = {
  assetId: "hero-042",
  sourceSha256: "<SOURCE_SHA256>",
  markupSha256: "<MARKUP_SHA256>",
  change: ["replace only the annotated price card with a blank cream card"],
  preserve: ["bottle geometry", "label text", "camera angle", "shadows"],
  forbid: ["new logos", "extra objects", "changes outside the annotated region"]
};

要注意 sourceSha256 和 markupSha256：图片 URL 的内容可能被替换，哈希用于确认当时实际使用的是哪份原图和标注。

变更契约的价值，是把「看着差不多」拆成可以逐项验收的要求。

自然语言负责描述目标，透明 PNG 标注层负责指出区域。两者配合能让要求更明确，但不能保证模型绝不越界，所以后面仍然需要验收。

前端表达业务意图，服务端决定模型和输入规则

原文把 GPT Image 2.6 分为 Flare 和 Sunburst，并建议用 Flare 快速尝试候选，用 Sunburst 处理最终编辑。不过作者也明确限定：只有自己的验收测试证明适合，才应该这样路由；这不是质量或延迟保证。

浏览器只传 preview 或 final，服务端通过白名单配置选择模型。原文给出的映射是：preview 使用 gpt-image-2.6-flare、quality: "low"，final 使用 gpt-image-2.6-sunburst、quality: "high"。这样可以集中调整模型，也能避免客户端选择不受支持或成本意外偏高的变体。

输入校验同样应该在请求前完成。按原文引用的接口规则，markup 必须是透明 PNG，尺寸要与完成方向校正后的第一张参考图一致；不能与 mask、GIF 输出或 prompt_rewriter 同时使用。像素上限为 16_777_216，文件大小上限为 40 * 1024 * 1024 字节。

这里有个实现缺口：原文的校验函数只检查 MIME 字符串、尺寸、像素数和文件大小，没有验证透明度，也没有展示图片解码过程。生产环境还要验证解码后的 MIME，通过白名单下载器获取远程图片，阻止私网地址，限制重定向次数，并记录素材使用权。

下面是原文未经执行的调用示例，用 JSON URL 提交原图和标注：

curl --fail-with-body \
  https://api.acedata.cloud/openai/images/edits \
  -H "Authorization: Bearer <ACEDATACLOUD_API_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2.6-sunburst",
    "image": "https://assets.example.com/hero-042.png",
    "markup": "https://assets.example.com/hero-042-markup.png",
    "prompt": "Replace only the annotated price card with a blank cream card. Preserve bottle geometry, label text, camera angle, lighting, and shadows. Do not add logos or objects and do not change pixels outside the annotated area unless required for a natural boundary.",
    "size": "1536x1024",
    "quality": "high",
    "output_format": "png",
    "response_format": "url"
  }'

注意 markup 和提示词末尾的边界例外：示例允许为自然衔接调整标注区域外的像素，而契约里的禁止项写得更严格，实现时需要统一口径。该地址属于 Ace Data Cloud；直接上传文件需要使用文档规定的 multipart 表单。没有原始素材时，原文建议走独立的 Images Generations API，接入前也可以在 Ace Data Cloud Studio 探索提示词。

图片生成后，为什么还要过三道验收

作者建议收到结果后，先复制到自己控制的存储并计算哈希，再分别检查传输、变更和保留情况。

传输检查确认 PNG 签名、预期尺寸、文件大小和持久化存储。变更检查确认价签确实替换，并在目标展示尺寸下检查可读性。保留检查则关注瓶身标签、边缘、阴影，以及有没有新增物体。

区域外像素差异可以帮助筛查，但不适合直接要求差异为零。生成式编辑可能调整交界处，因此作者建议先把标注区域向外扩一小圈，再计算剩余区域的差异，超过阈值就转人工。原文没有提供扩张宽度、差异算法或阈值，团队需要自行评估。

每次任务还应记录 sourceHash、markupHash、模型、提示词版本、输出哈希、差异指标、审核人和决定，并使用 accepted、rejected、needs_review 等终态。

重试也要分原因：400/422 修输入，401/403 停止调用，429 使用带随机抖动的退避；超时且结果未知时，先核对上次任务，再提交新的付费编辑。画面保留失败则需要修改契约或人工判断，不能按网络故障自动重试。

我的判断

我认同把输入留档、约束和验收连起来。相比只保存提示词与结果 URL，这种做法更容易解释一次失败，也方便审核人追溯素材。

但「可审计」和「可复现相同像素」是两回事。文章没有提供固定随机性或确定性输出的证据，记录齐全只能帮助重建调用条件，不能保证再次生成完全相同的图片。

模型分工也只是建议。作者没有给出 Flare 与 Sunburst 的质量、耗时、成本对照，没有独立生产测试，因此不能据此断言最终稿就该选 Sunburst。模型名称、参数兼容性和限制也只是原文陈述，需要以实际接入方文档和测试为准。

相比传统蒙版合成，生成式编辑更适合需要重新生成内容、协调光影的任务。如果只是固定位置覆盖价签或文字，常规图像处理通常更容易控制边界。是否引入模型，应先看任务是否需要生成能力。

能拿来做什么

• 给前端编辑器增加「修改要求、保留要求、禁止项」三个输入区，并将标注层与原图版本绑定，让用户提交一份完整任务。
• 在 Node 服务端集中管理模型白名单、图片解码校验和远程下载规则，浏览器只提交业务意图。
• 为商品图或 UI 样稿保留原图、输出图和差异结果，让审核人能检查文字、边缘和阴影，并记录最终决定。
• 将超时、限流和视觉验收失败分开处理，尤其在超时后先核对结果，减少重复付费请求。