一份 200 万的采购合同,我让 AI 挑出 11 个问题

14 分钟
SKILLAI工程化产品
一份 200 万的采购合同,我让 AI 挑出 11 个问题

AI 审合同最该担心的不是它不够聪明,而是它一本正经地指出合同里根本不存在的问题。

今天就和大家推荐一款能够节约任何买方采购单位时间和降低采购阶段风险的开箱即用工具:

站在买方立场,在签约前把一份采购合同逐条审一遍,把风险、原文依据和修改建议列成一份可以逐条处理的报告。一份采购合同真正危险的,往往不是看着吓人的条款,而是你以为没问题、一眼扫过去根本不会停的地方。

这个 skill 的做法是双轨。能用关键词和算数确定的,交给代码——结果可重复、零漏报。需要判断“这句话对谁有利”的,交给大模型,但每条意见必须带原文摘录,检索不到就丢弃。

最终交付给采购部门一个可视化的采购合同审核报告,清晰呈现高、中、低风险预警。

一份 200 万的采购合同,我让 AI 挑出 11 个问题

图 1 一份 200 万设备采购合同的审核报告概览(3 高 / 6 中 / 2 低,11 项命中,其中 3 项金额问题)

一、买方审合同的难,不在看不懂,而在量大、重复、容错低

一个采购岗每周要过好几份合同,供应商还各不相同。

逐字看,时间不够;扫着看,又怕漏。更麻烦的是供应商回签的改版——对方改完发回来,你还得逐行对比,看他动了什么。卖方拿到合同签就是了,买方却要把这一关反复过。所以这个 skill 从一开始就固定站在买方。

这份 200 万的设备采购合同,问题集中在四类地方。

第一类是已经失效的依据。合同开头援引的是《中华人民共和国合同法》。这部法律在 2021 年 1 月 1 日《民法典》施行时就废止了,合同的订立、效力、履行都该改引《民法典》。还在引用废法,说明这份文本没有跟着法律更新。

第二类是一边倒的表述。“乙方设备安装调试中操作不当造成的任何损失,甲方概不负责”“本合同的最终解释权归乙方所有”“乙方在履约中知悉的商业秘密可任意使用”。这些话写进去,争议时多半被认定为无效的格式条款,但它会让你在谈判里失去立场。

第三类是数字和期限偏离了常见区间。预付款 80%(参考线 50%)、见票后 180 天付清(参考线 60 天)、乙方逾期交货违约金 0.5%/日(参考线 0.1%/日)。这些阈值不是法律红线,是行业常见水平,企业可以按自己的采购政策调,但偏得这么远,本身就是一个信号。

第四类最容易漏,是数字本身对不上。“贰佰万元整”和括号里的 1,800,000,同一份合同写了两个数,差 20 万。未必是有人使坏,多数是合同抄改时留下的笔误。可真到付款,按大写还是按数字,就是一场纠纷。

一份 200 万的采购合同,我让 AI 挑出 11 个问题

图 2 命中卡片:援引已废止的《合同法》、单方免责表述、金额大小写不一致

二、这个 skill 的逻辑:不做“丢给大模型自由发挥”,把审核拆成一条流水线

不少人对 AI 审合同的想象,是把文件丢给大模型,等它输出一段意见。我没有这么做。大模型理解能力强,但结果不稳定,同一份合同今天审和明天审可能给出不一样的结论;合同审核恰恰要求可重复、可追溯。

我把它做成了一条固定流水线,每一步做什么、由谁判定,都固定下来。

合同进来,先做规则包自检和热加载,每次审核都重新扫描规则,不读缓存。然后解析切块,按章、条、节拆开,每一块记录字符偏移,后面发现问题能精确定位到第几条。切块之后分两条轨道走,最后汇总、排序,生成一份单文件 HTML 报告。

一份 200 万的采购合同,我让 AI 挑出 11 个问题

图 3 端到端审核流程(F1→F8,代码硬规则与 LLM 语义双轨)

1. 确定的归代码,需要理解的归模型

这条流水线的核心是双轨。

能用关键词和算数确定的,交给代码:失效法规、违禁表述、必备要素缺失、比例期限是否超阈值、金额对不对。这些是字符级匹配,跑一百遍结果一样,要求零漏报。

需要读懂意思的,交给大模型:权责对等不对等、知识产权归谁、约定有没有效、条款要件齐不齐。这些没法靠关键词,要理解“这句话对谁有利”。

规则包一共 12 条规则,配 34 条法条依据。判定方式分四种:硬匹配和数值验算走代码,要件核验和语义理解走模型。每条命中的规则,都能在报告里折叠展开对应的法条,标注现行还是已废止。

2. 又为什么不能全交给大模型

大模型最大的风险是幻觉——它会一本正经地指出合同里根本不存在的问题。

我给它加了一道硬约束:模型输出的每条意见,必须带上章节定位、原文摘录、命中规则和修改建议。摘录必须能在合同原文里检索到,检索不到,这一条直接丢弃。原文没写的,一个字都不许说。遇到超出规则范围的复杂情形,它只能标“建议人工复核”,不许硬判。

另一道约束是透明。报告里不只列命中的问题,“已检查但没发现问题”的规则同样列出。这份问题较多的合同,有 8 项规则没发现问题;而一份写法规范的软件开发合同,报告长这样——

一份 200 万的采购合同,我让 AI 挑出 11 个问题

图 4 良好合同只报 1 项(分项合计 75 万≠总价 80 万),12 项规则未发现问题

12 项规则未发现问题,只挑出 1 个真问题:分项金额 20 万 + 35 万 + 20 万 = 75 万,合同总价却写 80 万,差 5 万。

这一点我很在意。审核工具乱报,比不报更消耗信任。如果每跑一次都要从误报里逐条筛,用两次就不会再用了。

