网硕互联帮助中心察元 AI 文档助手把自动审查拆成明确三态：预览（dryRun）、确认写批注、确认替换。Claude Code 经 chayuan-wps-mcp 调用时，写操作需要 confirmed；未确认通常只返回预览或报 CONFIRMATION_REQUIRED。这是门禁，不是故障。本文按操作顺序写清三态差异、口令、抽查方法和失败模式。
为什么必须先预览
预览只产生问题列表：原文片段、建议、理由或级别，不写批注、不改正文。你在对话里就能丢掉误报、标出必须改的条目。跳过预览直接「全部改完美」，在制度稿和合同上风险最高：同音替换可能改掉专有名词，表格锚点漂移可能改错单元格。
技术上对应 proofread 的 dryRun。客户端说法可以是「校对预览」「先预览不要写批注」。
官网与发布包：https://aidooo.com、https://github.com/zhgyuhuii/chayuan-wps-releases。
三态对照
预览（dryRun）
输入：当前活动文档或指定文档。输出：条目化问题列表。文档变化：无。失败时可能是模型未配置，
确认写批注
输入：你对预览列表的确认口令。输出：WPS 批注窗格出现批注，锚点尽量落在具体文字。文档正文：不改字。未确认就要求写批注，常遇到确认门禁。
确认替换
输入：按条或按批的确认替换口令。输出：正文发生替换。范围：仅确认过的条目。未确认的大段写回应被拒绝或仍停在预览。
推荐操作顺序
确认口令建议固定
可用口令：
- 确认写批注。
- 确认替换。
- 按第 2、4、6 条确认替换，其余只保留批注。
不要用含糊的「行」「改吧」「你看着办」。门禁认的是明确确认，不是语气同意。
批注锚点与表格
正文批注应落在错字或词组上，而不是整段漂到邻句。表格中应钉在单元格内具体文字，禁止整格挂靠。预览阶段若发现定位文本过短或重复多次，先让 Claude 补充上下文再确认写批注。锚点抽查失败时，不要进入确认替换。
CONFIRMATION_REQUIRED 怎么处理
含义：当前调用想执行写操作，但缺少确认。正确处理：回到对话，发出明确口令；不要同一秒改 MCP 配置。若你本意只要预览，说明提示词没写清，补一句「不要写批注，不要改正文」。
误操作后的回退
若已经发生不想要的替换：立即停止继续确认；用另存副本或版本比较找回；检查开场白是否缺少禁改声明；下一轮强制 dryRun。重要稿请在第一步就另存，不要指望智能体提供撤销语义。
验收标准
- 预览列表含原文片段与建议，不是空摘要。
- 确认写批注后，批注条数与抽查锚点匹配预期。
- 未确认的条目正文未变。
- 确认替换仅作用于点名条目。
- 另存文件名可追溯。
与加载项检查的关系
加载项内拼写与语法检查适合短文快检，也会写批注。Claude 路径适合多步确认与多文档。两条路径都要遵守「先看问题再接受写回」。不要一边在加载项点检查、一边在 Claude 确认替换同一段，以免批注与正文状态交错难读。
把 dryRun、确认写批注、确认替换当成三条独立命令来用，自动审查才稳定。MCP 地址仍是 http://127.0.0.1:62588/mcp；协议说明见 https://code.claude.com/docs/en/mcp；源码仓 https://github.com/zhgyuhuii/chayuan.git。
人在回路如何落成科室约定
「先预览再确认」可以写成三条科室规则。第一，未经预览列表，不得口头要求智能体「直接全部改正」。第二，写批注前必须有人看过列表并回复确认口令。第三，替换改正文必须按条或按批确认，并另存已校对副本。这三条与产品的 confirmed 门禁一致，培训时用同一套口令，减少学员发明同义说法导致门禁未触发。
抽查锚点建议固定动作：打开批注窗格，随机点三条，看高亮是否落在错字上；表格稿再加抽两条单元格内批注。抽查失败则禁止进入确认替换。合同数字、日期、甲乙方名称出现在问题列表时，即使建议「看起来更通顺」，也要人工核对业务含义，不能只看错别字规则。
误报、漏报与版本差异
误报常见于专有名词、地名谐音、行业缩写。处理方式是在列表里剔除，而不是为了「清零」强行确认替换。漏报常见于超长段落未分块、扫描件未识别文字、文本框游离于主文档故事。漏报时补跑分块审查，或回到加载项对选区再检一次。不同小版本工具参数名可能微调，但 dryRun 预览、确认写批注、确认替换三态不应消失；若某版界面把按钮文案写得不同，以是否改动了正文为准做验收。
dryRun 结果怎样才算能用
一份能用的预览列表，每条至少能回答三个问题：错在哪句或哪个词，建议改成什么，为什么要改。只有「第三段有问题」这种粒度，不足以支撑确认写批注，更不足以支撑确认替换。遇到空洞列表，追加要求：按条输出原文片段与建议，不要只给段落大意。若模型仍然空洞，回到模型配置文检查模型能力，而不是强行确认。
预览列表建议你在对话里做标记：误报、必须批注、必须替换。你自己的标记不会自动传给工具，但能约束你下一步口令写得更精确，例如「按第 2、4、6 条确认替换」。
写批注与改正文的责任不同
写批注的代价低：正文不变，审稿人仍可在 WPS 里采纳或忽略。替换的代价高：正文已变，若锚点漂移，错字可能被「正确替换」到错误位置。因此默认策略是：大多数条目停在批注；只有高置信、锚点抽查通过、业务含义无歧义的条目才确认替换。合同金额、日期、当事人名称，即使错别字检查认为要改，也要人眼核对业务含义。
科室若需要更严的规则，可以直接规定：自动审查只允许到确认写批注，替换一律人工在 WPS 里改。产品门禁支持你停在第二态。
长文与分块时的三态
长文一次全文校对可能触发超时或 DOCUMENT_TOO_LARGE。正确做法是按章节或按块预览，每块单独确认写批注，最后再决定是否替换。不要在第一块还没抽查锚点时，就对全文发出确认替换。分块审查时，开场白里写清当前块范围，例如「只审第三节，先预览」。块与块之间保持同一确认纪律。
多文档串行时的活动文档陷阱
工具操作的是当前活动文档。刚打开另一份文件后，若 WPS 焦点仍停在旧文件，预览会跑到错误目标。口令里先要求「确认当前活动文档文件名」，与标题栏核对，再预览。多文档场景的提示词见第五篇。每一份文档都要单独走预览与确认，不能假定上一份的确认口令会延续到下一份。
批注窗格抽查动作手册
打开批注窗格。按列表点第一条，看高亮是否落在预览给出的原文片段上。再随机点一条位于文中部的批注。再点一条靠近文末的批注。表格稿额外点两处单元格内批注。五次里若有两次落点明显偏离，停止确认替换，回到预览并要求更严格的锚点说明。把抽查结果记在稿纸上即可，不必写长报告。
与加载项按钮同时使用时的秩序
可以先在加载项里快检，再在 Claude 里做多步确认；也可以只走 Claude。不要同一分钟内两边都对同一段落执行写回。若加载项已经写过批注，Claude 再写一批，窗格会变拥挤，抽查变难。建议选定主路径：短文用加载项；长文与多文档用 Claude。混合使用时，写回前先清理或接受已有批注状态。
失败案例复盘模板
记录四项：当时处于预览、写批注还是替换；完整口令原文；WPS 中观察到的变化；错误码或现象。复盘时先看口令是否含糊，再看锚点是否抽查，再看模型是否给出空洞列表。多数事故能归到「跳过预览」或「未抽查就替换」。把这两条写进科室约定，比再买一个更大模型更有效。
把三态练成肌肉记忆
第一句永远是预览。第二句永远是明确确认写批注。第三句才是按条确认替换。中间插入抽查。结束时另存已校对副本。五步走熟以后，工具名怎么变都不会乱。门禁报 CONFIRMATION_REQUIRED 时，微笑着补口令即可，无需重装。
预览列表的人工标记符号
可以在对话里用简单标记加速确认。例如对模型输出的编号列表回复：第 1、3 条误报忽略；第 2、5 条确认写批注；第 4 条确认替换。然后分别发送对应口令。不要指望一条含糊消息同时完成忽略、批注、替换三种动作。门禁按写操作类型触发，口令越干净，工具参数越好构造。
若条目很多，先确认写批注落完全部必须保留的意见，再开第二轮只处理替换。两轮之间抽查锚点。替换轮只引用仍有效的编号，避免沿用已过时的预览编号导致改错位置。
版本差异下的验收底线
小版本可能调整工具参数名或返回字段，但验收底线不应变：未确认不改正文；批注可抽查；替换可按条；错误码 CONFIRMATION_REQUIRED 应能通过明确口令解除。若某版本出现未确认就改字，视为缺陷，停止在该环境处理正式稿，并保留对话与文件另存证据。正式稿环境只使用通过底线验收的版本。
评论前必须登录！
注册