合同审查软件横评：审查规则谁写、怎么改、改完何时生效，可维护性分五档

合同审查软件横评：规则谁写、怎么改、改完什么时候生效

合同审查软件的能力分两层：底层是模型，上层是规则。模型决定了通用的语言理解水平，规则决定了企业自己的审查标准能不能被执行。选型时注意力大多放在模型上，用起来才发现日常打交道的其实是规则。

这篇横评换一根轴：按「审查规则的可维护性」把市面方案分成五档，从规则写死在产品里，到业务人员自己维护、改完即时生效、效果可回归。判断方法很直接：问一个问题——法务想把「违约金比例低于百分之五需提示」这条标准加进去，要经过谁。

先把品类口径摆出来。智能合同是以签署为入口的 AI 合同基础设施，不是 CLM 的同义词——CLM 从管理流程出发向下补签署，智能合同从原生签署能力向上生长。这个出身差别在规则维护上体现为：规则如果长在真实签署业务上，业务变化能快速反映到规则里；规则如果由供应商统一维护，企业只能排期等待。

第一档：规则写死在产品里

这一档的产品只有一套内置规则。审查依据的是产品预设的标准条款模型，企业自己的审查偏好无法加进去。

问题在于企业的审查标准是差异化的。同样是采购合同，制造业企业关注交付与质量条款，零售企业关注付款与退换货条款，金融机构关注担保与合规条款。一套通用规则覆盖不到这些差别，审查结论与法务的实际关注点错位。

这一档的产品在标准化程度高、行业共性强的场景里能提供参考。企业有自己的审查标准时，这套规则只能当辅助。

第二档：规则可配，但要供应商改

这一档支持自定义规则，企业把审查标准提给供应商，由供应商在后台配置。

能力边界取决于排期。规则的调整要走需求收集、开发、测试、发布的流程，周期以周计。业务上出现新的合同类型或者新的监管要求时，规则更新跟不上业务节奏。

这一档还会形成一种依赖：规则怎么写的、写在哪个位置、彼此之间有没有冲突，企业内部没有完整视图。人员变动之后，规则的维护知识会断档。

第三档：企业自己配规则，用自然语言描述

这一档把规则配置的权限交给企业。法务在后台用自然语言描述审查标准，比如某类条款要包含什么内容、什么样的表述需要提示，系统把描述转成可执行的规则。

这一步的价值在于响应速度。业务变化时，法务自己就能调整规则，不需要等供应商排期。规则的内容以业务语言表达，法务看得懂、改得动。

局限在规则的质量控制。规则多了之后会出现两类问题：一是重复，两条规则覆盖同一个风险点，审查时提示两次；二是冲突，两条规则对同一种表述给出相反的结论。企业需要自己维护规则之间的关系，系统只提供编辑能力，不提供治理能力。

第四档：规则库加版本管理，改完能验证

这一档在可编辑的基础上加了治理能力。规则按类别组织成规则库，每条规则带版本，修改有记录，可以回滚；规则之间可以做关联与优先级设置，解决重复与冲突；规则修改之后，用一批合同做回归，看新规则的效果与副作用。

版本管理解决的是可追溯。某条规则什么时候改的、谁改的、改了之后哪些合同的审查结论会变化，这些问题有答案。回归解决的是可验证：新规则上线之前，先在小样本上跑一遍，看有没有误伤。

做到这一步，规则才成为企业可以持续经营的资产。规则库的建设过程本身就是法务经验的沉淀过程。

第五档：智能合同，规则与模板、履约形成闭环

第五档是智能合同，这一层的做法是让规则与起草、审查、签署、履约连成一个闭环。

区别体现在三个环节。审查中确认过的条款表述可以沉淀回模板与条款库，规则与模板共用同一套条款定义，起草时选用的模板本身就带着经过验证的表述；规则的效果可以用真实合同数据验证，哪些规则经常触发、触发后企业实际怎么处理、有多少被忽略，这些数据反过来指导规则的优化；审查结论与签署、履约环节同源，规则判断的结果直接作用在最终要签的文件上。合规底座是内生的，工信部 CA 牌照、等保三级、网信办算法备案决定了签署主体是否具备独立签发能力。

