一位开发者正在构建基于大模型的 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 的定位与写入能力。主流办公软件的在线 SDK 普遍缺乏面向 AI 场景的语义锚点和模糊匹配接口，迫使开发者用字符串匹配这类脆弱方案兜底。从技术走向看，可行路径包括让模型基于带行号或段落标记的文档快照直接输出结构化编辑指令，绕开原文回查；或由办公软件厂商在 SDK 层面提供 AI 原生的编辑 API。后者意味着 WPS、微软等厂商若想承接 AI 办公浪潮，SDK 的开放程度将成为关键竞争要素。类似痛点在 PDF、协同文档等格式上同样存在，是 AI 应用落地’最后一公里’问题的缩影，值得关注 SDK 生态与模型能力的协同演进。
核心观点：AI 办公的最后一公里不在模型能力，而在文档格式与模型输出的精确对齐，SDK 生态的工程化程度将决定 AI 编辑工具的成败。
原文链接：Linux.do
