AI API 批量处理失败后怎么断点续跑？
批量调用 AI API 做摘要、审核、改写或资料整理时，真正麻烦的不是第一条失败，而是第 600 条失败后不知道前面哪些已经成功。直接整批重跑会浪费额度，也可能覆盖人工已复核的结果。
适用场景：一批任务跑到中途失败
这篇适合批量处理客服工单、商品描述、知识库切片、合同摘要、邮件草稿、内容审核和 AI 自动化办公报表。常见失败包括：网络超时、429、单条输入太长、JSON 解析失败、写库失败和人工取消。如果问题是单次失败后是否重试，可以先看 AI API 调用失败后要不要自动重试；如果高峰期队列堆积，先看 AI API 突然限流怎么办。
先定义状态：不要只记录成功和失败
批量任务至少需要这些状态：待处理、处理中、调用成功、结果校验失败、写入成功、人工复核、跳过、最终失败。只有成功和失败两个字段，断点续跑时就会分不清模型已返回但写库失败，还是根本没调用。每条任务还应有输入哈希和幂等键，用于判断输入是否变化。
操作步骤：让续跑只处理该处理的记录
1. 给每条输入生成稳定任务编号
任务编号可以来自业务主键，也可以由来源、批次号和行号组成。不要用纯自增临时序号作为唯一依据，因为重新导入文件后顺序可能变化。输入哈希用于判断同一个编号的文本是否被修改；如果输入变了，应创建新版本，而不是覆盖旧结果。
batch_id: ticket-summary-20260627
task_id: ticket-84921-v1
input_hash: sha256(title + body + customer_type)
status: pending2. 调用 AI API 前先写入处理中
调用前把状态改为处理中，并记录开始时间、模型名、profile、request_id 和尝试次数。调用成功后先保存原始响应摘要，再做结构化校验。JSON 输出不稳定时，可以参考 开发者调用 AI 模型时怎么约定 JSON 输出，把 schema、必填字段和错误原因写进日志。
3. 续跑时只选可重试状态
续跑脚本不要扫描全表。只处理待处理、超时处理中、结果校验失败且未超过次数的记录；跳过写入成功、人工复核和明确不处理的记录。已经写入成功的结果不应被模型新输出覆盖，除非输入版本变化或负责人明确要求重算。
4. 批后抽样校验结果质量
断点续跑保证流程完整，不保证每条结果都好。批量摘要、审核和改写完成后，按来源、长度、错误类型和模型名抽样检查。若某个模型或某类输入错误率明显更高，暂停该批次。成本和用量来源可结合 AI API 接入后怎么知道谁在消耗额度 观察。
常见问题/避坑：整批重跑通常是最贵的选择
第一个坑是失败后删除结果重新跑，导致已复核结果被覆盖。第二个坑是没有输入哈希，文本改过也被当成同一条续跑。第三个坑是把 JSON 校验失败当成调用失败，重复请求模型但不修 schema。第四个坑是没有批次级暂停开关，连续 429 时仍然把任务推给上游。
如果通过 CCSwitch 配置多个 AI 模型接口，续跑记录里也要写模型名和 profile。不同模型生成的分类标签、摘要风格和置信表达可能不同，同一批结果最好不要无记录地混用模型。需要多模型备用时，先看 AI 模型接口要不要做多模型备用，明确什么时候允许降级。
Codex 可以帮助你检查批处理脚本：哪些状态会被重跑、哪些结果会被覆盖、失败日志是否足够定位问题。但让 Codex 改这类脚本前，要给它测试样本和验收命令，避免把生产数据当测试数据。首次项目预检可以参考 第一次让 Codex 改项目之前要检查什么。
上线前还应准备 dry-run 模式，只输出将要处理的 task_id、状态和预计调用次数，不真正请求模型。负责人先确认续跑范围，再切换到真实执行。这个步骤能提前发现筛选条件写错、批次号选错或人工复核结果被纳入重跑范围的问题。
检查清单：批量任务上线前确认
- 每条任务是否有稳定 task_id、batch_id 和 input_hash。
- 状态是否区分调用成功、校验失败、写入成功和人工复核。
- 续跑查询是否只选可重试状态，不覆盖已确认结果。
- 日志是否记录模型名、profile、request_id、尝试次数和错误类型。
- 连续 429、超时或校验失败时是否能暂停批次。
- 批后是否有按来源、长度和错误类型抽样复核的规则。
验收标准：失败后能继续，而不是重来
一套合格的 AI API 批处理流程，应该允许你在中断后回答：哪些没跑、哪些跑了但没写入、哪些需要人工看、哪些不能再动。永沃云枢建议把这套断点续跑表和 AI API 接入专题、AI 自动化办公专题 连起来维护。这样 https://ai.jn83.com 上的开发者 AI 调用经验，才能从单次接口调通走向长期批量运行。