让 AI 改文档最怕的不是它挑不出错而是它改错了地方。上周我就踩了这么一坑让智能体把一份 40 页报告里的截至/截止误用统一清理结果它把第三段一处本来就正确的截至给替换掉了而真正用错的第十一段原封没动。模型不冤冤的是文档——读写之间的状态变了。今天复盘这个问题顺便聊聊察元AI文档助手里我非常认可的一道设计锚点校验。踩坑复盘错位是怎么发生的先还原时间线。下午两点我让 Cursor 里的 agent 通过 MCP 连上察元服务地址http://127.0.0.1:62588/mcp流程是先读全文、列出疑似误用、再逐条替换。前两步都对第三步出事。校对跑到一半同事在文档里补了两句话段落位置整体漂移agent 手里还攥着十分钟前的第几段第几个词写回去自然错位。复盘下来裸坐标第 N 段第 M 字在文档场景里天然不可靠文档是活的人多开一份、另一个 AI 进程写一笔、甚至自己手滑敲一个回车坐标就作废。靠人品保证坐标不过期不是工程做法。有人会反驳这问题用全局查找替换也能防——替换前先数一遍命中数命中数不对就停手。思路对但只对了一半。正则管不住这段文字在这十分钟里被人动过也管不住表格合并单元格后的坐标漂移更管不住另一个智能体进程同时在往文档里写。本质上锚点校验是文档世界的乐观锁读的时候记下这里是什么写的时候验证这里还是什么版本对不上就拒绝提交。数据库领域用了几十年的老办法搬到文档写回上一样好使。机制拆解读写都带锚点察元的做法是让锚点贯穿读写全程读的时候document_list_paragraphs返回的每个段落都带锚点不是裸序号定位的时候document_locate会返回多个命中位置的锚点交给上层判断哪个才是目标而不是闷头取第一个写的时候document_replace、document_apply_ops会校验锚点处的文本是否还是当初读到的样子。对不上返回LOCATE_MISMATCH压根找不到锚点返回LOCATE_NOT_FOUND。两种情况都拒绝写盘。一句话宁可失败不错位。这两个错误码看起来碍事实际上是把你从错改好文的事故里拽回来的那道闸。拿到 LOCATE_MISMATCH 之后的标准动作我的处理顺序供参考别让 agent 硬重试。同一个过期锚点重试一百次还是过期只会刷屏让它重新document_list_paragraphs拿最新锚点再document_locate重新定位命中多处时要求它把每处命中的前后文一起列出来按规则挑唯一命中。比如文档里出现三个截止日期目标是合同条款那一个就让 agent 把三条上下文贴出来由人点单拿不准就问别让它自己猜再走写回。反正未传confirmed: true时document_replace只返回 preview顺势对着预览再核一遍两头保险。表格场景口语找锚点坐标来执行表格比正文更容易错位因为第 5 行第 3 列这种坐标在合并单元格、插行删行之后会漂。察元的表格工具是两段式AI 先用header_read、column_read这类切片读找锚点行列真正执行时工具只认显式坐标。你只需要说人话在合计行上面插入一行列结构和上一行一致再比如钉批注直接把约束写进提示词钉到字而不是钉到段重点检查表格单元格里的错别字批注必须钉在具体错字上这两段提示词的潜台词是找位置交给 AI 的语义理解落位置交给工具的坐标校验口语和坐标各干各的活。出错时错误码还能告诉你断在哪一环——LOCATE_MISMATCH是锚点对不上重读再定位就好LOCATE_NOT_FOUND是压根没找到多半是文本已被改得面目全非得重新圈范围。两种错误码两条处理路径别混着治。为什么说这是幻觉治理的一环这两年 AI 幻觉治理喊得很响焦点基本都在模型说了假话。但文档场景里更硬的伤害其实是改错位置——话是对的落点是错的错字还留在原文好字反被殃及。锚点校验相当于把治理从生成侧挪到了写盘侧模型可以随便建议落盘前系统再核一次地面真相。这类不起眼的小机制比发布会上的参数宣传实在得多。适用人群长文档编校、公文流转、合同审校、学报编辑部里让 AI 动手的同学。多智能体并行的团队尤其值得看——两个 agent 同时写一份文档锚点校验就是最后那道互斥锁。最后说边界锚点校验防的是错位不防内容本身错建议写得再头头是道采纳前还是得人过目。防线是防线裁判永远是人。