一条失败就整批失败，浪费的已经完成的部分。
批量任务不是"循环调用"
把单条功能套个循环就是批量 ✗ —— 上线后立刻遇到四个问题 ✗：
排队与限流怎么处理 ✔、进度怎么给 ✔、失败怎么重跑 ✔、花多少钱先说清 ✔。
批量任务是独立的产品形态 ✔，要单独设计 ✔。
一、四个必备能力
① 排队与限流
· 任务进队列，并发可控 ✔（避免把上游打爆 ✔ —— 见限流那篇 ✔）；
· 给用户队列位置与预计等待 ✔（见容量那篇 ✔）；
· 支持优先级（交互式请求优先于批量 ✔）。
② 进度可见
```
已完成 42 / 100 ｜ 失败 3 ｜ 预计剩余 6 分钟
```
· 进度要按条（不是百分比估算 ✔）；
· 可暂停/取消 ✔（长任务必须能停 ✔）；
· 页面关掉也能继续 ✔（服务端执行 ✔ —— 见状态与恢复那篇 ✔）。
③ 失败可重跑
· 只重跑失败项 ✔（别把成功项再跑一遍 ✗ —— 白花钱 ✔）；
· 保留每条的失败原因 ✔（可导出 ✔）；
· 支持人工修正后重跑（见人工审核那篇 ✔）。
④ 成本透明
· 提交前给预估（条数 × 单条估算 ✔）；
· 超预算要确认 ✔（见价格与额度那篇 ✔）；
· 完成后给实际消耗 ✔。
二、结果的组织方式
· 可导出（CSV/JSON，中文 CSV 带 BOM ✔ —— 见导出那篇 ✔）；
· 可对比（同一批次前后版本的差异 ✔）；
· 可抽样复核（人工抽检入口 ✔ —— 见审核队列 ✔）。
三、三个反模式
· 前端轮询到页面关闭就断 ✗（任务其实还在跑，用户以为失败了 ✔）；
· 一条失败就整批失败 ✗（浪费已完成的 ✔）；
· 没有预估就开跑 ✗（账单惊吓 ✔）。
四、一条判据
> 提交 1000 条批量任务后 ✔，用户能否知道"进行到哪、花了多少、失败几条、怎么只重跑失败项" ✔？
> 缺任一项，说明批量只是循环调用 ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：把事故复盘连到评测：四步与三类事故
下一篇：把成本上限做成产品能力：让用户自己设 →
第 151 / 171 篇