Batch 结果下载完了，怎样对账漏项、重复项和陌生 custom_id

Batch 文件下载成功，不等于每个输入请求都有明确结局。按行数对账会漏掉一个 ID 重复、另一个 ID 缺失的情况；只读成功输出，又会把错误文件里的已知失败当成失踪。应用应把输入清单与全部结果做集合和次数核验。

固定输入身份再读结果

提交前保存 custom_id 清单与输入文件摘要，并保证批内 ID 唯一。ID 是匹配键，不是列表位置；官方 Batch 文档提醒结果顺序不能作为输入顺序的依据。本文不提交真实任务，也不根据离线样本推导平台处理时长或费用。

输入示例为 r1、r2、r3。成功输出有 r1，错误结果有 r2，预期 missing 为 r3，但 r2 仍算已有明确结局。异常对照再加入一个 r1 和陌生的 rx，于是 duplicate 为 r1，unknown 为 rx。三类集合分别保留，不能把一条重复当作弥补一个缺失。

对账完整与业务成功分开

每个输入 ID 恰好对应一个结局，且没有陌生和重复 ID，才叫这批结果完整。结局可以是成功或明确错误；因此完整不代表成功率百分之百。报告同时给成功数、错误数、缺失数与冲突数，才能决定后续应该补取文件、检查重复来源还是处理失败请求。

附件先验证损坏集合准确列出三类问题，再验证补全后的集合可以完整对账。它把成功与错误文件合成统一视图，没有声称真实平台把两者放在同一下载文件。实际运行应按返回的文件标识分别取得材料，再送入本地对账器。

不用覆盖消除冲突

失败反例是把结果写入字典，后出现的同 ID 自动替换前一条。若两条内容互相矛盾，审查者再也看不到冲突。正确做法是 ID 对应结果列表，保存来源文件与行号，重复组隔离后人工判断，不能按下载时间猜哪一条更新。

输入本身有重复 ID 时，先阻断对账，不能把两个输入当一项去匹配。unknown 也不应自动加入输入全集，它可能来自错文件或错误批次。文件摘要和批次身份有助于排查来源，但本文不把 SHA256 当平台签名。

后续是否重跑缺失或失败项由独立流程决定，要核对原任务状态及重复副作用。本文不会发起重跑，也不改变服务端批次。离线通过证明输入与合成结果之间有唯一结局关系，结果正文仍需继续经过状态、Schema 和业务校验，不能在对账完整后直接全部入库。

配套文件与依据

本文的合成输入和参考结果可下载独立样本 a031.json，离线检查器 a031.py与样本放在同一目录后运行。检查器不调用模型接口。 使用 Python 3.12 或兼容版本，将上述文件下载到同一目录，执行 python a031.py。

一手资料1；一手资料2。资料核对日期：2026-10-24。