AI把一段产品说明插入文档，同时准备留下“请确认适用型号”的批注。如果返回结果提示评论保存失败，程序最容易做的动作是把整个请求再发一遍。但原来的正文可能已经插入成功，再做一次，就把同一段说明写了两遍。

Google Docs在9月30日更新的评论与建议指南中，专门说明了这种部分失败：文档模型里的插入、删除可能已经提交，而相关评论或建议未能保存。批量更新响应中的commentUpdateState，用来描述评论和建议更新的保存状态，不能把它直接理解成整份正文的提交结果。

一次操作，可能留下两种结果

对协作文档，正文和围绕正文的讨论往往一起出现，人的视觉感受也像一件事。接口对正文与关联信息的保存结果却可能不同：一部分已提交，另一部分没有保存。程序若只按“成功或失败”给整项工作分组，就会丢掉已经发生的那部分变化。

指南列出的状态包括未请求更新、全部保存，以及因未知原因全部失败。其中“全部失败”的对象是这一状态所描述的评论和建议更新，不能顺手扩展成“正文也全部回滚”。反过来，评论全部保存，也不表示产品事实已经通过负责人确认。

这类细节对中国团队与海外同事共同维护产品说明、报价草稿尤其重要。新增文字可能已对协作者可见，但原本用来提醒型号、交期或选项待确认的批注缺失。文件因此看起来比实际更确定。修复时既不能重复正文，也不能悄悄放弃那条仍有必要的确认请求。

重读之后，再决定补哪一部分

第一步是读取当前正文，找到原本准备修改的句子，确认它现在是什么。随后核对相关评论和建议是否存在，把“文字已改、批注未存”和“文字也没改”分开处理。只有确定缺失的动作，才进入补做范围，不能因为一个状态字段报错就整单重放。

位置也需要重新确定。正文一旦完成插入或删除，后面的字符位置就可能改变；协作者又可能继续编辑。旧请求中的位置不再天然有效，补批注时应根据当前内容定位，必要时先停下来处理歧义。把过期位置原样重用，可能把提醒挂到另一段文字上。

如果当前文档找不到唯一对应的段落，自动补做应暂停在这里。让负责内容的人确认指向哪句话，比程序自行选择一处相似文字更稳妥。这个暂停针对的是定位不清，不需要因此撤销所有已经明确完成的内容修改。

这也不同于报价讨论关闭后核对最终文字。那篇讨论人的决定是否真正写进正文；这里处理的是程序已经提交一部分内容、另一部分没有保存。两者都要看正文，但不能用相同的重试规则处理。

值得保留的操作记录可以很简短：这次原本要改哪段，当前正文是什么，缺的是哪条关联信息，以及最后补了什么。无需把整份报价复制进日志，更不必让AI重新生成一版措辞相近的全文来掩盖错误。

评论保存失败后，合适的下一步不是更快地重发，而是先确认文档已经变成了什么。知道已完成与未完成各在哪里，才能只补那一块空缺。

参考来源