Image editing API：参考图接入与商品图片验收指南

从商品图片的保护要求反推 API 接入契约，梳理输入、请求、返回、下载和失败处理。现有资料不足以验证 InkRoom 的编辑协议，因此不提供虚构的调用示例。

2026-10-28 · 2026-10-28

需要把商品参考图交给 image editing API，不能只确认“请求成功”。还要确认提交的是哪个原图、返回文件能否使用，以及商品标签、颜色和轮廓是否仍符合要求。

本文提供的是接入设计与验收方案，不是已验证的 InkRoom 调用教程。现有资料未提供 InkRoom 编辑端点、认证方式、参数或响应结构，具体请求代码在这些证据补齐前应暂停编写。下文的方法均为设计建议，没有实际发送请求或生成测试结果。

先写验收条件，再写请求

从任务上区分：纯文生图主要用文字描述目标；参考图编辑则需要把已有图片作为输入依据，并说明哪些内容允许变化。所读的 eesel 图像编辑指南也将图片与提示词列为编辑输入，但这不是 InkRoom 字段或协议的证明。

以“只替换商品背景”为例，可以先写一份应用侧验收说明：

这些是验收建议，不是模型的保真承诺。提示词可以表达保护要求，但不能替代检查。若原图本身无法辨认标签，应先补充清晰素材或经确认的文案，不让模型猜出一个看似合理的版本。

先从当前官方文档确认以下信息，再选择 SDK 或编写 HTTP 请求：

需要程序调用或系统集成的读者，可以从 InkRoom 图片 API 接入介绍核对当前说明。已批准事实仅确认该介绍与程序接入入口存在；不能据此认定它支持本文所需的参考图编辑、查询状态或特定下载流程。未确认时，应把相应能力标为待核实，而不是用占位参数拼出“可运行”示例。

建议先设计一条与供应商字段无关的记录链：

已登记输入 → 待提交 → 已提交 → 已取得文件 → 待验收 → 可交付／已拒绝

这些是建议的应用内部状态，不是 InkRoom 返回的状态值。若供应商协议采用异步任务，再按真实文档增加等待与查询环节；若直接返回文件，就不必虚构轮询。

每次编辑至少关联原图标识、使用授权、编辑要求版本、本地操作标识和输出文件标识。供应商若返回请求标识，也可保存用于排障，但日志不应记录密钥或公开敏感图片。

取得返回后仍有两道门：先验证文件能被解码，且格式、尺寸和透明度满足下游要求；再进行商品内容验收。只有取得并检查文件，才能判断素材是否可用，不能把“收到响应”直接映射成“允许发布”。

明确的输入或权限错误：先修复文件、授权或配置，不盲目重发相同请求。

提交后超时：结果可能未知。优先按文档查询已有操作；只有协议明确支持时才使用其幂等机制。没有这些能力，就保留人工核对路径，避免自动重复提交。

下载失败：先确认是否已有成功生成的结果，再按真实协议尝试重新获取；不要默认必须再次生成。

视觉不合格：保存失败原因，隔离该输出。标签损坏或轮廓变化不是通过 HTTP 重试就能被证明修复的问题；后续修改提示词或输入后，应重新验收。

建议先按相同商品区域并排比较原图与输出，放大查看标签和边缘，再单独检查成品文件。颜色判断应使用一致的查看环境；没有色彩管理和容差定义时，不应宣称“颜色完全一致”。

如使用 OCR，可把它当作发现文字异常的辅助步骤，而不是标签正确的唯一证明。商品存在文字、结构或配件疑点时，应交给熟悉该商品的人确认。

参考指南强调，检查输出与验证后续系统应分开进行。对商品素材，这意味着还要确认上传到目标系统的是获准的那个文件，而不是旧版本或未审核版本。任何后续自动发布，都应建立在明确的验收门禁上，而不是建立在“API 已返回”之上。

下一步不是猜参数，而是补齐官方编辑协议与一组有授权的验收素材。拿到这些证据后，才适合编写并标注真实执行过的请求、响应和下载示例。