展开本页目录
开始前准备什么
- 准备两张已授权且可辨认的图片,保持版本名和顺序稳定。
- 确认目标模型、通道和协议支持多张图片;不要套用其他型号的数量上限。
- 本页 A/B 为虚构包装规格图,不是商品实拍或真实重量测量。
- 先定义比较字段与范围,只对可见内容做结论。
- 固定图片 ID
- 逐图传入
- 分别读取
- 绑定差异
- 回看双图
两张图先分别定义身份
image_id 是本页给图片的业务标签,不是厂商通用的内置字段。把标签作为文字紧邻对应图片传入,再要求返回记录引用这些 ID;不能把自行新增 image_id 键硬塞进图片对象并假设接口接受。
| 图片 ID | 角色 | 可见标准字段 |
|---|---|---|
| image_A | 版本 A,基准 | DEMO TEA,紫色标签,250 g |
| image_B | 版本 B,候选 | DEMO TEA,绿色标签,200 g |
- 图片 ID
- image_A
- 角色
- 版本 A,基准
- 可见标准字段
- DEMO TEA,紫色标签,250 g
- 图片 ID
- image_B
- 角色
- 版本 B,候选
- 可见标准字段
- DEMO TEA,绿色标签,200 g
同一个请求,传两张真实图片
构造器会保留输入顺序并拒绝重复 ID,分别完整解码两张图。检查生成的请求里两份 Base64 确实来自不同文件;重复发送同一张图时,文字标签不同也不会产生真实差异。
多张图片会增加输入量,先用两张练习图核对实际型号和通道,再扩展数量。本地脚本的8张上限只控制示例范围,不能当作平台承诺。
只生成内容数组,不发起请求
python3 growth-batch7-vision-image-message.py \
--protocol chat --model YOUR_CONFIRMED_VISION_MODEL \
--images image_A=multi-image-a.png image_B=multi-image-b.png \
--prompt growth-batch7-vision-multi-prompt.txt \
--output multi-image-request.json差异先绑定字段,再绑定两边证据
比较分三层:图中文字值、颜色与形状等可见外观、需要外部资料的业务判断。前两类可以作为候选识别结果,第三类保留未知或待确认,不从画面推断真实重量、配方或产品是否合规。
本地标准差异示例;不是 API 输出
{
"differences": [
{
"field": "net_weight",
"left_image_id": "image_A",
"right_image_id": "image_B",
"left_value": "250 g",
"right_value": "200 g",
"evidence": "两张图中央净含量文字"
}
],
"unchanged": ["品牌文字 DEMO TEA"],
"unknown": ["实际重量", "材质", "商品真实性"]
}先排除图片错配,再检查遗漏差异
- 返回 images 里必须恰好包含原来的 image_A 与 image_B,不允许凭空出现 image_C。
- 每个差异的左右 ID 和字段值都能回指相应图片,不能把两个版本反过来。
- 本地标准有两类变化:紫色→绿色,250 g→200 g;品牌文字 DEMO TEA 不变。
- 颜色受到拍摄、显示和白平衡影响,真实照片精确色值要用原始素材和专门测量,不靠模型颜色名称。
- 没有发现差异不代表图像逐像素相同。需要像素检测、尺寸对齐或 Logo 真伪验证时另设方法。
版本扩大后,用 ID 和状态恢复
多组图片按 pair_id 保存两个图片 ID、文件哈希、来源和版本。接口响应成功、差异审核、业务确认分别记录;仅保存“相似度高”无法定位错误或恢复审核。
本页提供可运行的离线消息构造与双图标准,没有新增多图 API 实测、批量准确率或实际商品对比。正式应用先对自己的两张小样完成实际请求和逐字段验收。
怎样确认已经完成
- 输入包含两张不同真实图片,顺序和 ID 固定。
- 返回 ID 与原图一致,差异左右关系没有颠倒。
- 颜色和净含量两类差异都被逐项检查。
- 不变项与未知字段分开,图片标签没有被当实际测量。
- 原图、哈希、请求、响应与审核版本分别保存。
常见问题
image_id 是 API 固有参数吗?
本页把 image_id 用作业务标签,作为文字与图片一起传入。具体接口图片对象仍遵循厂商字段,不应随意添加未支持的键。
多图对比和多图生图一样吗?
多图对比使用视觉理解返回文字或结构化差异;多参考生图或编辑返回新图片,需要另一类接口能力与验收标准。