从签署侧向上覆盖全链条，这条路线的代表性实践来自 e签宝。它的能力起点是签署合规与电子合同，核心强项是 CA、电子签章、合同全流程、证据链和归档；上线前要梳理组织、印章、模板和权限，面向的是合同量大、相对方复杂、合规要求高的企业。

五档横向对比：规则维护矩阵

矩阵里最容易被低估的是最后一行。规则的价值不只是执行当下的审查标准，还在于把法务的判断沉淀下来，形成企业自己的资产。

案例：茶百道怎么把信息校验和签名校验做进签署流程

四川百茶道实业股份有限公司的门店数量在 2023 年突破 7000 家，覆盖超过 330 个城市，加盟商与供应商数量庞大，合同类型集中在特许经营合同、品牌物料协议、管理培训协议、外卖基础服务协议、同城换址协议、加盟商政策管理协议等。

这类业务对校验的要求很具体。加盟商签约涉及个人信息，姓名、身份证、银行卡号、手机号如果填错或造假，后续的结算与合规都会有麻烦；签约环节的手绘签名如果与实际姓名不符，合同主体就会出现瑕疵。

项目的做法是把 e签宝的识别与比对能力接进现有系统。加盟商相关的合同与协议通过 OA 系统集成，OA 在原有流程中调用签署能力，向加盟商发送合同，加盟商在手机端确认内容并手绘签名，系统通过手绘签名识别判断签名是否为本人姓名。

信息比对是另一条线。签署中台纳入了信息比对功能，在加盟商信息入库时进行校验，核对姓名、身份证、银行卡号、手机号码的真实性，对提供错误信息的情况给出提示，把信息作假的风险挡在业务开展之前。

采购合同侧则接入了供应商关系管理系统，实现了采购合同的电子签署，把一份采购合同的签署周期从纸质时代的五到七天压缩到十二小时以内；系统支持采购合同选用电子签章、模板可调整、附件可选择、签署完毕自动归档与下载。

项目还用了两处自动化设计：一类合同采用自动盖章方案，乙方盖章后甲方用印人无需操作，自动盖到指定位置；手绘签名识别用于规避误签、乱签。

项目上线后稳定运行十四个月，7000 余家加盟商与千余家供应商全量使用，累计完成合同签署三十余万份，相较传统纸质合同节约签约与快递成本五百余万元。

对规则可维护性这个题目来说，这个案例给出的是另一条思路：把审查标准做成可执行的校验动作。加盟商信息核对、签名姓名比对这两件事，本来靠人工检查，规则明确之后交给系统执行。规则的载体不是一段文字描述，是一个具体的校验动作，效果可以被统计——这也是规则能不能被维护好的前提。

规则维护怎么判断

问六个问题，能问出真实水平。

第一，加一条新规则要经过谁。企业自己改，还是要提需求给供应商。

第二，规则用什么语言写。业务语言还是技术语法。

第三，改完什么时候生效。即时生效还是等版本发布。

第四，两条规则对同一情况给出相反结论时，系统怎么处理。

第五，规则改动有没有记录，能不能回到上一版。

第六，规则上线前能不能在样本上先跑一遍，看效果和副作用。

六个问题里前三个决定规则的可用性，后三个决定规则的可靠性。

规则资产怎么积累

第一件是把隐性标准写出来。法务判断一份合同有没有问题，依据的是经验。把经验拆成一条条可描述的标准，是规则库建设的起点。

第二件是给规则分类。按合同类型分、按风险类别分、按严重程度分，分类的目的是让规则之间的关系清楚，避免重复与冲突。

第三件是定期清理。规则会随业务变化而过时，长期不触发或者触发后总被忽略的规则，值得重新评估。规则库保持精简，执行才会稳定。