规则 or Agent 驱动：一个合同审查系统的产品设计与工程拆解

这篇来拆解个前阵子投产的合同审查项目，在我年初出版的《RAG 落地之道：从工作流到企业级 agent》第 8 章里，也写过一个合同审查的完整 Case，当时是基于 Dify 实现的一套四阶段工作流，把 bad case 做结构化处理、构建可检索的案例知识库，再通过分步编排把复杂的审查任务拆解成独立可控的环节，用低代码的方式完整地演示了核心实现逻辑。

但那个版本更多是方法层面的演示，合同审查在生产环境部署的时候，不仅要结合特定的业务类型和业务特征来定制审查逻辑，还要和企业原有的 ERP、审批等系统做集成，以及对历史积累的合同类文档资产做深度的解析和治理。同时形成数据闭环，也才能越用越好用。

两个月前，我结合一些客户提出的合同审查类 Agent 需求，深度访谈了五家上市公司种子客户，同步和两家律所团队针对底层的审查逻辑做了进一步打磨。最后梳理下来，收敛了一个比较朴素的二八原则的做法。换句话说，80% 的标准化审查工作通过定制规则的 Pipeline 来实现，剩下 20% 通过侧边栏形式的 Agent 进行工程化的追问和处理。

视频链接：

规则 or Agent 驱动：一个合同审查系统的产品设计与工程拆解https://mp.weixin.qq.com/s/7luPQxmKnIEnJAPWBYrcmA

这篇试图说清楚的：

市场上主流的合同审查技术路线各自在做什么，以及分别解决了什么问题；Pipeline 的核心实现逻辑是怎样的，它和传统的 Agent 对话式审查有什么本质区别；基于历史合同内容和修订记录，在深度治理方面做了哪些工程探索；以及从这个场景出发，对模型与规则如何做有机结合的一些思考。

以下，enjoy:

1、市场上三种路线的合同审查

无论是和上市公司的法务负责人，还是和律所团队聊起来，在交流过程中我发现挺多人反复提到的需求有些明显共性，比如风险提示要能定位到原文，判断依据要有明确的法条或司法解释出处，不同审批人的批注或修订意见要能直接进入 WPS 这类在线协同编辑系统，以及最基础的审批流程还要能和现有的 ERP 或合同管理系统衔接。

在调研的同时，我也系统梳理了遍国内外主流的合同审查产品，国内和海外产品在整体风格和定位上还是有比较明显的差异，当然这背后可能和中美产业结构是直接有关。

总体来说，海外头部产品普遍拿到了大体量的融资，比如 LegalOn 累计约 2 亿美元，Ivo 完成 5500 万美元 B 轮，Luminance 完成 7500 万美元 C 轮，Harvey 更是以 110 亿美元估值融了 2 亿美元。

这种融资结果无疑让它们有资源在 Playbook、Agent 化和自动谈判等方向上做更深的投入。国内产品则更多走法务团队深度参与的交付路线，或者通过模板和规则资产的积累来降低边际交付成本。大致归纳下来，市场上分化出了三种做法。

1.1、法务团队深度参与，规则梳理本身是交付物

以幂律为代表，它主要交付的不是一个审查工具，而是由法律团队和实施团队深度参与企业审查规则的梳理、系统集成和业务适配。公开资料的说法是，幂律沉淀了约 300 个审查点、上千种合同要素，以及超过 30% 的员工具有法律背景。

尤其类似的是，海外的 Robin AI 也保留了专业服务与软件订阅相结合的方式。这条路无疑看起来很重，但它也确实解决了一个很现实的问题。就是很多企业本来就没有一套足够清晰的，可以直接交给系统执行的审查标准。把规则梳理清楚，把风险口径统一好，这件事本身就是很有价值的交付。

1.2、先积累内容和规则资产，再让 AI 执行

国内以秀合同为代表的，公开宣称拥有上万份合同模板、5 万多条合同条款和多年的审查规则积累，并在此基础上叠加了 CLM 流程、审查智能体和知识云。

海外市场例如 LegalOn 和 Spellbook，走的都是类似路线，把企业模板、标准条款、历史修改记录和谈判指南等组织成结构化的审查规则手册（海外通常叫 Playbook），再通过 Word 插件等方式让 AI 去理解和执行这些规则。

