Google Workspace API加入评论与建议能力：Docs修订可留待审核，MCP支持仍是预览
2026 年 9 月 30 日，Google Workspace 官方更新宣布，Docs、Sheets 与 Slides 的开发接口增加评论处理能力，Docs 也支持通过接口提出建议修订。对把自动化接入文档评审的团队来说，关键变化是输出可以附着在具体内容上，交由协作者继续处理。
配图为 AI 生成的概念示意图，非真实产品界面、设备照片或活动现场。
本次发布覆盖的能力与状态
官方公告介绍，Docs 可添加和回复评论并提出文本修改建议，Sheets 评论可对应具体单元格，Slides 评论可对应幻灯片及其中的元素。面向全部 Workspace 客户和个人 Google 账号，自 9 月 30 日逐步推送，可见性最长约需十五天。相关 MCP 服务器中的评论支持仍是开发者预览。
Docs 开发文档说明，读取时可选择把建议内联显示，或查看全部接受、全部拒绝建议后的预览。后两者是读取视图，不代表已经替用户接受或拒绝修改。用于后续更新的文本位置，应以包含内联建议的视图为准。
评审输出需要锚点，也需要上下文
以下是本文的接入建议。先用一份测试文档验证评论落在哪一段，原文随后被编辑时是否仍能理解评论，以及回复能否对应同一个讨论。不要只检查接口返回成功；评审者真正需要看到的是“哪段内容、什么问题、建议怎样处理”。
例如自动检查发现一份说明中的日期不一致，可以写出两处原文和待确认问题。它不应直接猜出正确日期后覆盖正文。若规则只能判断存在冲突，就把交付状态保留为待核实，让真正了解背景的人作决定。
将自动化结果接入现有评审流程
先确定谁负责查看新增评论、哪些建议可以接受，以及处理后是否需要重跑检查。重复执行时还应检查是否会创建相同评论，避免协作者被一批内容相同的提醒淹没。把检查规则版本和本次输入版本记下来，有助于解释结果为何发生变化。
在多页签文档中，测试数据可以故意放入两段相同文字，确认定位没有只命中第一个出现位置。对于表格和演示稿，也应从实际单元格、页面或元素重新核对范围。能写评论只是能力入口，范围准确才使它适合日常协作。
本次公告没有意味着所有账号在发布当天就完成推送，也没有把 MCP 的预览状态升级为正式可用。团队可以先以小范围测试建立评审约定，再扩大到真实内容流水线。
来源与核验
Google Workspace官方更新：评论与建议支持（2026-09-30；正文经官方更新首页核验）；Google Docs开发文档：评论与建议（2026-10-01核验）。本文于北京时间 2026 年 10 月 1 日核验，功能状态以官方后续更新为准。
