采购合同审核

一、为什么做这个项目

合同里的风险，几乎从来不是在签完之后才出现的，而是在签之前没人有时间逐条看完。

在企业里，采购合同的数量和法务的人手天然不成比例。业务部门等着下单，供应商催着回签，合同往往在流程末端才流转到法务手上，留给审核的时间可能只有半小时。于是审核动作被迫简化成两件事：看一眼金额和付款方式，确认没有明显离谱的条款，然后放行。

这件事真正的难点不在“看不出问题”，而在标准没有沉淀成可复用的东西。同一个风险点，今天张三审出来，明天李四可能就放过去了；上个月因为某个条款吃过亏，这个月的合同里又原样出现。经验留在个人脑子里，就无法被继承，也无法被验证。

所以我做了这个项目：一个采购合同签约前的风险审核助手。上传一份合同，它按既定规则逐条审一遍，产出一份可以直接交给法务和业务看的审核报告——每一条意见都带着“在哪一章、原文是什么、违反了哪条规则、建议怎么改”。

需要先讲清楚它的定位：AI 只出意见，采纳权在人。它不替代律师与法务的最终判断，不构成法律意见，也不直接改写合同正文。

二、痛点：合同审核卡在哪里

把这件事拆开看，卡点其实非常具体：

• 人手和时间不匹配——法务要覆盖全公司的合同，单份合同能分到的时间被压缩到极限，只能做抽样式的粗看
• 审核标准存在人脑里——哪些条款必须写、哪些表述是雷区，靠口口相传，没有可以复核的清单
• 同类问题反复出现——上次踩过的坑，因为没沉淀成规则，下一次换个人、换份合同又踩一遍
• AI 审完不敢用——大模型能说出一堆“存在风险”，但说不清依据在哪一段，业务方拿着意见也没法改
• 审过什么没有留痕——事后追问“当时是按什么标准审的”，往往拿不出证据

其中最要命的是第四条。一份无法溯源的审核意见，价值接近于零。 业务方需要的是“把第 8.2 条的付款比例从 30% 改到 10%”，而不是“建议关注付款风险”。

我的判断是：合同审核的瓶颈不是缺少智能，而是缺少一套可被复核、可被继承的审核标准。

三、设计思路：把「审核标准」和「审核引擎」拆开

这个项目最关键的一个决定，是把原本混在一起的两件事彻底分开：

审核标准，是规则；执行审核的，是引擎。规则以文本形式独立存放，引擎只负责读取和执行。

这个拆分带来了后面所有的设计。展开说六点。

1. 规则是数据，不是代码

规则不写在程序里，而是以独立的文本文件存在，一条规则一个文件，可以随时新增、修改、停用。

这意味着：改规则不需要动引擎，也不需要有工程师参与。法务同事新增一条“尾款比例不得超过 10%”的规则，保存之后，下一份合同就会按新规则审——规则在每次审核开始前重新加载，不存在“改了要等明天才生效”的情况。

规则还带版本号、生效日期和来源依据。这样做的价值在事后：任何一份历史报告，都能回答“当时是按哪一版规则审的”。

2. 双轨审核：确定性归代码，语义归模型

不是所有条款都适合交给大模型判断。可判定的问题应该用确定的方式解决，需要理解的问题才交给模型。

判定方式	适合审核的内容	漏报要求
字符匹配（代码）	援引已废止或被替代的法规、明显违禁表述	零漏报
阈值验算（代码）	账期天数、尾款比例、违约金上限等数值越界	零漏报
要件核验（模型）	必备条款是否齐全、表述是否具备可执行性	尽量不漏
语义理解（模型）	权责是否对等、成果归属是否清晰、约定有效	尽量不漏

援引失效法规、必备要素缺失这类问题，一旦漏掉就是硬伤，因此必须用字符级精确匹配来做，不交给模型，结果确定且可以重复验证。 而“这份合同的违约责任是否对等”这类判断，字符匹配做不了，才交给模型，并要求它按固定结构给出结论。

阈值类参数（尾款比例、违约金上限、账期天数）也不写死在引擎里，而是放在规则包的词表里，企业可以按自身的采购政策调整。默认值只是行业常见参考，不构成硬性法律标准。

3. 每一条意见都要能被翻回原文

这是整个项目最硬的一条约束：任何一条命中项，都必须同时给出四要素，缺一不可。

