多张同名截图交给 Gemini，怎样保留每条结论的图片来源

多张同名截图交给 Gemini 时，来源追溯不能只依赖 截图.png。给图片稳定编号、计算文件摘要并保存输入顺序，才能把每条结论对应回确切字节。本文只处理重名图片的来源关系，不重复图片识别接口教程。

文件名、路径和内容身份分开保存

两张图片可以同名不同内容，也可以不同名同内容。路径能区分当前目录，但移动后会变化；SHA-256 摘要帮助辨认内容是否相同，但不能解释业务含义。因此清单同时保留编号、相对路径、原文件名、字节数、摘要和人工说明。

图片编号	相对路径	原名	人工内容说明
IMG-001	day1/截图.png	截图.png	订单列表，合成编号0001
IMG-002	day2/截图.png	截图.png	订单详情，合成编号0002
IMG-003	copy/截图副本.png	截图副本.png	与IMG-001相同字节

摘要需要实际计算，表中不编造看似真实的值。下面脚本只读文件，不发送图片：

from pathlib import Path
import hashlib, json
root = Path('images').resolve()
rows = []
for i, p in enumerate(sorted(root.rglob('*.png')), 1):
    data = p.read_bytes()
    rows.append({'image_id':f'IMG-{i:03d}',
                 'path':p.relative_to(root).as_posix(),
                 'bytes':len(data),
                 'sha256':hashlib.sha256(data).hexdigest()})
print(json.dumps(rows, ensure_ascii=False, indent=2))

正式任务生成编号后保存清单，不要每次因目录排序变化而重新编号。文件很多时可以改为流式计算摘要，避免一次读取大文件占用过多内存。

让每条结论带图片编号

提交图片时在对应内容附近说明编号，提示结果必须含 image_id、观察、证据区域描述和是否可确认。若结论需要比较两张图，来源应是编号数组，不强迫只填一张。不要让模型把同名文件自行命名为“第一张”，因为后续展示顺序变化会失去含义。

输出编号必须属于输入清单，缺编号或凭空增加编号都隔离。接着人工打开对应文件，看结论是否来自这张图。编号合法不等于来源正确，模型可能把 IMG-002 内容写到 IMG-001 下。

交换顺序做反例测试

固定两张内容不同的同名图片，先单独识别，再一起识别，最后交换输入顺序。比较结论是否仍跟随稳定编号。再加入相同字节的副本，验证应用是否按既定规则去重：同内容是否合并，要由业务决定，不能仅靠文件名。

如果在上传前生成缩略图或裁切版，记录派生图对应的原图编号、裁切区域和摘要。派生图与原图摘要不同是正常现象，不能直接把它们当成完全独立来源。证据区域文字也应说明是在原图还是裁切图中的位置。

本文没有执行 Gemini 图片调用，提供的是来源清单与污染测试。真正验收时要检查小字是否可读、敏感信息是否已经遮盖，以及遮盖是否删掉了需要验证的关键证据。

清单中还应记录图片宽高和是否经过压缩。内容摘要变化可能来自合法的缩放，也可能来自错传图片，只有保存派生关系才能解释。比较同名图时先用缩略预览人工确认编号映射，再进行识别。

常见问题

把名字改成1.png、2.png够吗？ 可辅助辨认，但仍要固定映射，防止改名后内容被替换。

摘要相同是否证明两份图业务来源相同？ 只能证明字节相同，业务来源还需清单说明。

图片修改一像素后编号要变吗？ 内容版本应更新，保留旧版与新版关系，不能继续冒充原始文件。

继续处理相关问题

相关入口：Gemini 接入基础。

官方依据与核对日期

核对日：2026-10-23。Gemini 图片输入：支持图片输入；本文编号和摘要映射由应用维护；Python hashlib：提供 SHA-256 等摘要计算。文中的流程、阈值和合成数据属于工程示例，不能代替当前账号、文件或运行环境的验收。