批量提交：把 20 条视频任务推进接口再收集结果

20 条视频任务一条条点，40 分钟；写成脚本提交，又卡在限流、重复扣费和结果收不回来。问题不在脚本，在把「提交」和「等结果」写成了一个循环。

一句话结论

提交阶段的唯一目标是拿到可追踪的 task_id，不是拿到成品。把提交与收集拆成两个独立步骤，整件事才可控：提交只管推进去、记下号；收集另起一轮，按号查。我这次 20 条任务，人工逐条点 42 分钟，脚本提交 3 分 20 秒（含两次 429 退避）；幂等键用「本地任务号 + 参数哈希」，重跑三次没有一条重复扣费。首轮 17 条成功、3 条 400，全是参数超出时长上限，修参补提后 20 条全进。

这篇解决什么问题

三种情况最常见。一是脚本跑完，日志里只有一句「提交成功」，没有外部的任务号，后面结果对不上。二是重跑一遍，重复提交了 8 条，额度白扣。三是脚本里写了同步等待，跑 20 条要等 40 分钟，中途超时全丢。

根子是同一个：把批量提交当成循环调用接口，实际是建一套台账。循环调用只关心「这次返回什么」，台账关心「这一条现在在谁手里」——本地号、远端号、状态、耗时，四样缺一不可。有了台账，重跑是安全的，收集是可以事后做的，失败的能精确补。文章把它固定成五步，做完得到一张提交台账和一套可重复执行的提交脚本。

开始前要准备什么

• 单条可用的最小请求：先手动成功发一条，把请求体、响应体原样存下来。批量代码只能在这个基础上加循环，不能在没跑通的情况下直接写批量。
• 限流参数：每秒允许几次、每分钟几次、超限返回什么状态码。这三项必须实测出来，不能照文档猜——很多接口写的限额是「每分钟」，实际按「并发数」卡。
• 本地任务号规则：每条任务在提交前就生成一个稳定 ID（如 b20261020-001），全程用它做关联。不要用数组下标，重跑一次顺序一变就对不上。
• 一份 CSV 输入：一行一条任务，字段固定（提示词、时长、分辨率、回调标记）。任务清单进 CSV 而不是写在代码里，改起来不用动脚本。

具体怎么做

第一步：先跑通单条，把请求和响应存成样本

单条跑通的标准不是「返回 200」，是能拿到一个后续可查询的 ID，并且用这个 ID 立刻查一次，能查到状态。很多接口提交成功但查询要隔几秒才可见，这个延迟必须记下来，否则后面收集阶段会误判成失败。我这次延迟约 4 秒，第一次收集就因此误报了 5 条。

这是我调一个视频生成接口的单条请求与响应（含完整请求体、响应体、状态码）。
请帮我做四件事：
1. 指出响应里的哪个字段是「后续可查询的任务 ID」，如果不止一个，说明它们各自代表什么、该用哪个做追踪；
2. 判断这个请求里哪些字段是必填、哪些可以不传（按响应里的错误提示反推）；
3. 列出提交成功后多久能查到状态，并给出验证方法；
4. 标出请求体里哪些字段一旦改变，就会生成一条「新任务」而不是「重试」。

请求与响应：（粘贴）

第二步：定幂等键，先建去重表

幂等键 = 本地任务号 + 参数哈希。参数哈希的用处是：改了参数就该算一条新任务，没改参数重跑就不该再提交。本地建一张表，四个字段：本地号、参数哈希、远端号、状态。提交前先查这张表——同本地号同哈希且已有远端号的，直接跳过。这一步做完，重跑就变成安全操作，不用再手工核对哪些发过了。

我要给一个批量提交脚本加幂等控制，场景是：一个任务清单可能被重复执行多次，接口按提交次数计费。
请帮我做三件事：
1. 设计幂等键的构成，说明为什么不能只用本地号、也不能只用参数哈希；
2. 给出去重表的字段与判断逻辑（什么情况下跳过、什么情况下允许重新提交、什么情况下要新建一行）；
3. 指出如果两个进程同时跑同一个清单，会在哪一步冲突，给一个最小的防护方案。

我的场景：（粘贴）

第三步：写提交循环，并发与退避都要有上限

循环里三件事必须写死：并发不超过 3（多数接口按并发卡，不按次数）、429 与 5xx 才退避（4xx 里的参数错重试一万次也一样）、退避带抖动（2/4/8 秒各加 0–1 秒随机）。每条提交完立刻写台账，不要等全批跑完再落盘——中途崩了，前面发的号就丢了。我这次设的是并发 3、单条最多重试 3 次、总预算 60 秒。