1.3、从单次审查到 Agent 化

以 Ivo、Luminance、Harvey 为代表的是第三种路数。Ivo 这家 强调利用交易背景和企业历史谈判记录来理解"这家企业过去接受过什么条件"，公开的报道查到最新的 Review 2.0 为不同审查主题分配独立 Agent，再由上层 Agent 统一处理冲突。而 Luminance 把产品延伸到了端到端的合同生成、审查、谈判和履约监测，正在测试 Agent 与 Agent 之间的自动谈判。

Harvey 定位则更大，做的是面向律所和企业法务的通用法律 AI 基础设施，把高频法律工作封装为端到端的 Agents。这个方向私以为代表了未来的趋势，但目前大多数产品仍然强调 Playbook 约束和人工确认，完全自主的 Agent 还是少数。

涉及到的公司比较多，可以通过下面这个表格再做个直观对比：

产品	路线归属	核心定位	公开融资
幂律	法务深度参与	法律知识工程 + 企业系统集成	未公开
秀合同	内容资产 + AI	CLM + 模板/条款库 + 审查智能体	未公开
LegalOn	规则手册 + AI	Playbook Agent，支持自定义立场和红线	累计约 2 亿美元
Spellbook	规则手册 + AI	Word 插件，基于律师范本生成修改	5000 万美元 B 轮
Ivo	Agent 化	交易背景 + 历史谈判 + 多 Agent 协作	5500 万美元 B 轮
Luminance	Agent 化	端到端平台，测试 Agent 自动谈判	7500 万美元 C 轮
Harvey	Agent 化	通用法律 AI 基础设施	2 亿美元（估值 110 亿）

简要来说，合同审查产品的差异化竞争更多看的是规则资产的积累深度、与企业既有系统的集成能力、以及对历史数据的治理水平。

2、产品设计思路一览

上面讲完了市场观察，在具体拆解工程实现之前，老规矩先说清楚我这套产品设计层的一些思考。

2.1、整体架构

整个系统的数据流转大致是：合同文档进入 Pipeline，经过 9 个阶段的处理后输出一组结构化的风险卡。风险卡被三个消费端读取，审查工作台负责展示和交互，WPS 插件在原文中生成批注和修订建议，ERP 或合同管理系统驱动后续审批流程。

Pipeline 的运行完全由配置驱动。四层配置体系决定了这份合同按哪套规则审查、启用哪些检查项、调用哪些外部服务。配置和执行分离，调整审查规则不需要改代码。

Pipeline 部分输出的是结构化的风险卡，不是文本报告。结构化的好处在于同一份输出可以被多个消费端各取所需，Pipeline 不需要为每个下游系统单独做适配。

Agent 侧边栏和 Pipeline 共享外部服务和模型网关的基础能力，但运行方式完全独立。Pipeline 负责标准化的批量审查，侧边栏负责法务人员在审查过程中的即时追问。

审批人员在审查工作台上的每次采纳、驳回和改写，都会作为人工反馈回流到配置体系，这也是系统审查规则持续优化的基础。

2.2、合同类型：从民法典的 19 类到系统的 42 类

合同进入 Pipeline 后，第一步是先确定合同类型。合同类型决定了后续加载哪套审查方案，是整个配置体系的入口。

类型体系的设计无疑应该从法律框架出发。其中，《民法典》合同编规定了 19 种有名合同：买卖、供用电水气热力、赠与、借款、保证、租赁等。但企业实际经营中还有很多高频出现的合同类型并不在这 19 种之内。比如劳动合同由《劳动合同法》单独规定，并不属于民法典调整范围；同样，股权转让协议、投资协议、保密协议、竞业限制协议等同样没有被列为有名合同。

经过几轮论证，系统设定了 42 种合同类型，为了方便理解，我大致梳理了各个分类的代表性类型：

