几十份合同要提炼关键条款，上百份简历要打标签，一整箱票据要录成表格——一份份丢进聊天框，贴一次、等一次、复制一次，一天就这么没了。批量处理的本质不是「更快地聊天」，而是把 AI 当成流水线上的一个工位：文件进来，结构化结果出去。这篇讲清楚这套流程怎么搭，以及最容易翻车的三个地方。
第一步：先让输出变成结构化数据
单个文件的时候，回答是散文还是表格都无所谓，人眼看得懂就行。但几百份文件的结果要汇总、要排序、要导进表格，散文就没法用了。所以批量的第一步是强制模型返回固定结构的 JSON，字段写死在提示词里，例如「只返回 JSON，包含 party_a、party_b、amount、sign_date 四个字段，缺失填 null，不要任何解释文字」。
提示词里还要放一条兜底规则：无法从原文判断的字段一律填 null，禁止猜测。批量场景下，一个编造出来的金额远比一个空值麻烦——空值你能补，编造的值往往要等汇总出问题才会被发现。
批量处理的提示词模板一旦定稿就别中途改动。中途改模板，前一半和后一半的结果字段口径不一致，汇总时还要再清洗一遍。
第二步：并发要开，但要开得克制
串行跑几百个文件，一个文件三秒，一小时也就一千多个，时间全花在等待上。所以并发是必须的，但也不能一上来就把几百个请求全甩出去。稳妥的做法是固定一个小并发池，比如同时保持 3~5 个请求在跑，跑完一个补一个。这样既不浪费等待时间，也不会因为瞬时压力过大触发限流。
并发数可以从 3 起步往上试：如果开始密集出现 429 限流，说明踩到限流阈值了，降回上一档；如果一路顺畅，可以再加 2。文件体积大的任务要把并发调得更低，因为长文本响应慢，并发池里的请求会长时间占着名额。接口地址统一用 https://api.aigcbreeze.cn/v1，和客户端里填的是同一个。
模型搭配：批量任务量大，单份文件的活儿通常也不复杂，主跑用便宜的快模型就够了，比如 glm-5.3-flash 或 deepseek/deepseek-v4-flash；只把识别不准、字段缺失的那几份挑出来，换成更强的模型重跑一遍。这样整体成本比全程用强模型低得多。
第三步：断点续跑，别让一次中断全白干
批量任务跑到一半被打断是常态：网络抖一下、手滑关了窗口、某个文件格式异常直接抛错。如果脚本没有做记录，重跑意味着已经花钱处理过的文件再花一次钱。正确做法是每处理完一个文件就把结果立刻追加写进结果文件（JSONL 格式，一行一条），同时记下已完成的文件名。
下次启动时先读一遍已完成清单，跳过这些文件再从断点继续。这样无论中断多少次，累计消耗都只和处理过的文件数成正比，不会重复计费。顺带的好处是：跑的过程中就能随时打开结果文件看进度，不用等整批结束。
常见问题
跑了几百个文件，怎么快速找出哪几份出了问题？
结果落成 JSONL 时，每行除了业务字段，再补上文件名、状态标记和返回的原始文本摘要。跑完统一筛「状态=失败」或「关键字段全为 null」的条目，通常只剩个位数，挑出来单独重跑或人工看一眼就行，不用逐条翻。
同一个文件跑两次，结果不一样，以哪个为准？
这是模型的随机性导致的，把 temperature 调低（0~0.2 之间）能明显减少差异，但不能完全消除。对精度要求高的字段，可以跑两遍然后比对，两次一致的直接采用，不一致的标记出来人工确认——这比调参数管用。
批量任务要花多少钱，怎么提前估？
先用 5~10 份典型文件试跑，在控制台看这段时间的消耗，再乘以总份数，误差不会太大。文件内容长度的差异比份数影响更大，所以抽样时别忘了把最长的那几份也放进去，否则估出来的值会偏低。