批量修改 100 份文件，只成功了 73 份怎么办？
批量修改一百份文件，只成功七十三份时，应从逐项结果中恢复剩余工作，而不是把整批任务再跑一遍。批次需要整体摘要，但恢复的最小单位通常是单个文件或单个业务对象。
批次成功率不能替代对象清单
“成功率 73%”无法告诉接班人该重试哪些文件。每项至少记录稳定对象 ID、操作键、输入版本、执行阶段、实际结果和错误类别。没有返回结果的对象应单列为未知，不应直接混入失败项，因为其中可能已经写入成功。
| 分项状态 | 能否直接重试 |
|---|---|
| 已成功并读回 | 不重试，保留成果 |
| 明确校验失败 | 修正输入后重试该项 |
| 暂时性服务错误 | 按接口和幂等规则重试 |
| 提交结果未知 | 先对账再决定 |
明确批内顺序是否影响结果
一百份互不相关的草稿，可以按文件独立恢复；若后面的汇总文档依赖前九十九份明细，就不能只看文件级成功数量。应把依赖关系写进计划，明细未完成时不生成声称完整的总报告。缺失项可以显示为待补，但不能填零冒充无业务发生。
Google Docs 的 batchUpdate 说明了单个文档内请求批处理的行为。它不能推导出跨一百份文档的整体事务性。使用任何厂商的批量接口前，都要分别确认单请求、单文档和跨文档三个层面的原子范围。
恢复时保留原批次身份
为批次建立稳定 ID，为每个分项建立稳定操作键。重试记录应追加到原分项，而不是创建一份全新的“第二批”并丢掉关联。用户调整输入时则形成新的修订，说明哪些对象因需求变化需要重新处理，哪些只是技术失败后的续跑。
例如一份模板的页眉规则有误，已经成功的七十三份也可能需要修正；这属于新的修订任务，不是重试剩余二十七份。把需求变化与故障恢复分开，才能避免统计上看似完成，实际文件内容分成两种版本。
怎样交付一个尚未全完的批次
给用户提供可用成果清单、未完成清单和恢复入口。摘要可以写“七十三份已验证，十二份输入待修，十份请求待重试，五份结果未知”，并链接到分项证据。不要把整批统一标成失败，也不要在还有未知项时说一百份已经处理完成。
用于石墨等企业文档平台时，批次台账应与真实文件 ID 对应，并遵守实际接口的并发限制。本文给出的是调度和交付方法，不是某个产品已支持跨文件事务的声明。恢复能力需要通过中途退出、部分失败和重复启动等场景实际验证。
恢复入口还应保存上次核验时间，避免接手者误把过期的失败列表当成当前结果。
在企业文档中验证
如果要把本文方法用于企业文档，可预约演示，结合实际资料核对协作、权限与集成方式。
需要在自己的环境中验证时，可先了解私有化部署方案，再确定试用范围与验收要求。