3. 规则不是一次写成的,是被真实Badcaase一条条补出来的

合同审核过程中比较容易遗漏的一项是合同的分项结构,因为合同撰写时的颗粒度各不相同,有些有分项结构、而有些没有。

如果合同里根本没有分项结构,只有“预付款 160 万、含税价 190 万”,程序却硬把它们当分项相加,就能报出几百万差额。为此,我加了一道结构前置校验,没有明确的分项引导语和明细行,就不启动分项核对。这里我宁可漏报,也不误报——金额上报错一个数字,整个工具的可信度就没了。

币种也一样。早期只认 ¥、$ 这些符号,合同里写“人民币”“美元”两个汉字,它就完全静默。补齐中文币种名之后,这份合同里“人民币报价、美元单价”的混用才被抓出来。

4. 最该死板的事,交给代码

金额核对是最能体现“代码轨道”价值的部分,全是算数,不调模型。

它做四件事:大写和阿拉伯数字是否一致、分项加总是否等于总价、不含税金额按税率换算后是否等于含税价、同一份合同币种是否统一。

这份 200 万的合同,三项全中:

一份 200 万的采购合同,我让 AI 挑出 11 个问题

图 5 金额核对:含税换算不自洽(180 万×1.13=203.4 万≠190 万)、人民币与美元混用

大写 200 万对不上数字 180 万;不含税 180 万按 13% 算是 203.4 万,合同写的含税价却是 190 万;同一份合同还混用了人民币和美元。

5. 供应商回签后,到底改了什么

买方还有一个高频场景:供应商拿你的合同改完盖章发回来。逐行对比几十页,人眼很难保证不遗漏。

我专门做了版本对比。难点不是找出差异,而是去判断哪些差异影响最大,并做影响程度的排序。

它先在条款层面做最长公共子序列配对,即使对方把条款重命名、调顺序,也不会被误报成“删了一条又加了一条”。然后在词级做对比,精确到字。最关键的是排序:不按字符改动占比,而按实质影响打分——数字变化、主体翻转(甲方变乙方)、整句增减,权重最高。

一份 200 万的采购合同,我让 AI 挑出 11 个问题

图 6 版本对比:7 处修改、6 处高风险;付款改动占 2% 字符却按实质影响排在第一

结果是 0 新增、0 删除、7 处修改、4 处未变动、6 处高风险。排在第一的是付款条款:预付款 30% 被改成 80%、见票后 30 天改成 180 天。这一段改动只占全合同 2% 的字符,却排在所有改动最前面。

再看这一条:

一份 200 万的采购合同,我让 AI 挑出 11 个问题

图 7 管辖权“甲方所在地→乙方所在地”,只动一字、占比 2%,仍按实质影响置顶

“甲方所在地人民法院”被改成“乙方所在地人民法院”,只动了一个字,改动占比 2%。但它决定了将来打官司你要去哪个法院。按字符占比排,这种改动会被埋到末尾;按实质影响排,它必须顶在前面。

金额、付款、交付验收、违约责任、权属保密、争议解决,这六类字段一旦改动,报告会单独标注高风险,建议优先复核。

6. AI 只出意见,采纳权在人

整条流程里,我把边界划得很清楚:AI 只负责出意见,不替你拍板,最终的合同的责任方还是归属负责人。

报告里每条建议都可以接受、拒绝或编辑。只有你勾选“接受”、再点生成按钮,才会导出一份修订说明,原始合同文件一个字都不会被覆盖。报告是单文件 HTML,双击即开,顶部印着规则包的名称、版本和生效日期,日后能追溯“当时是按哪一版规则审的”。

三、换个场景还成立吗:三个测试,和它做不到的事

为了验证它不是只在一份合同上有效,我用三个典型场景做了测试。

设备采购合同问题最多,11 个,前面已经讲过。软件开发合同写法规范,只报了 1 个分项金额对不上的问题,证明它不乱报。我还特意写了一份 254 字、要素大量缺失的简式合同:

一份 200 万的采购合同,我让 AI 挑出 11 个问题

图 8 254 字简式合同:4 高 6 中、10 项必备要素缺失,定位均为“全文(未检出)”

它标出 10 项必备要素缺失,4 高 6 中——主体、验收、违约、争议解决这些关键条款一个都没有。这证明另一个方向:合同简单到只有几句话,它也能覆盖,不会因为没关键词就放过。

它适合每天要过合同的采购、法务和业务负责人,签约前花一分钟自查;也适合想把专家经验沉淀成可版本化、可回归规则的团队。

四、总结

这篇讲的就是把签约前的合同审核拆成双轨。代码负责字符级硬规则:失效法规、违禁表述、必备要素、阈值验算,零漏报;大模型负责语义规则:权责对等、归属、约定有效性,但每条意见必须带原文摘录,检索不到就丢弃。规则是文本数据、可版本化,每条建议由人决定去留。

往上一层看,这是「规则归数据、判断归模型、决策归人」在合同场景的落地。真正的痛点不在模型够不够聪明,而在错误成本:审合同低频高损,漏一条可能赔几十万,误报一条又会让工具被弃用。这类工具的门槛不是能力上限,而是可信度下限——不乱报、可溯源。模型越强,这条底线越值钱。

如果你每天也要过合同——采购、法务或者业务负责人——可以直接拿去用:上传一份合同,一分钟左右拿到一份带章节定位和原文依据的风险清单,签约前自查一遍。它已经在 WorkBuddy 的技能市场上架,搜「采购合同审核」就能装: https://skillhub.cn/skills/user_79dc15b5/procurement-contract-review

也可以直接复制给你的Agent安装:请根据 https://skillhub.cn/install/skillhub.md,安装 @user_79dc15b5/procurement-contract-review。