分类	代表性类型	说明
交易类	买卖、采购、销售、供应	民法典买卖合同及企业采购销售场景
用工类	劳动合同、劳务合同、劳务派遣、竞业限制	民法典未纳入，由劳动法体系调整
租赁与工程类	租赁、融资租赁、建设工程、工程监理	民法典有名合同 + 工程领域延伸
投融资类	股权转让、投资协议、合伙、借款	企业资本运作场景
知识产权与技术类	技术开发、技术许可、软件开发、知识产权许可	民法典技术合同的细化 + IT 场景
服务类	委托、咨询服务、物业服务、广告	企业日常服务采购
担保类	保证、抵押、质押	民法典担保体系
特殊类型	保密协议、特许经营、代理分销、加盟	企业高频但民法典未单列

42 种类型的设计目标，是让系统能把每份合同准确挂到正确的业务场景上。但需要说明的是，42 种类型并不意味着需要 42 套审查规则。这里有一个和律师团队特别论证过的核心逻辑，就是合同名称虽然有很多，但只要履约结构、风险重点、证据路径和处置动作等维度相近，实际可以也应该用同一套审查策略。

换句话说，审查方案本质应该按风险结构收敛，而不是按法条分类收敛。目前系统内置了 8 套审查方案，这部分就不展开了。

2.3、四层配置体系

在合同类型确定之后，系统需要知道按什么规则审查、启用哪些检查项、调用哪些外部服务。我把这些配置拆成了四层：

合同类型是入口，上面已经介绍过。

审查方案决定审查思路。以交易类合同为例，买卖合同、采购合同、销售合同的审查关注点高度一致（主体资质、付款条件、违约责任、争议解决），共用一套审查方案。

审查策略控制执行细节。每套审查方案下挂 9 个策略项，决定具体启用哪些检查项、设置什么参数阈值、是否启用特定的规则模块。

服务调用方案管理外部数据源的调用逻辑。后端已完成多类数据源的接入与集成，具体启用哪些服务由客户的需求或者偏好来定：

类别	已集成服务	用途
工商主体核验	企查查、天眼查、爱企查、启信宝	主体资质核验、工商信息查询
法律法规与司法数据	北大法宝、威科先行	法律法规检索、最新司法解释和司法判例查询
舆情与补充数据	Tavily 等	公开舆情检索、补充性案例查询
民法典条文检索	自建 RAG	民法典条文语义检索
历史审查经验	自建案例库	企业历史审查经验检索

以上服务通过 MCP 或标准 API 方式接入，审查范围和深度完全由客户需求决定。

上面介绍的这四层之间有一条明确的分界线：客户只需要配置合同类型到审查方案的映射，表达的是业务偏好。具体调哪个服务、调几次、怎么归并结果，由平台内部决定。

每次审查使用的完整配置会生成 SHA256 快照，确保事后可以准确还原当时生效的规则版本和服务调用记录。

需要说明的是，上面介绍的这套四层配置体系属于标准版的产品配置逻辑。标准版支持用户在不同数据源、不同审查维度上自主选择审查的尺度和口径，自行决定启用或关闭哪些策略。在合同类型识别上，源代码也已经支持通过特定关键词加大模型兜底的方式，针对不同条款进行过滤，在送审时触发相应的合规性审查。

当然，标准版的自主配置不等于企业级。真正的企业级方案需要深入结合客户实际的业务特征和审查口径，做更深度的定制化调整。标准版提供的是基础配置框架，企业定制版在此基础上做进一步的业务适配。

2.4、风险卡：一份输出，三个消费端

Pipeline 的输出不是一份文本报告，而是一组结构化的风险卡。每张风险卡大致包含以下信息：

字段	说明
风险等级	高、中、低
原文定位	命中条款在合同中的具体位置
判断依据	触发该风险判断的规则或模型推理过程
证据来源	法规条文、司法案例、企业历史审查记录
修改建议	该条款的建议修改方向
修订动作	替换、在指定位置后插入、删除

三个消费端各取所需：审查工作台用风险卡展示风险列表和操作入口，WPS 插件用风险卡中的原文定位和修订动作在合同原文中生成批注和修改建议，ERP 或合同管理系统用风险等级和判断依据驱动审批流程。

