让 AI 直接修订 Word 文档，为何卡死在文本精确匹配上？

一位开发者正在构建基于大模型的 Web 文档审阅应用，目标是让 AI 分析文档内容后，直接在 WPS 在线编辑器的修订模式下完成修改，用户可看到类似 Word 审阅效果的红色删除线与新增文字。技术栈采用 React 前端配合 WPS WebOffice JSSDK 嵌入式编辑器，后端为 Node.js，大模型调用走 OpenAI 兼容接口，支持流式输出与工具调用。实现方案上，开发者经过大量 API 测试后确定使用 Find.Execute 定位文本：由 AI 返回需修改的原文片段与修改后内容，通过 Find.Execute 获取精确位置和长度，开启修订模式后用 PasteHtml 替换内容，从而产生修订标记。之所以不用 Content.Text 的 indexOf，是因为 WPS JSSDK 返回的文本位置与 Range 真实位置存在隐藏字符偏移，无法用于定位。核心难点在于 Find.Execute 是精确匹配，而大模型输出的原文片段常与文档存在差异，包括换行符形态不一、中文序号有无或格式出入、全角半角空格差异，以及跨段落拼接导致无法命中。目前尝试的截短重试、去编号前缀、换行替换为空格等降级策略命中率仍不理想。此外还发现 PasteHtml 快速连续调用会并发导致重复插入，需加锁串行执行，JSSDK 异步代理对象直接赋值可能不触发远程调用。开发者希望寻找段落索引加偏移量等替代定位方式，并求证 Find.Execute 是否支持模糊或正则匹配。

事件分析

核心观点：AI 办公的最后一公里不在模型能力，而在文档格式与模型输出的精确对齐，SDK 生态的工程化程度将决定 AI 编辑工具的成败。