去年年底有个周五我记到现在。下午四点五十业务同事抱着三份文件站在我工位旁边主合同、补充协议、技术验收单用印申请已经批了就等法务最后过一眼。三份文件讲的是同一笔交易但关键数字在三处出现主合同写 128 万补充协议里调整过一次验收单上还有一个数。哪份是准数含税还是不含税附件编号对不对得上那晚我对着三份文件逐页核数字核到第三遍才确认补充协议里的一处金额是笔误——但没人敢保证第四遍会不会再翻出新问题。后来部门上了察元AI文档助手同样的事再没让我加过班。2026 年被叫做 AI Agent 办公落地元年落到法务这个工种最先被智能体接走的恰恰是多文档交叉核对这种最磨人的活。这套流程值得展开讲讲。交叉校对是怎么跑的察元的本机 MCP 服务起了之后浏览器访问 http://127.0.0.1:62588/healthz返回 online 即正常可以让 Claude Code 这类外部智能体通过 MCP 直连 WPS一份指令操作多份已打开的文档。核心是 46 个文档工具里的读取与定位能力document_list_paragraphs 列出带锚点的段落document_locate 按条款名定位并返回命中锚点发现差异后用 document_add_comment 写批注必须显式 confirmed:true 才落盘。三份合同对数字我用的提示词是这条打开当前这三份合同文档交叉核对同一笔交易的以下信息是否一致合同金额与含税口径、付款节点日期、甲方乙方名称、合同编号与附件编号、版本号每一处不一致用批注钉在原文位置并说明另外两份文件里对应写的是什么。这条指令的关键是钉在原文位置。交叉核对的输出如果不落到具体段落上法务还得自己翻第二遍等于白干。数字类再加一条勾稽核对合同正文金额与付款表格合计是否一致大写金额与小写金额是否一致各期付款比例合计是否为 100%。表格侧有 12 个表格 actionheader_read、column_read 能按列读数AI 不必把整张表当纯文本硬啃定位合计行这类锚点也更稳。为什么敢信它的输出说白了就是防幻觉设计。定位不到会直接报 LOCATE_NOT_FOUND锚点校验失败会报 LOCATE_MISMATCH而不是硬编一个位置批注钉在具体锚点上一键就能跳回原文核对。“AI 幻觉治理这个词听起来很大落到文档场景其实很朴素宁可报错不可编造每个结论都能回溯到原文。在合同场景里这一条比模型跑分重要得多——一个编造的第三份文件金额不一致”比漏报十条还伤信任。机器圈差异人来定对错跑完之后屏幕上七八条批注五分钟我就分完了补充协议金额与主合同不一致——真问题查往来函件确认以哪份为准验收单日期比主合同晚一天——业务确认为笔误改两份文件里乙方简称写法不同——统一成主合同口径。注意最后这一步判断哪个数是对的机器给不了答案它只负责把对不上全部摆到你面前。交叉校对是预筛定稿口径是法务的活这条分工线不能模糊。AI 找差异的能力再强也不构成对合同内容的法律判断更不替代律师审查。一点延伸那天之后多份文件交叉核一遍成了我们用印前的固定动作批注清零再盖章清零之前用 document_save 另存一版审查留痕和用印版分开存。法务的加班很多时候不是案子难是重复劳动把晚上占满了——把这部分交给本机跑的智能体合同不出域服务只监听 127.0.0.1模型可走 Ollama 本地端点、结果有锚点、人只拍板。第一次准点下班就是这么来的。