事情本身不复杂，线索都在日志里。2 万条评论分类跑完，output_file 的行序和输入完全对不上，第一版按行号 zip 回去，错位之后有 300 多条结果被贴到了别的商品上，返工查了两个小时。
第一反应是「业务侧生成的 custom_id 有重复，对齐时互相覆盖」，验证下来不成立。
这类报错背后常见的原因有几处，逐个排除就行。批次内部并行执行，结果按完成先后落盘而不是按输入顺序。还有一种是失败请求只出现在 error_file，两个文件合起来才是全量。
少数情况下是response.body 里还有一层请求 id，容易误当成业务主键。
先用 jq 抽出 custom_id 和结果两列
jq -r '[.custom_id, .response.body.choices[0].message.content] | @tsv' out.jsonl > pairs.tsv然后把成功和失败文件合并成一个全集
cat out.jsonl err.jsonl > all.jsonl接着在内存里按 custom_id 建映射回填
python -c "import json;m={json.loads(l)['custom_id']:json.loads(l) for l in open('all.jsonl')};print(len(m))"末了核对映射条数与输入条数是否相等
python -c "print(sum(1 for _ in open('in.jsonl')), sum(1 for _ in open('all.jsonl')))"改完先别撤，确认这几项。映射后的条数与输入行数相同，抽样十条 custom_id 与业务单号一一对应，失败清单里的 id 能在输入中找到且未混入成功结果。
补一句。custom_id 是唯一可信的对齐键，行号、时间戳、response.id 都不行，生成时最好拼上业务主键，重复了整批数据都会错位。报错文案容易误导，真正的原因往往在相邻那一层的日志里。