批量作图排队前，先发现重复任务编号

商品精修支持批量任务时，也需要先检查任务清单是否清楚。同一个编号被两行不同要求占用，后续很难判断完成记录对应哪一行；把重复行都送去生成，还可能产生不必要的重复请求。本文给出一个本地编号检查例子，在排队前报告重复编号，不连接图片服务，也不自动重试已有任务。

　　假设准备处理一组钥匙收纳盘照片，清单里有任务编号与素材名称，其中一个编号被误复制。商品是方法示例，没有真实生成结果。程序只检查编号是否唯一，输出冲突行；素材是否属于正确商品、图片是否清楚、每行要求是否可执行，仍需另外核对。编号唯一只是任务可追踪的条件，不是图片质量指标。

　　编号要与工作内容一起保存。它可以由内部系统产生，也可以由团队约定，但一旦开始执行就不应仅因改文件名而换掉。素材版本、处理要求与输出目录都应能找到对应任务。如果当前系统已经提供可靠的编号，可以沿用；此处不要求每个团队重新建设一套编码系统，重点是防止同一编号表示不同任务。

from collections import Counter

rows = [{"id": "tray-a", "source": "a.jpg"},
        {"id": "tray-b", "source": "b.jpg"},
        {"id": "tray-a", "source": "c.jpg"}]
counts = Counter(row["id"] for row in rows)
duplicates = sorted(key for key, count in counts.items() if count > 1)
print(duplicates)
for index, row in enumerate(rows, start=1):
    if row["id"] in duplicates:
        print(index, row["id"], row["source"])

　　运行后得到 tray-a 的重复提示，并列出第一行与第三行。把第三行编号改成 tray-c 后，重复列表为空。这个构造测试说明计数与定位行为，不能证明 a.jpg、b.jpg 或 c.jpg 已经存在。实际导入前应另检查编号为空、字段缺失及素材路径，先在本地修正输入，不让服务端错误承担资料清理工作。

　　发现重复后不要直接删除一行。两行可能是误复制，也可能是同一素材的两种处理任务，或同一编号误配到另一商品。先按来源和要求核对：误复制可以合并，合法的不同任务需要各自编号，商品混用则回到素材表修正。程序提供位置，不决定哪份需求更正确，因此示例只有输出，没有自动覆盖或删除操作。

　　Picset 的项目资料列出批量精修功能，可以把编号检查放在钥匙盘素材处理之前，随后按已确认清单安排候选任务。这个本地脚本并非 Picset 接口，也不说明产品的并发限制或自动重试规则。具体批量操作条件以当前页面为准；本文没有调用记录，因此不填任务速度、成功率或单位费用。

　　执行时区分尚未提交、已提交待结果、已保存与失败等状态。尤其遇到网络超时，可能只是本地没有收到结果，不能从超时字样推断服务没有执行。应保留任务编号与请求记录，按实际服务提供的查询能力检查，再决定下一步。本文的编号脚本不会查询平台，也不会因为缺文件就发出重复生成请求。

　　结果返回后，记录输出对应的任务与素材版本，再检查钥匙盘轮廓、边沿和颜色。批量操作并不免除逐张观察；同一组里有一张正确，也不能推断其他张全部相同。文件存在与图像可以采用分开记录，最终交付还要看页面对应。不要让一个“完成”字段同时表示提交成功、文件落盘和商品检查通过。

　　要求变更时说明它是新任务还是原任务修订。仅改交付文件名可以保留处理记录；更换商品照片或制作要求，需要明确版本，避免旧结果进入新清单。内部编号可以帮助查找关联，但不能代替内容解释。团队需要能回答每张输出为什么存在、来自什么素材以及由谁确认采用。

　　批量流程的起点可以先做这项窄检查：清单能否唯一指向每一份任务。消除冲突后再检查资料、提交与结果，逐层保留事实。技术人员得到可复现的计数报告，运营得到需要核对的行，制作工具承担视觉处理；各自边界清楚，批量任务才有可继续追踪的记录。

资料与关系：本稿由与 Picset 存在直接商业关联的项目制作；商品场景为说明方法的假设示例，未作工具效果横评。产品信息按项目品牌事实表限定引用。Picset 官网；Python Counter 文档。