Pipeline 不需要知道下游系统的实现细节。企业可以接 WPS 也可以接其他编辑器，可以接某个 ERP 也可以接别的审批系统，风险卡的输出格式不变。外部服务也是同样的设计：在审查方案里配了就调用，没配就跳过，调用失败不中断主流程，降级状态作为提醒展示。

2.5、Skills 智能问答

上面介绍的各类数据源和审查能力，在 Pipeline 中是按配置自动调用的。同时，这些能力也被统一做了 Skill 化的封装，法律检索、主体核验、历史条款对比、法规解读等，每一项都是独立的 Skill，合同审批人员可以在侧边栏通过智能问答直接调用。

侧边栏要解决的不只是单份合同内部的追问。例如法务在审查一份合同时，有时需要做两类跨合同的分析。一类是纵向对比，关注合同的延续性：这个交易对手方历史上和我方签过哪些合同，当前这份和之前的主合同、从合同之间有没有条款冲突或延续性问题。

很多合同之间不是割裂的，主合同到期了从合同什么状态、前一份合同里的遗留条款有没有在新合同中得到处理，这些都需要跨合同去看。另一类是横向对比，看的是行业基准：同类型客户在付款比例、交付条件、违约金上限等关键条款上通常怎么约定的，当前这份合同的条件在同业范围内处于什么位置。

这两类查询能跑起来有一个前提，企业历史上几千或上万份生效状态的合同，都需要经过结构化解析和多层级的元数据标注。系统会对每份入库的历史合同做四个层级的元数据处理：

标注层级	典型字段	支撑的查询场景
合同级	交易对手方、合同类型、签署日期、生效状态、合同金额、关联合同编号（主从关系）	"这个对手方历史上和我方签过哪些合同""主合同到期了从合同什么状态"
条款级	条款分类、风险要素标签、关键事实（金额、比例、期限、交付条件）	"同类客户在付款比例上怎么约定的""违约金上限一般设多少"
主体级	涉及主体、主体角色（甲方/乙方/担保方）、集团归属与关联关系	"这个集团下有没有其他在执行的合同"
事件级	修订记录、审批节点意见、履约事件（续签、终止、变更）	"这份合同历史上退回过几次，退回原因是什么"

检索时先用元数据做范围过滤，比如指定对手方加合同类型，把候选范围从上万份缩小到几十份，再在过滤后的范围内做语义检索。两层结合，元数据保证召回的相关性，语义检索处理表述差异。

每个 Skill 有明确的输入、输出、权限和超时机制，不是开放式的自由聊天。Pipeline 负责标准化的批量审查，侧边栏通过 Skill 组合提供按需的跨合同分析能力。

3、Pipeline 工程拆解

产品设计层的逻辑在上一部分已经讲过，这一部分我重点介绍下 Pipeline 的工程实现，挑几个关键的工程决策展开。

合同文档进入 Pipeline 后依次经过上述 9 个阶段，最终输出结构化风险卡。下面结合其中四个关键环节大就核心代码逻辑做下拆解。

3.1、文档解析与结构恢复

Pipeline 的第一步是把各种格式的合同文档转换成统一的结构化输入。

系统支持 Word、PDF、扫描件和纯文本。PDF 解析后如果提取的有效文本过短，自动判定为扫描件并触发 OCR。解析完成后按目标长度进行条款切分，切分窗口之间保留一定重叠，确保条款边界处的上下文不丢失。切分参数是在当前测试语料上调优的经验值，不同业务场景下可能需要调整。

解析过程中同时保留段落结构、表格、页码和原文锚点，为后续风险卡定位到合同原文和 WPS 批注提供坐标。

3.2、混合场景检测：正则加大模型

合同类型识别决定了后续加载哪套审查方案。工程上采用混合检测，也就是正则先行，大模型兜底。

async def detect_contract_type(doc):
    regex_hit = match_regex_patterns(doc.text)
    if regex_hit.confidence >= CONFIDENCE_THRESHOLD:
        return regex_hit.contract_type
    model_result = await model_classify(doc.summary)
    if model_result.confidence >= CONFIDENCE_THRESHOLD:
        return model_result.contract_type
    return ContractType.PENDING_REVIEW

