做合同的人多少都见过那种案例：合同里大写金额和小写金额对不上，结算时双方各执一词，最后靠交易习惯和证据链去推真实意思——一审二审折腾大半年，起因只是起草时的一个数字。这类坑我踩过，也见同事踩过，这篇把踩坑过程和现在的查法摊开讲，方便同行少走弯路。
坑一：大写不规范，肉眼看着都一样
人民币壹拾万元整，规范大写要带"壹"。但合同里写成"拾万元整"的，我一年能见到好几份——起草的人觉得意思没变，审查的人眼睛一扫也觉得没变，真到争议发生，这种瑕疵就是对方律师的突破口。类似的还有小写侧：千分位错位的"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 跑勾稽，拿问题清单；第二步，逐条判断哪个数是准数，查函件、查系统记录，这一步必须人来；第三步，确认后写批注，改数字一律人工动手或在人工监督下执行；第四步，用印前再跑一遍终检兜底。机器管"找全"，人管"判对"——数字勾稽做得再细也是辅助手段，合同金额的最终确认责任永远在法务手里。但至少那些低级的数字坑，不会再漏到用印之后才被发现。适合把这个流程固化下来的，是所有经手金额条款的岗位：法务、合同管理、财务审核、采购经办。
