一次写回两百条批注：document_apply_ops 批量操作实战

一份六十页的验收报告AI 校对跑出 137 个问题。按老办法document_add_comment 一条条写137 次工具往返每条几秒的延迟光写批注就要干等十分钟中途会话一断还得重来。Agent 办公落地喊得响真到批量场景一条条写回就是瓶颈。察元AI文档助手针对这个场景准备了一个批量工具document_apply_ops一次调用最多写回 200 条操作。这篇记录完整打法。第零步确认链路在线动手前先看 WPS 和加载项是否连着——如果报 WPS_AGENT_OFFLINE说明 WPS 没开或者加载项掉线先把 WPS 打开等它回连再继续。批量操作跑到一半才掉线比一开始就失败烦得多。链路检查一句话就能让 AI 代劳“调 wps_status 看分层健康”各层状态一目了然。第一步dryRun 拿问题清单先让 AI 只读不写用这句终检提示词帮我做发布前终检错别字、标点、数字前后一致性、表格与正文是否一致全部用批注输出最后给我一份问题分级摘要严重/一般/建议全部用批注输出描述的是最终形态但执行时 AI 会先跑 proofread_run 的 dryRun 拿到 issues 列表——这个工具默认就是只返回问题、不落盘天然适合当第一步。dryRun 的价值在批量场景被放大问题列表是可人工编辑的中间产物你改完再进下一步等于在AI 的判断和文档的改动之间留出一个编辑位。数表多的材料再加一句勾稽核对数表与正文数字是否一致合计、百分比第二步人工过筛137 条里通常混着三类真错、可改可不改、误报。让 AI 把清单按严重、一般、建议分级提示词结尾那句就是干这个的我只保留严重项和部分一般项一般能砍掉三分之一。分级还有个附带好处写回时让严重的先提交、一般建议的靠后批注在文档里的分布自然有主次。这步千万别省它直接决定了写进文档的批注质量——批量写回的威力越大入口把关越重要。第三步组装 ops 一次性写回确认后的清单交给 document_apply_ops。它支持四种操作replace 替换正文、comment 加批注、comment-replace 批注加替换、insert-after 在锚点后插入。每条操作关联一个锚点和对应内容锚点来自前面的段落列表或 document_locate批量写批注就是 comment 数组一次调用最多 200 条。执行时带上 confirmed:true——不带的话老规矩只返回 preview 不写盘。整批提交前还可以让它先报一遍 ops 条数跟清单对得上再确认。137 条一批正好在上限之内哪天问题超过 200拆成两批先后提交就行。第四步抽查与善后写回完成后让 AI 随机抽十来条批注报告位置和内容自己再肉眼核对两三处确认批注钉在了正确的字句上最后 document_save 收尾。个别锚点漂了的条目会以 LOCATE_MISMATCH 或 LOCATE_NOT_FOUND 报回来单独重试即可不影响整批结果——批量操作里的单条失败不会掀翻整桌这点设计得很务实。四种 op 怎么选我的经验错别字用 comment批注标出原文和建议改法改不改让作者定已经和作者当面确认过的硬伤用 comment-replace批注写明理由同时改正文留下改动痕迹成段的补充说明用 insert-after。纯 replace 不带批注地批量替换慎用——快是快但没有留痕审阅的人不知道哪里被动过出了问题无从追溯。200 条的上限我也觉得定得合理一批的规模可控出了问题好定位真要几百条就分批节奏反而更稳。记忆口诀留商量用 comment已拍板用 comment-replace补内容用 insert-after纯 replace 最克制。适用场景与边界终检、验收材料、标书交叉核对凡是问题多、都要落批注的场合apply_ops 都是效率主力一次调用顶过去一百多次往返。个人写作者的日常稿、团队的制度文件汇编也能套这四步——批量工具不怕问题多就怕问题没过筛。但有两句话放在最后批量写回的前提是批量过目没看过的清单不要一键确认AI 给的问题分级是参考哪些算严重、哪些可以放过最终得文档负责人说了算。