正则匹配速度快，结果确定，也没成本，目前积累的正则模式已经能覆盖绝大多数标准合同类型。大模型在处理非标名称（比如"XX 项目战略合作框架协议"）时有优势，但每次调用都有延迟和成本。

两层结合，标准场景走正则，非标场景走模型，两层都低于置信度阈值的标记为待人工确认，不会出现用错误的类型去加载审查方案。置信度阈值是在当前测试数据上调优的经验值，不同语料和业务场景下需要重新验证。

3.3、规则先行，模型收口

能用确定性规则解决的判断不交给模型，必须用模型时也不是把整份合同丢进去让它"全面审查"。

判断类型	处理方式	具体内容
确定性判断	规则引擎	主体名称一致性、金额与日期校验、必要字段缺失、比例阈值、标准条款命中
语义理解	大模型	语义等价判断、隐含义务识别、责任转移分析、例外条件理解、修改建议生成

规则引擎先输出一组确定性 Findings，连同外部服务的查询结果一起，作为结构化上下文传给模型：

# 模型接收的是预处理后的结构化上下文，不是整份合同原文
context = build_review_context(
    profile=contract_profile,    # 合同画像
    findings=rule_findings,      # 规则引擎的判断结果
    services=service_results,    # 外部服务的查询摘要
    clauses=key_clauses,         # 需要重点关注的条款
)
response = await model_gateway.call(context, fallback=FALLBACK_CHAIN)

这样做的目的是让模型聚焦在语义理解和灰度判断上，而不是从头做信息提取。模型调用的容错设计分三层。以 DeepSeek 为例：

同供应商内降级：首选高质量模型，超时或返回异常时自动切换到同供应商的轻量模型，接口和输出格式一致，切换成本最低。

跨供应商切换：单一供应商可能出现服务故障、API 限流或区域性不可用，系统支持配置备选供应商，主供应商不可用时自动切换。

终极兜底：如果所有模型供应商都不可用，Pipeline 的规则引擎和外部服务仍然可以独立运行，输出规则层面的 Findings。模型层面的语义判断标记为"模型暂不可用"，不会因为模型故障导致整个审查流程中断。

每一层模型调用都带 JSON 校验与修复逻辑，处理常见的格式异常后再做结果校验。

3.4、外部服务的并行调用与降级

Pipeline 根据审查方案的配置并行调用外部服务（服务列表在上一部分已经介绍过）。任何外部服务都可能超时或返回错误，不能因此阻塞整个审查流程。

async def call_services(plan, doc):
    tasks = [
        call_with_timeout(svc, doc, timeout=svc.timeout)
        for svc in plan.enabled_services
    ]
    results = await asyncio.gather(*tasks, return_exceptions=True)
    return merge_results(plan.enabled_services, results)

需要说明的是，asyncio.gather 让所有服务并行执行，每个服务有独立的超时时间。某个服务超时或报错时不会阻塞其他服务，异常会被转换为降级标记，后续流程正常继续。

降级原则是宁可少一项信息，也不允许误报。如果某个主体核验服务超时，系统不会把查询失败显示成没有风险记录，而是在风险卡中标注服务暂不可用，审批人员看到的是信息缺失提示而不是审查结论。

4、从审查合同到理解合同

前面三个部分讲的都是怎么审。但这些能力有一个共同的前提：审查规则默认是现成的。标准版的审查策略不是靠专家从零编写的，而是经过和多家需求方及律所团队的多轮论证，在工商查询深度、合规触发条件、审查提示词加载、外部数据源调用等环节上抽象出了一组相对通用的配置。

但通用配置能覆盖的范围有限，企业做私有化部署的时候，还需要通过大量访谈把客户已有的审批经验和风险偏好适配进来，这个冷启动过程往往才是最大的成本。

换一个角度看，企业签过的历史合同其实是一批没有被充分利用的数据。哪些条款长期被接受、哪些反复被修改、哪些触发过审批升级，这些信息基本还停留在文件服务器和 OA 系统里。

如果能从企业实际签署执行过的历史合同和审查记录中做蒸馏，自动生成一套基础审查规则，再由法务，财务等审批人员确认调整，比完全从零冷启动效率高很多。在这个方向上我做了一些工作，在两条线上有了阶段性成果大概说下，供各位参考，不过还在持续迭代当中。

