Claude Code 批量处理：从单次到规模化应用

十条和一千条不是同一件事

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

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

按数量选方式

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

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

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

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

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

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

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

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

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

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

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

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

一份照着填的脚本需求单

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

任务：把 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、写入前查一次，这就是幂等的实际用法；想少花重复的钱，可以先看缓存命中率里的思路。

质量抽检：比例要看阶段

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

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

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

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

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

断点与成本

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

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

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

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

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

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

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

跑顺之后，下一步把这些零散的线固定成可复用的模板：模板化与标准化。