多参考图生成请求，为什么需要一份不可变清单

单张参考图的生成表单很容易理解：选择文件、填写提示词、提交。多参考图加入以后，同样的表单会迅速暴露数据建模问题。用户调整了图片顺序，某张图上传失败，模型只支持更少的输入，或者处理期间界面又被修改——如果系统只保存一个图片 URL 数组，很难解释某次生成到底使用了什么。

更可靠的做法，是在提交前构造一份不可变的资源清单。它不是为了增加表单复杂度，而是把用户意图、系统约束和任务证据放到同一个可验证结构里。

URL 数组缺少哪些信息

多图请求至少需要表达四类信息：稳定资源标识、用户确认的顺序、图片承担的角色，以及资源本身的校验状态。

例如，同一张人物图可以是“主体参考”，另一张室内图是“场景参考”，第三张图片只提供色彩或材质。如果后端收到的只是三个 URL，它无法区分顺序变化是用户操作还是网络并发导致，也无法在某张图失败时给出有意义的提示。

可以把每个输入建模为清单项：

{
  "assetId": "asset_8f2a",
  "position": 1,
  "role": "subject",
  "status": "ready",
  "mimeType": "image/png",
  "byteSize": 4280132
}

这里的 position 是用户确认后的显式值，而不是数组抵达服务器的先后；role 用于描述意图，不等于承诺模型一定精确遵循；status 则让提交前校验可以定位到具体资源。

上传完成不代表资源已经可提交

浏览器看到上传进度达到 100%，只说明字节已经发送完成。服务端还需要实际解码文件，确认格式、大小、像素与内存风险，并登记稳定资源 ID。

客户端扩展名和 MIME 声明都不能作为最终证据。一个文件也可能压缩体积不大，却拥有异常大的像素画布。清单项只有在服务端校验完成后才能进入 ready；若失败，应记录可恢复原因，例如格式不支持、文件过大、解码失败或资源已失效。

局部状态很重要。三张图片中的第二张失败时，用户应该只替换第二张，而不是重新上传全部输入。资源清单使这种局部恢复成为明确操作。

提交前进行组合校验

单个文件合法，并不代表整组输入适用于当前模型。提交前还要针对当前能力版本校验：

• 输入数量是否在模式允许范围内；
• 每张资源是否均为可用状态；
• 角色和顺序是否完整且无重复位置；
• 当前模型是否支持所选宽高比和分辨率；
• 登录状态与积分条件是否满足；
• 提示词长度是否仍在当前限制内。

这一步应由服务端做最终判断。前端校验用于即时反馈，不能替代服务端契约。若模型能力已经变化，返回结构化冲突，并指出失效字段；不要静默删除图片或替换用户选择。

请求快照必须与界面草稿分离

用户点击生成时，把资源清单、提示词、模型、输出设置和能力版本复制为不可变请求快照。此后用户在界面上重新排序图片或修改提示词，只影响下一份草稿，不改变正在处理的任务。

这项分离解决了一个常见的复核问题：结果出现异常时，页面展示的输入必须与实际提交内容一致。如果复核页读取的是仍可编辑的表单状态，就可能把后来修改的提示词错误地显示为当前结果的来源。

快照还可以参与幂等判断。响应丢失后，客户端使用原幂等键查询或重复提交同一快照，服务端返回已有任务；只有资源、角色、顺序或设置真正变化时，才创建新尝试。

去重不能只比较文件名

用户可能两次选择同一文件，也可能选择文件名相同但内容不同的图片。文件名既不能作为资源身份，也不能可靠去重。

系统可以在上传阶段计算内容摘要，用于发现完全相同的字节内容，但去重策略要保守。重复图片有时是用户有意选择，摘要相同也不代表可以擅自改变它在请求中的角色和位置。因此更合理的交互是提示重复并让用户确认，而不是自动删除。

资源存储层的复用与业务请求中的输入项也应分开：底层可以只保存一份相同内容，清单仍可保留两个拥有不同位置或角色的引用。

复核页继续使用同一份清单

生成完成后，清单不应被丢弃。复核页需要把源图、角色、顺序、提示词、模型设置和结果放在一起，帮助用户检查主体、场景、构图、文字、标识和需要保留的细节。

模型返回文件只代表系统执行成功，不代表视觉结果已经符合意图。输出质量、提示词遵循、身份一致性、唯一性与第三方权利许可都不能自动保证。将请求清单带到复核阶段，可以让“不符合预期”成为有上下文的质量判断，而不是一条无法追踪的失败反馈。

把公开边界变成校验规则

具体限制应该落入清单校验。以 Image to Image Generator 的公开工作流作为案例，单图模式使用一张来源图片，多图融合使用两到五张；输入支持 JPEG、PNG 和 WebP，单文件上限 24 MB，提示词上限 1000 个字符。模型、宽高比、分辨率、账号要求、积分成本与可用性会变化，4K 也不是所有流程的共同能力。

这里提到产品名只是说明需求来源，不提供站外链接。工程上的核心结论是：多参考图请求不该被压缩成临时 URL 数组。把资源身份、顺序、角色、状态和能力版本固化为不可变清单，才能让校验、重试、复核与问题定位共享同一份事实。