4.1、历史合同的条款聚类与规则发现

这个方向的思路是把企业历史签过的同类合同、同类条款放在一起做聚类分析，找到"正常接受区间"和"异常偏离"，从中生成候选审查规则。

技术上有一个关键设计，条款向量不是单纯的文本 Embedding，而是把知识图谱的结构信息也编码进去，由文本语义、图谱邻域特征、元数据（合同类型、签约时间、行业）和风险要素四部分拼接而成。这样两个文本表述不同但在图谱上有相似关联关系的条款，在向量空间里会更接近。

条款向量聚类可视化图

举个例子，对某企业历史采购合同中的知识产权条款做聚类，可能发现三个聚类中心："项目交付物归甲方，背景技术各自保留"占 70% 以上，"全部归甲方"占 20%，"授权使用但不转让"不到 5% 且集中在特定供应商。第一类就是这家企业的主流接受范围，第三类是需要关注的长尾模式。聚类结果不直接变成审查规则，而是生成候选规则，每条带有适用合同类型、风险等级、历史样本数量和置信度，由法务确认后才正式发布到审查策略中。

4.2、修订痕迹与审批反馈的偏好校准

第二个方向关注的不是历史合同的最终版本，而是从初稿到定稿的修订过程。一份合同通常经历多个版本：初稿、审查系统的建议、法务的人工修订、对方反馈、最终定稿、审批意见。这些版本之间的差异本身就是信号。

条款多版本语义对齐矩阵

技术上第一步是做多版本的条款级语义对齐。这不是简单的文本 Diff，修订过程中条款可能被拆分、合并、移动位置，纯文本比对噪声很大。对齐算法综合文本相似度、风险要素、条款位置和涉及实体来计算跨版本的条款对应关系。对齐之后提取修订差异并标注意图，比如把"承担全部责任"改成"以已收取的服务费用为限承担赔偿责任"，文本变化不大，但意图是责任限额收紧，这是一个明确的风险偏好信号。

修订类型	含义	举例
强化	加强对己方的保护	增加违约金上限条款
弱化	放宽某项约束	删除竞业限制条款
替换	用不同表述达到类似目的	"全部责任"改为"以已收款金额为限"
新增	补充原稿缺失的内容	增加数据删除和返还条款
删除	移除不可接受的内容	删除单方面解约条款

在修订意图之上是 Agent 建议的采纳评估：系统给出的每条建议，最终是被完全采纳、部分采纳、改写后采纳还是驳回。这个结果是对规则质量最直接的反馈。基于采纳结果，系统对每条规则维护一个置信度分数并持续校准。采纳率高的规则置信度上升，驳回率高的下降，降到阈值以下的标记为待复核。法务反复做出类似修改但系统没有对应规则的，会被识别为新规则候选。

4.3、最难的不是算法，是数据归集

上面两条线的算法逻辑说起来清晰，但实际做的时候，最难的部分不在算法，在数据归集。

条款聚类需要企业把历史合同批量导入系统，这一步已经有成熟的文档解析能力支撑，问题不大。真正难的是修订痕迹分析所需要的数据：不是只要最终签署版，而是从初稿到定稿的每一个中间版本，加上审批流中各节点的意见。在实际场景中，这些版本散落在 OA 系统、邮件附件、微信传输记录、本地文件夹里，格式不统一，版本命名混乱，很多中间稿根本没有留存。把这些资料完整归集并对齐成可分析的版本链，需要大量人工，而且容易出错。

当然，这和做大模型微调是一样的道理。微调真正的难度不在训练过程的收敛，而在高质量数据集的构建。合同审查也是如此，算法原型跑通不是最难的一步，把散落在各处的修订记录清洗成结构化数据，这个过程占了绝大部分工作量。

所以个人建议是不要一开始就做这件事。先把 Pipeline 跑起来，让系统在日常审查中自然地积累结构化的修订记录和采纳反馈。跑了半年、攒了几百份合同的完整修订链之后，再做条款聚类和偏好校准，数据基础会扎实很多，投产比也更合理。

5、四种 OCR 对比需求实际更高频