• 章节定位——问题出在第几章、第几条
• 原文摘录——合同里原原本本的那句话
• 命中规则——违反了规则包里的哪一条
• 修改建议——具体怎么改，可以直接复制

并且，模型给出的原文摘录必须能在合同原文里检索到。检索不到的意见，无论看起来多合理，一律丢弃。这条约束专门用来对抗大模型的“编造引用”——没有原文依据的判断，不进报告。

遇到超出规则范围、无法可靠判断的复杂情形，它不会强行下结论，而是标记为“建议人工复核”。承认自己不确定，比给出一个错误结论更有价值。

4. 没命中的规则，也要说清楚

多数审核工具只报问题。但“这份合同有 3 个问题”这句话本身是不完整的——业务方无法判断这份合同到底被检查得有多彻底。

所以报告里既列命中项，也列已检查但未发现问题的规则。一份报告看完，能明确知道：12 条规则里，哪些命中了、哪些逐条看过了且没有问题。透明本身也是审核质量的一部分。

5. 采纳权始终在人

报告里的每一条建议，都带“接受 / 拒绝”的选择，并且建议内容可以直接编辑。审核结果不是一份不可挑战的判决书，而是一份待确认的意见清单——最终改不改、怎么改，由法务和业务决定。

6. 规则要能被运营，而不是一次性写完

规则包是一个会长期演进的资产，因此它必须具备工程属性：能回归测试、能灰度、能回滚。

新增或修改规则之后，要同时补正例（应当命中）和反例（不应误报）两类测试样例，跑一遍回归，确认新规则生效且没有引入误报，才算完成。状态为草稿的规则在审核中只作提示、不计入正式问题，用来小范围灰度验证。

四、一次审核的完整链路

从上传合同到拿到报告，是这样一条链路：

1. 上传合同——支持 Word、PDF、纯文本三种格式，按文件内容判断类型，不依赖后缀名
2. 解析与切块——按“第 X 章 / 条 / 节 / 附件”的结构切分，保留章节路径，为后续精确定位做准备
3. 规则包自检与热加载——每次审核开始前重新校验并加载规则包，规则格式有误会直接报错并定位到具体规则
4. 硬规则审核——字符匹配与阈值验算，不调用模型，结果确定、零漏报
5. 语义规则审核——逐条让模型按固定结构评审，原文摘录检索不到的一律丢弃
6. 汇总去重——合并两类结果，同一处问题归并；硬规则命中置顶，其余按严重程度排序
7. 生成审核报告——输出一份单文件、无外部依赖的交互式网页报告，双击即可在浏览器打开

报告页顶部给出合同名称、审核时间、规则包名称与版本、命中与未命中数量；每张命中卡片包含严重程度、规则编号与名称、章节定位（原文高亮）、问题说明、可一键复制的修改建议，以及接受 / 拒绝的勾选框。报告同时带有规则包版本与生效日期的标注，用于事后追溯。

需要强调的是：整个过程不会修改用户的原始合同文件，所有产出都写入新文件。

五、适合谁用，以及不适合做什么

适合的场景：

• 采购、行政、业务部门在提交法务审核之前，先做一轮自查，把基础问题挡在前面
• 法务人手紧张时，用于大批量合同的初筛，把人力集中在真正需要判断的条款上
• 把散落在个人经验里的审核要点，沉淀成一份团队共用的、可复核的规则清单

首发规则包面向企业采购合同，覆盖货物采购、软件与系统开发、服务外包、工程建设等常见类型。

不适合做的事情，也说清楚：

• 不代写合同、不代为签署
• 不出具法律意见书
• 不替代律师与法务的最终判断

报告中所有意见均为辅助性提示，采纳前请由法务复核。命中失效法规等硬规则的问题，建议优先处理。

六、复用与下一步

这套设计的真正价值，在于引擎与场景是解耦的。

换一个合同类型，不需要重做工具——复制一份规则包，改掉规则清单、词表和测试样例，引擎完全不动。劳动、租赁、保密、SaaS、营销合规等场景都可以用同一套引擎承接。

下一步我关注的是规则的持续运营：把每次真实审核中发现的误报和漏报，回流成新的测试样例，让规则包在使用中不断收敛。一个审核工具的好坏，最终不取决于它第一次有多准，而取决于它能不能越用越准。