做合同的人多少都见过那种案例合同里大写金额和小写金额对不上结算时双方各执一词最后靠交易习惯和证据链去推真实意思——一审二审折腾大半年起因只是起草时的一个数字。这类坑我踩过也见同事踩过这篇把踩坑过程和现在的查法摊开讲方便同行少走弯路。坑一大写不规范肉眼看着都一样人民币壹拾万元整规范大写要带壹。但合同里写成拾万元整的我一年能见到好几份——起草的人觉得意思没变审查的人眼睛一扫也觉得没变真到争议发生这种瑕疵就是对方律师的突破口。类似的还有小写侧千分位错位的10,0000、多敲一个零的1000000在长段落里都不显眼。人眼对这类看着差不多的字符串天然钝感尤其是审到第五版、晚上九点的时候。坑二三个地方三个数谁都不知道哪个是准数更常见的是勾稽关系断了正文写合同总价 96,800 元付款进度表各期合计 90,800 元附件报价单又是另一个数。每处单看都合理凑在一起才发现对不上。以前我们是三个人各查一遍再交叉对——费人而且照样漏。数字勾稽本质上是机器擅长的活确定性比对、无疲劳、口径一变就能原样重跑。现在让 AI 跑这条提示词核对这份合同的金额勾稽关系大写金额与小写金额是否一致正文总价与付款表格各期合计是否一致正文引用的附件金额与附件实际金额是否一致另检查含税与不含税口径是否标注清楚不一致处全部用批注标出原文位置。坑三让 AI 直接改正文差点把对的改错这是我自己踩的。第一次用的时候图省事让 AI把不一致的金额都改成正确的结果它盯上了摘要段里的一个数字——那段是引用历史协议的背景描述本来就应该写旧数。教训很清楚AI 知道哪里不一样但不知道哪里该不一样。从此我坚持两段式先跑校对的 dryRun 模式工具默认只返回问题清单不动正文先跑一遍校对dryRun汇总金额不一致的问题列表不要先改正文我确认后再写成批注。确认清单没问题后批注写回走带确认门槛的工具批量用 document_apply_ops一次上限 200 个操作超量就分批执行。批注钉在原文锚点上谁标的、为什么标留痕清楚复核的人点开就能看到上下文。坑外的坑别把合同传到在线工具上还有一类坑不体现在文本里为了省事把合同丢给在线校对网页。合同是公司最敏感的文件类型之一出域这个动作本身就违反大多数单位的保密制度。察元的方案是全链路在本机WPS 加载项加本机 MCP 服务只监听 127.0.0.1本机即信任边界模型接 Ollama 或 LM Studio 的本地端点合同从文档到模型全程不出这台电脑。这是我能把它推荐给法务同事的底线前提——数据安全不出域不是加分项是准入项。复盘之后的标准动作现在的金额复核固定四步。第一步dryRun 跑勾稽拿问题清单第二步逐条判断哪个数是准数查函件、查系统记录这一步必须人来第三步确认后写批注改数字一律人工动手或在人工监督下执行第四步用印前再跑一遍终检兜底。机器管找全人管判对——数字勾稽做得再细也是辅助手段合同金额的最终确认责任永远在法务手里。但至少那些低级的数字坑不会再漏到用印之后才被发现。适合把这个流程固化下来的是所有经手金额条款的岗位法务、合同管理、财务审核、采购经办。