---
title: "Claude Code 批量处理：从单次到规模化应用"
description: "从几十条到上千条，处理方式要换三次：分批对话、脚本批跑、接进流程。每一层都配一套质量抽检和断点续跑的做法。"
updated: 2026-11-13
canonical: https://docai.cc/learn/scale-up-batch-processing/
markdown_mirror: https://docai.cc/learn/scale-up-batch-processing.md
---
## 十条和一千条不是同一件事

处理十条，你可以复制粘贴、逐条看过。处理一千条，手就不是瓶颈了，流程才是。中间那条线大概在五十条附近：再多，分批对话就开始出错；再过几百条，就得让脚本替你跑。

换个说法：任务没变，你花的时间从「做事」变成了「设计和验收」。想清楚这一点，后面每个选择都好做。

## 按数量选方式

| 规模 | 做法 | 你主要负责 |
| --- | --- | --- |
| 十到五十 | 在对话里分批提交 | 定规则、逐批核对 |
| 五十到一千 | 写脚本循环处理 | 写清输入输出、抽检 |
| 一千以上 | 接进定时任务或系统 | 监控、异常处置 |

跨层不是靠感觉，是靠故障率。分批对话如果开始出现「前面几批和后面几批风格不一致」，就该换脚本了——人盯不住一致性。

## 分批对话时，先让规则落地

一次发几十条有个前提：规则必须在第一批之前讲完，并且确认它记住了。

```
我有 80 条产品描述要改，分 8 批发。每批开始前我会说「第 N 批」。
规则（全程不变）：
- 保留原有功能点，一个都不能删
- 口语化，不用形容词堆砌
- 单条控制在八十个汉字以内
先复述一遍规则，我确认后再发第一批。
```

让它复述是廉价的保险。省这一步，第五批开始走样，你得回头重做前四批。

每批之间抽查两三条，不用全看。发现有偏差，停下来改规则，别指望后面自己纠正。

## 脚本批跑：三件事必须写进需求

用它来生成批处理代码时，除了处理逻辑，把下面三条一并说清：

```
目标：批量处理 data/ 目录下的表格，逐条交给模型改写。
- 每条完成就立刻追加写结果，不要攒到最后统一落盘
- 记录已完成的行号或 id；下次启动跳过这些
- 相邻两次调用之间留出间隔，碰到限流就放慢后再试
```

第一条防的是崩在半路全丢，第二条是断点续跑，第三条对应[限流](/concepts/rate-limit/)与[重试退避](/concepts/retry-backoff/)。这三条不写，脚本一定在某个深夜给你添麻烦。

还有一个常被忽略的点：同样的输入重复跑，结果应该一致或可去重。给自己的每条任务一个稳定的 id，写入前查一下是否处理过，这就是[幂等](/concepts/idempotency/)在批处理里的样子。

## 一份照着填的脚本需求单

不要只说「帮我批量处理这些文件」。把输入、输出、失败处理写成一张单子，模型才有可能一次写对：

```
任务：把 data/raw/ 下的表格逐行改写，结果写到 data/out/result.csv。
输入列：id、原文、渠道。
输出列：id、改写结果、状态、错误信息。
规则：
1. 每完成一行立刻追加写入，不要等全部跑完再保存
2. 用 data/out/progress.txt 记录已完成 id，一行一个
3. 启动时先读 progress.txt，已出现的 id 直接跳过
4. 两次请求间隔 0.5 秒；收到 429 先等 2 秒，再 4 秒、8 秒重试
5. 单行连续失败三次，写入 failed.csv，继续处理下一行
6. 增加 --limit 参数，支持先跑 10 行验证
```

六条里，前三条决定中断后能不能接着跑，后三条决定跑起来稳不稳。第一次运行时加 `--limit 10`，人工看完这十行再放开全量，比跑完一千行再回头找问题便宜得多。

进度文件不必复杂，纯文本一行一个 id 就够；失败队列单独一个文件，跑完再逐条处理。不要把「未完成」和「失败」混在一列，否则你分不清是该重跑还是该人工看。

## 四种异常，先查哪里

| 现象 | 常见原因 | 处理 |
|---|---|---|
| 跑到一半报 429 | 请求太密，超了配额 | 加间隔、指数退避，或改走批处理接口 |
| 结果前后风格差一截 | 提示词太长被截断，或中途换了模型 | 固定模型与提示词版本，逐批抽检 |
| 同一行被扣两次费 | 重试时没有去重，任务 id 不稳定 | 用内容哈希或数据库主键做 id，写入前查重 |
| 中文输入返回英文 | 样例全是英文，或指令没限定语言 | 在规则里写「输出与输入同语言」，并给中文样例 |

第三种最容易被忽略，因为账单不会当场报警。给每条任务一个稳定 id、写入前查一次，这就是[幂等](/concepts/idempotency/)的实际用法；想少花重复的钱，可以先看[缓存命中率](/concepts/cache-hit-rate/)里的思路。

## 质量抽检：比例要看阶段

刚上线，全查。稳定跑过两三批，降到两成。再稳定，降到百分之五左右。规则改过、换了模型、数据来源变了，一律回到全查。

抽检看三样：格式是否一致、内容是否有依据、有没有整段编造。编造最难发现，因为读起来最顺。挑那种「细节特别丰富但你没提供过」的段落重点看。

能自动标的问题就别靠眼睛：

```
写一个检查脚本，对结果文件逐行标记：
- 字数少于下限 → 标记「过短」
- 原文是中文但输出含大段英文 → 标记「疑似串行」
- 出现「待补充」「XXX」这类占位符 → 标记「未完成」
- 同一段文字在多个结果里重复出现 → 标记「疑似复制」
```

标记只是提示，不是判决。但它能把几百条缩到几十条，你只需要看这几十条。

## 断点与成本

一千条任务，每条几秒钟，整体也就几十分钟。这段时间机器在跑，你可以做别的——前提是脚本能自己扛住中断。

成本上有三条朴素的办法：不重要的批次用便宜的模型；提示词能短就短；重复的请求先查缓存。批量任务用[批处理接口](/concepts/batch-api/)通常更划算，代价是结果回来得慢，适合不赶时间的场景。

| 做法 | 适合什么任务 | 代价 |
|---|---|---|
| 换便宜模型跑初稿 | 格式固定、判断简单 | 抽检比例要更高 |
| 缩短提示词 | 规则稳定的重复任务 | 边界情况容易漏 |
| 相同请求先查缓存 | 有大量重复输入 | 需要额外存一份结果 |
| 按重要性排队 | 数据量远超预算 | 次要数据可能长期不跑 |

预算紧的时候，先问「这一千条里，哪两百条真的会被使用」。把全量拆成必做与备用两档，往往比换模型省得更多。文档类批量的具体做法，可以对照[批量文档处理](/learn/batch-document-processing/)。

**什么情况不要批处理。** 有四类活不该硬上批量：

- 每条结论都要独立专业判断，比如法律意见、医疗建议；规模化只会放大错误。
- 原始数据含有姓名、联系方式、金额，且没有做完脱敏。
- 流程要求逐条留人工签字或复核记录，脚本无法替你承担这个责任。
- 输入格式本身不统一，字段时有时无；先把数据洗干净，再谈批量。

遇到这几种，退回单条处理或先做人工分拣，比硬上脚本安全。批量处理的上限不是模型能力，而是你能否验收每一行。

跑顺之后，下一步把这些零散的线固定成可复用的模板：[模板化与标准化](/learn/standardize-reusable-workflows/)。