这是我批量提交脚本的核心循环（含并发、重试、落库）。
请帮我做四件事：
1. 指出这段循环里哪些失败会「悄悄丢任务」（异常被吞、重试次数用尽后没记录、写库失败）；
2. 按状态码给出重试策略表：哪些立刻重试、哪些退避后重试、哪些绝不重试；
3. 指出并发数应该按什么信号调整，并给一个「不超过」的判定方法；
4. 给出中断恢复的最小改动：脚本被杀掉后重跑，怎么保证不重复也不漏。

代码：（粘贴）

第四步：落提交台账，四列就够

台账四列：本地号、远端号、提交状态、提交耗时。加一列「失败原文」用来事后分类。别在台账里存请求体全文——20 条还好，2,000 条就是灾难。请求体存到单独目录，按本地号命名，台账里只放文件名。我这次 3 条 400 的失败原文都是「duration 超出 15s 上限」，一眼就能定位是输入清单的问题，不是接口的问题。

这是我批量提交后的台账（本地号、远端号、状态、耗时、失败原文）。
请帮我做三件事：
1. 把失败项按「输入问题 / 接口问题 / 网络问题」三分类，逐条给判断依据；
2. 对可以修参重提的条目，给出改哪几个字段、改成什么；
3. 给一份重提清单：只包含需要补提的本地号，格式要能直接喂回脚本。

台账：（粘贴）

第五步：收集另起一轮，按号查不按列表翻

收集阶段不碰提交逻辑，只读台账拿远端号，逐个查状态。三种结果：成功（取产物地址）、失败（取失败码）、仍在跑（下一轮再查）。不要用「列表接口翻页」来收集——列表往往只保留最近若干条，任务一多就翻不到，而且顺序不保证。我这次 20 条，收集两轮完成：第一轮 13 条完成、7 条仍在跑；3 分钟后再查，20 条全部终态。

这是提交台账与两轮收集的结果（远端号、首次查询状态、二次查询状态）。
请帮我做四件事：
1. 判断哪些条目是真的失败、哪些只是查询太早，给判断依据；
2. 给一个收集轮询的推荐参数（间隔、最大轮次、总超时），并说明怎么按任务时长分布来定；
3. 指出如果某条一直停在「处理中」超过 30 分钟，应该怎么处理（重提还是人工介入）；
4. 给一份最终结果表的结构：要包含哪些列才能直接交给下游使用。

台账与收集结果：（粘贴）

实测记录

规模：20 条视频生成任务，单条时长 6–15 秒，统一 1080p；接口按提交次数计费，限额实测为并发 3、每分钟 30 次。

• 耗时对比：人工逐条点 42 分钟；脚本提交 3 分 20 秒，其中两次 429 各退避 4 秒和 8 秒。
• 首轮结果：17 条返回 200 并拿到远端号，3 条返回 400，失败原文均为「duration 超出上限」——输入清单里有 3 条写了 20 秒。
• 幂等验证：重跑三次，台账里 20 条无新增远端号，接口账单侧 0 条重复扣费。参数哈希改动后（分辨率 1080p→720p），同本地号生成了新任务，符合预期。
• 收集：第一轮 13 条成功、7 条处理中；间隔 90 秒后第二轮全部终态，20 条 100% 成功，总收集窗口 4 分钟。
• 踩到的延迟：提交成功后约 4 秒才能查到状态，第一次收集按「立刻查」跑，误报 5 条失败。

最容易错的 3 个地方

第一，在提交循环里同步等结果。看着省事，实际把整批的耗时变成了单条耗时的 20 倍，而且任何一条超时就把整批拖死。判断方法很简单：如果脚本跑完要几十分钟，说明它在等结果，不是在提交。正确做法是提交只拿号，收集另跑。

第二，只记「提交成功」，不记远端号。日志里有一百行「成功」，但没有任何一个可以查询的 ID。等到要收集的时候，只能去翻列表接口，而列表按时间倒序又只保留最近若干条，早期的任务根本翻不到。远端号是唯一能把本地清单和远端任务对上的东西，缺了它，整批等于白跑。

第三，把所有 4xx 都当成可重试。参数错、鉴权错、余额不足这类错误，重试的结果永远是同一个错误，只是把失败时间往后推了。更糟的是把真正的错误信息淹在一堆重试日志里，最后看到的是「重试 3 次后失败」，而不是原始的「duration 超出上限」。

可复用的东西

提交与收集分离：提交只负责拿到可追踪 ID，收集按 ID 另起一轮。任何异步接口的批量调用都适用，包括批量转码、批量翻译、批量审核。

幂等键三要素：本地任务号 + 参数哈希 + 去重表。改参数算新任务，不改参数重跑只跳过——这条规则让重跑从「危险操作」变成「安全操作」。

台账四列 + 失败原文：本地号、远端号、状态、耗时、失败原文。前四列支撑恢复，第五列支撑事后分类，缺了第五列就只能一条条去翻日志。

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接