前面四个部分讲的都是基于规则引擎和大模型的语义级审查。但在实际的法务工作中，有一类更基础的对比需求使用频率甚至更高。审批人日常最先关心的往往不是"这份合同有没有语义上的风险"，而是"模板对不对""关键信息有没有填错""签字版和审批版是不是一致"。这些判断不需要大模型，但出了问题影响同样很大。

5.1、四种对比场景

合同从提交到归档的生命周期中，有四个节点需要做对比校验：

对比类型	对比对象	解决的问题
模板对比	提交合同 vs 我方标准模板	是否使用了我方模板，增删改了哪些条款
数据一致性对比	合同关键字段 vs ERP 表单字段	金额、日期、税号、产品名称等是否一致
修订对比	合同 V1 vs V2 vs V3...	各版本之间具体改了什么
归档对比	最终电子版 vs 签字盖章扫描件	签署版本是否与审批通过的电子版一致

模板对比相对简单，核心是文本差异算法，比较提交合同和标准模板在条款层面的增删改。修订对比和归档对比的底层逻辑类似，都是两份文档做 OCR 识别后逐段对比，区别在于归档对比的输入是扫描件，对 OCR 准确率的要求更高。

5.2、提交即校验

四种对比里最容易被忽视但影响最大的是数据一致性对比。

举个实际场景：某企业的私有化部署服务申请了软件著作权，业务人员提交合同时需要在 ERP 系统的下拉菜单中选择对应的软件著作权产品名称，这个名称必须和合同附件 Excel 表格中填写的内容完全一致，包括大小写，一字不能差，否则直接影响后续的开票和退税。但合同通常是业务人员在之前版本的基础上修改出来的，产品名称很容易漏改或改错。这种错误靠人工逐字核对效率很低，但让系统做字段级精确匹配反而非常简单。

在调研阶段聊下来发下，很多审批人真正想要的交互都是希望业务人员点击提交的那一刻，系统用几秒跑一遍模板对比和数据一致性对比，发现明显问题就直接拦截，让业务人员当场修改，不需要等到审查环节再退回来。这比后面的语义级审查轻量得多，但能拦住大量低级错误。

技术实现上，模板对比用的是自研的文本差异算法，其他三种对比封装了合合信息、依图等 OCR 服务商的能力。这类基础 OCR 能力私有化部署的成本不高，几万块就能搞定一套，不需要自己造轮子。

6、写在最后

跳出合同审查这个具体 case，过去两年我做了二十多个不同场景的项目，大致可以归为三类。一类是各种知识库的检索与问答，一类是审查，合同审查、工业质检、财务合规、信贷资质审查等。还有一类是专业报告的生成，投标报告、信审报告、售前报价等。这些场景都有一个共同点，如果企业的数据基础足够好，无论是结构化数据、半结构化的业务文档还是非结构化的历史记录，从中蒸馏出规则、偏好和业务模式，直接用于上层的问答、审查和生成，效果是非常明显的。前面讲的四层配置体系、规则先行模型收口的分工、置信度阈值的设计，换一个场景换一套业务规则，骨架是可以复用的。

但现实是大部分企业并不具备这样的数据基础，或者说前期归集、清洗和管理这些高质量数据的成本过高，很多企业也看不清投入产出比。所以最后大家往往还是回到一个比较朴素的做法：先跑起来再说，然后再快速迭代。在使用过程中自上而下推一套反馈机制，每条审查建议是采纳还是驳回，驳回的时候标注原因。这些反馈慢慢积累下来，就是用户用脚投票沉淀出的真实偏好和规则。

文章里涉及到的 Pipeline 架构和核心工程逻辑，我做了一版精简的可运行源码，保留了完整的 9 阶段处理流程、正则加大模型的混合审查机制、确定性规则引擎、审查提示词的构建逻辑和基础的前端审查工作台。配一个大模型 API Key 就能跑起来，可以直接上传自己的合同看完整的审查效果。这个版本已经发布在我的知识星球，感兴趣的盆友可以拿来复现文章中的核心逻辑，也可以作为起点做进一步的扩展和定制。对这个方向有具体需求或者想深入交流的，也欢迎私信找我。