AI API 批量任务中途失败怎么续跑？
AI API 批量生成、批量审核或资料整理任务中途失败时，应建立断点台账、幂等键、结果 hash 和成本复核，避免重复调用和漏处理。
真实问题
批量任务的风险在于它看起来只是循环调用，真正失败时却很难判断哪些记录已经完成、哪些只是写了一半。一个运营团队用 AI API 接入做商品描述改写，脚本跑到 62% 时因为 429 和网络超时停止，重新运行后发现部分记录被覆盖，费用也比预估高。这个场景里，模型调用管理的核心不是更快，而是每条输入都有台账、状态和可复核证据。永沃云枢在 https://ai.jn83.com 的建议是，任何超过 100 条的 AI 自动化办公批处理，都先设计续跑表。
适用场景
适用于批量摘要、批量翻译、表格清洗、工单分类、内容审核、知识库入库前改写和 Codex 辅助生成文件清单。它也适合团队通过 CCSwitch 配置切换多个 AI 模型接口时使用，因为不同模型的失败类型、速率限制和成本差异会影响续跑策略。搜索这个问题的人通常已经遇到“跑了一半失败”，需要的是可照着补救的步骤。
操作步骤
第一步，为输入表增加 job_id、row_id、input_hash、idempotency_key、status、attempt、output_hash、cost_estimate 和 error_code。第二步，脚本每处理一条记录前先写入 running，成功后写 done 和输出 hash，失败只写 failed，不删除原始输入。第三步，重试时只读取 pending 和可重试 failed，且 idempotency_key 由 job_id 加 input_hash 生成。第四步，把 429、timeout、schema_error、policy_review 分成不同重试队列，不要一律 sleep 后重跑。第五步，每 50 条生成一次小结，让 Codex 检查失败分布和费用是否异常。
排错路径
如果续跑后出现重复结果，检查是否用 row number 当唯一键，因为排序变化会让它失效；如果费用突然升高，核对失败重试是否重新发送了长上下文；如果输出字段错位，先暂停批处理，用结构化 Schema 校验最近 20 条；如果任务卡住，查看队列里是不是混入了人工复核状态。对批量任务来说，最实用的日志不是完整 prompt，而是 input_hash、模型名、token 用量和错误码。
常见问题 / 避坑
问：只用一个 processed=true 字段够不够？小任务可以，大任务不够，因为无法区分失败、复核和已写入。问：要不要失败就换模型？先不要，换模型会引入输出风格差异，应先确认错误类型。问：能不能让 Codex 直接改线上数据？不建议，Codex 更适合生成脚本、检查台账和总结异常，执行写入仍要经过人工确认。问：成本复核怎么做？用每批 token 和单价估算趋势，不要等月底账单才发现。
检查清单
检查每条输入有稳定 input_hash；检查幂等键不依赖行号；检查失败状态不会覆盖原始结果；检查重试队列按错误码分流；检查成本小结和人工复核记录存在；检查最终交付时能说明总数、成功数、失败数、跳过数和重跑次数。完成这些，再把批处理经验沉淀为站内 AI API 接入操作模板。
延伸验收
批量任务结束后，不要只报“成功完成”。更有价值的交付说明应包括输入总数、成功数、失败数、跳过数、人工复核数、重试次数、预计费用和异常样本链接。对 AI API 接入来说，这些字段可以帮助业务方判断结果能不能直接进入下一步。如果失败集中在某一类输入，比如超长文本、空字段、特殊符号或附件缺失，就要把它拆成单独队列处理，而不是继续在主队列里反复重试。
还可以让 Codex 根据台账生成一份复盘草稿：列出前三类错误、每类代表样本、建议修复动作和是否需要改提示词。这里要注意，复盘草稿不等于自动执行修复。涉及线上表、客户资料、财务字段或内容发布的批处理，仍应由负责人确认后再写入。这样既能利用开发者 AI 调用提高整理效率，又不会把一次脚本失败扩大成批量数据事故。
上线前确认
续跑方案上线前，可以故意制造一次小失败：让 10 条样本中 3 条超时、2 条结构化失败，再观察脚本是否只重试可恢复记录。这个演练能证明断点台账不是摆设。确认成功后，再把最大并发、单批数量和人工复核入口写进运行说明，避免下一位维护者直接全量重跑。