海外同事把报价旁的批注标成“已解决”，销售准备导出文件发送。这时最值得再看一眼的，是原来被讨论的那句话：交期有没有真的改，选配是否仍混在标准配置里，价格条件是否还停留在建议状态。讨论结束和文件改好，可能发生在不同时间。

Google在9月30日宣布，Docs API正式支持程序化管理评论和建议。它把接受建议与回复、解决评论分别提供为不同操作。程序看到评论已关闭时，仍需读取实际正文和建议状态，才能判断对外文字是否已经确定。

一条批注里可能装着不同的动作

“请确认这个交期”是一项询问；“建议把交期改为按配置确认”提出了文字修改；“已和生产确认，保留原句”则可能是一个保留决定。三者都可以结束讨论，但只有其中某些决定需要改变正文。若AI只读取最后一句“已解决”，它无法可靠推断文件应该呈现哪种结果。

合适的收口方式，是把决定说到具体句子上：保留原文、接受哪条建议，或用什么文字替换。无需为每条标点批注增加审批，但涉及数量、配置、交付条件和金额解释时，回复最好能够指向实际改动。否则下一位接手者只能靠聊天记录猜测。

建议修改又有另一层区别。Google文档允许读取“所有建议已接受”的预览，也允许读取拒绝建议后的预览。预览是一种读取方式，不是已经执行接受动作。用这种预览生成摘要，可能让摘要看起来像定稿，而原始文件仍保留待决定的修改。

对接程序应明确自己读的是哪种视图。需要理解争议时保留建议和上下文；需要生成正式发送稿时，则先确认哪些建议已被实际采纳，再读取确定内容。不能为了让正文看起来干净，就默认采用全部建议，其中可能包含互斥的选项。

定稿检查落在承诺文字上

中国团队与海外销售共同修改报价，容易把“我已处理”理解为同一种状态。可以把讨论和发送稿分开看：讨论区说明为什么改，发送稿说明最后承诺什么。买家不应承担从批注颜色、删除线或内部缩写中拼出最终条件的工作。

一次有用的定稿检查，不必重新讨论整份文件。先回到影响交易理解的几处修改，核对原句、决定和最终句子是否对应，再看导出文件有没有把待定文字带出去。若保留了原文，也要确认这不是漏改，而是有依据的决定。

这里和采购单纠错的作用范围不同：后者判断一处修正是否应改变以后所有单据的规则；报价批注要确认的，是这份文件眼下究竟写了什么。不要把一个线程的关闭状态提升为整份文件的批准状态。

协作人数少、修改简单时，人工逐句确认通常足够；只有同类文件频繁流转，才值得把评论、建议和最终内容分别纳入程序。自动化最该减少的是反复猜测，而不是替负责报价的人决定接受所有修改。

发送前留下的最后一个问题很具体：收件人看到的这句话，是否就是团队刚才决定保留的那句话？答得上来，再关闭相关批注，文档状态才与人的决定对齐。

参考来源