Gemini API Batch Mode批量写作结果归档

先明确批次边界

官方发布说明确认，Gemini API Batch Mode 可将请求成批提交并异步处理。开始前不要把不同交付标准的任务混在同一批：摘要可按原文长度验收，改稿要核对原意，分类则要检查标签集合。接口名称、可用模型、配额和具体请求字段应以执行当日的官方文档为准。

• 一个批次只处理一种内容类型和一种输出规则。
• 为每项内容分配不可重复的任务标识，不用标题或文件名代替。
• 冻结本批的提示词版本、资料版本和审核规则。
• 先用少量固定样本跑通归档与复核，再扩大提交量。

建立可关联的任务字段表

字段表应在提交前生成，任务标识必须同时写入本地记录和请求关联信息。即使某项没有返回正文，也要保留它的原始记录。

按内容类型拆分并提交

1. 筛出资料齐全、已脱敏且允许处理的内容，缺少来源或版本的项目先退回补齐。
2. 按内容类型建立独立批次，例如只放摘要，或只放需要保留原意的改稿。
3. 为每个任务生成 task_key，并保存输入摘要、原始内容位置、提示词版本和预期输出格式。
4. 按当前官方文档组织异步批量请求；提交成功后，立即写入批次关联信息和提交时间。
5. 将本地记录标为已提交，不因尚未拿到正文而提前标为完成。

异步写作任务不应依赖人工记忆判断归属。后续获取状态或接收完成通知时，都应先用批次关联信息找到本地任务，再写入结果。

用一个改稿批次演练归档

例如运营团队有 20 篇产品说明需要统一语气。可建立 batch_key 为 rewrite-20261005-a 的批次，每篇分配 task_key，如 rw-001。每项记录原稿版本、需保留的事实清单和“不得新增未确认承诺”的规则。结果返回后，不直接覆盖原稿，而是保存为候选稿，并将 task_key、返回状态、正文位置和复核人写入归档表。

若 rw-007 的结果缺少一段，应把它标为待复核，而不是和正常稿一起导出。这样编辑看到的是清晰的待处理队列，而不是混杂的文件夹。

保存结果与失败记录

归档至少分为原始输入、请求记录、原始返回、可读结果和人工结论五层。不要只存最终正文，否则无法判断问题来自资料、规则、提交还是结果整理。

• 原始输入：task_key、内容位置、输入版本与提交前校验结果。
• 请求记录：批次关联信息、提交时间、模型与配置版本。
• 原始返回：完整返回内容、状态和错误信息。
• 可读结果：提取后的正文或标签，保留与原始返回的关联。
• 人工结论：通过、退回改写、重试或停止处理，并注明原因。

常见故障如何复核

发布前逐项验收

• 每个可发布结果都能通过 task_key 找回原始输入、版本和请求记录。
• 批次内不存在待取回、未关联或状态不明的项目。
• 失败、重复和空结果没有进入可发布集合。
• 摘要未遗漏关键限定条件，改稿未新增未确认事实，分类符合既定标签表。
• 候选稿经过人工抽检或全量审核，并记录审核结论。
• 导出的文件、正文和状态与归档表一致，且保留可回退的原稿。