肇新合同

如果你这两年接触过各种“AI 合同系统”的宣传，大概会注意到一个现象：

有的产品主打“智能审核”“智能生成”“智能比对”几个大按钮，看上去什么都能干；

有的则几乎不谈“系统”，而是在各种 OA、合同平台、项目系统后面，默默提供“比对接口”“条款识别 API”“前端控件 SDK”。

前一种，更像是在老系统上贴了几块“智能标签”；

后一种，则是在往整个行业提供一套“能力基座”。

在《AI 时代的新合同系统》系列的总论篇里，我们已经画过那张大图：主干系统 + 能力组件。上一篇聊的是“低代码主干”那根骨头，这一篇，我们把视角移向另一侧——AI 能力组件基座。

核心问题只有一个：在合同场景里，AI 能力应该被拆成哪些“可复用组件”，而不是几个孤立的“智能按钮”？

下文会以肇新科技这条路线为主线，但并不局限于某一家厂商，而是尝试抽象出一个“能力基座”的通用形态。

一、为什么要把 AI 能力抽象成“组件”，而不是“功能”？

如果只站在单个系统的视角，很多事情似乎都可以通过“加一个功能”来解决：

合同系统里加一个“智能比对”菜单；

OA 审批详情页上多一个“AI 审核意见”；

项目系统的合同卡片里，嵌一个“风险评分”小挂件。

短期看，这种做法最快见效；但一旦把时间拉长、把系统范围放大，你会发现至少有三类问题：

1. 重复开发：每个系统都在造一样的轮子

合同系统做了一套合同比对；OA 又单独做一套；招投标平台再做一套；

每一套都要重新接入模型、调参、评估效果、写交互；

模型一升级，各条线要分别回归，成本乘以 N。

2. 难以跨系统复用：能力被绑死在某一个“壳”里

本来只想用“智能比对”能力，却被迫上对方整套系统；

OA 想在自己的流程里用合同风险评分，却发现对方只能“整页 iframe 嵌入”；

领导希望在一个总控台里看到所有合同风险，却发现各系统的数据口径完全不一致。

3. 很难量化 ROI：能力价值被“埋”在体验里

你不知道“智能审核按钮”到底帮用户节省了多少时间，只能靠访谈和主观感受；

每个系统各自统计，难以在公司层面看到“这几块 AI 能力整体带来的收益”；

更不用说以统一的 SLA、精度指标，对外作为“产品能力”来售卖。

站在产品和架构的角度，把 AI 能力抽象成“组件”，本质上是在做三件事：

把能力从具体系统里“剥离出来”：让它可以服务多个系统，而不是只能服务一个壳；

为能力定义清晰边界和接口：输入/输出、精度、延迟、计费、SLA 都可以被独立描述；

让能力可以独立演进、独立计价：模型升级、策略调整、A/B 实验都可以在组件层做，而不必每次动整套系统。

这就是肇新这类厂商选择做“能力基座”而不是“再造一个 OA/合同系统”的根本原因：把自己定位成系统背后的“智能零部件供应商”。

二、一套合同 AI 能力，应该拆成哪几类组件？

如果把合同相关的 AI 能力拆开看，大致可以分成几条主线。这里先不强调“某家厂商怎么命名”，而是从产品视角看“职责边界”。

1. 文档解析与 OCR 组件：把纸和 PDF 变成“可算的东西”

职责：接住各种格式（扫描件、PDF、Word、图片），输出结构化的文本和版面信息；

关键输出：段落、表格、页码、坐标、字体信息等；

应用：后续的条款识别、比对、风险识别，都要站在它肩膀上。

这一步如果做不好，后面所有“智能”都会变成“蒙的”。

2. 条款识别与结构化组件：给合同“画骨骼”

职责：在解析结果上识别出“这是付款条款、这是违约责任、这是保密义务、这是解约条件”；

关键输出：条款类型、条款位置、关键字段（金额、比例、日期、对象等）；

应用：模板比对、风险评估、履约拆解、统计分析，都依赖这一步的结构化结果。

你可以把它理解为“给一堆文字装上关节和标签”，让系统能抓住关节发力，而不是对着整篇文档瞎算。

3. 智能文档比对组件：把“变了什么”说清楚

职责：对比两份合同（或合同 + 模板），找出增删改动，并且从业务含义上高亮关键差异；

关键输出：差异清单、变更类型（新增/删除/改写）、涉及条款类别、重要性等级；

应用：版本审核、谈判复盘、审计追责、AI 草稿 vs 人类修改的对比等。

这里的难点往往不在字面 diff，而在于：

条款顺序调整、拆条/合条如何识别成“同一条”的改写；

金额、比例、时间等关键字段的改动，如何在 UI 上被特别突出；

多版本链路（v1→v12）中，如何快速捕捉“从无到有”和“从有到无”的变化。

4. 智能合成/生成组件：把“规则库 + 参数”变成草稿

职责：基于模板库、历史合同和业务参数，自动生成一份“八九不离十”的合同草稿或条款建议；

关键输出：可编辑的合同初稿、变更建议、可选条款组合；

应用：业务自助起草、批量合同生成、条款推荐等。

在 AI 时代，这块能力往往依赖大模型，但真正的产品难点是：

如何把企业自己的条款库、偏好、合规模板“喂”给模型，而不是完全靠通用语料；

如何在 UI 上清晰地区分“AI 草稿”和“人类修改”，避免责任模糊；

如何给用户足够的控制权，比如固定某些条款、只让 AI 在安全边界内改写。

5. 风险识别与评分组件：给合同打一张“风险体检单”

职责：基于条款结构化结果和企业风控策略，识别潜在风险点并打分；

关键输出：风险标签（如“付款条件偏弱”“违约责任缺失”）、风险等级、解释说明；

应用：法务初筛、审批前预警、存量合同风险排查、审计抽查。

这块能力通常会用到监督学习 + 规则引擎的组合，其表现可以用 Precision / Recall / F1 来量化。公开数据已经能看到类似：

某些场景下，AI 风险识别的 Precision 可达 93%+、Recall 接近 90%、F1 在 91% 左右；

明显优于“人工抽查 + 经验判断”的 80% 出头的准确率。

6. 智能提醒与进度监控组件：让合同“自动吱声”

职责：根据合同条款和履约计划，自动生成里程碑、提醒规则和异常告警；

关键输出：待办列表、提醒消息、逾期告警、风险趋势；

应用：回款跟进、履约节点提醒、续签预警、保函到期提醒等。

它不一定是“最 AI 的那块”，但往往是用户体感最直接的那块——有没有在关键节点给我敲过钟。

以上这些，都可以被拆成相对独立的组件，各自有清晰的输入输出、指标和可见的价值，而不是统统藏在一个“智能合同 2.0”的大黑盒里。

三、“能力基座”的产品形态：API + SDK + 前端控件

讲到这里，一个问题会自然浮现出来：

如果把这些能力都做成组件，组件本身应该长成什么样？

以肇新为代表的“能力提供方”，在这方面其实已经给出了一套相对清晰的答案：

1. API：后端的“能力边界”

为每一个能力组件提供一组相对稳定的 REST / gRPC 接口；

明确请求格式（合同文件、文本、业务参数）、响应格式（结构化字段、差异列表、评分等）；

对外公布鉴权方式、QPS 限制、错误码、超时策略等。

从集成方角度看，API 是“我能不能在自己的系统里，调用你这块能力”的第一道门槛。

2. SDK：降低集成成本的“适配层”

针对常见语言和平台（Java、.NET、Node.js、Python 等）提供轻量 SDK；

封装签名、重试、错误处理、流控等样板逻辑；

提供示例代码和最佳实践，降低一线开发的上手成本。

很多时候，决定一家能力提供方好不好接的，不是模型有多强，而是 SDK 和文档是否工程友好。

3. 前端控件：把能力“挂”在页面上的现成零件

提供可嵌入的对比视图控件、条款列表控件、风险摘要控件；

支持简单配置样式、主题和交互行为（只读/可编辑、单选/多选等）；

保证在主流浏览器、框架下都能稳定运行，并预留埋点和事件回调。

这一步的意义在于：

OA、合同系统厂商、内部研发团队可以少做大量 UI 重复工作；

用户跨系统体验可以相对一致——不至于在一个系统里看一套比对界面，在另一个系统里又是完全不同的逻辑。

当 API + SDK + 前端控件三件套都到位时，“能力基座”才真正具备了产品形态，而不是一堆散装模型。

四、用公开数据给组件“画边界”：别把所有功劳都算在 AI 头上

能力组件化还有一个容易被忽略的好处：

可以用数据给每一块组件“画边界”——它到底解决什么问题、做到什么程度、在什么前提下才成立。

以肇新的公开案例为例（这里只做抽象，不逐条复述）：

审批周期从“线下不可追踪”压缩到“线上可控的最多 3 天”；

ISDA 主协议审查从 7.2 天缩短到 1.8 天，效率提升约 75%；

某些场景下，人力成本下降 60% 以上，合同纠纷损失下降 70% 左右；

风险识别双盲测试中，Precision、Recall、F1 全面优于人工基线。

这些数字如果只写在“整套系统”的宣传里，很难分清：

哪一部分是流程电子化带来的；

哪一部分是 AI 能力本身带来的；

哪一部分又是组织治理、制度优化的结果。

而当你把能力拆成组件，就可以更细地去读这些数据：

文档解析 + 条款识别，主要影响的是**“可结构化的数据比例”**；

智能比对，更直接影响的是**“每轮审阅耗时”和“漏改/错改率”**；

风险评分，则主要体现在**“高风险合同被提前识别的比例”以及“审查人均工作量”**；

智能提醒组件，更多体现在**“逾期率”“漏审/漏签率”**等运营指标上。

这样一来，无论是对内复盘 ROI，还是对外讲解产品价值，都会清晰很多：

某个组件可以自信地说“在这个环节，我们把时间从 X 压到 Y，把准确率从 A 提到 B”；

也能老老实实承认“在特定场景下，仍然需要资深法务做最终判断”。

真正的可解释性，不只是模型层的，而是整个能力栈的。

五、以肇新为例：一条“能力基座”路线大致长什么样？

如果把肇新科技抽象成一个产品路线，而不是具体某款系统，大致可以画成这样一条线：

起点：从一个具体场景切入

比如先把“智能文档比对”做到极致：支持 Word / PDF / 扫描件，多版本、多模板、多语言，做到字符级精度和条款级对焦，先在少数大客户里证明“比人快、比人稳”。

向前后扩展：围绕比对打造能力簇

向前接 OCR 和条款识别，减少“比对前的人工准备工作”；

向后接风险评分和摘要生成，让比对结果不是一堆红绿线，而是一页“能直接拿来决策的提要”。

横向开放：把能力从“自家系统”解耦出来

把比对、识别、评分、生成都变成 API/SDK/前端控件；

让 OA、招投标、项目系统、内部工具都能接入这套能力；

在不同系统里积累 usage 数据和反馈，反向提升能力质量。

沉淀为“能力基座”：对内复用、对外输出

对内：自己做的任何新系统、项目，优先从能力基座里“领能力”，而不是再造轮子；

对外：把能力当成产品卖，而不是只卖整套系统；

在某些垂直领域（比如金融衍生品、工程总包等）做深，形成“行业黑盒能力”。

沿着这条路线走下去，你会发现肇新这样的厂商，更像是“AI 合同能力的供电站”，而不是单一某款合同系统的替代者。

六、产品经理如何和“能力基座”配合？

站在甲方或平台型乙方产品经理的角度，面对这种“能力基座”路线，需要思考的至少有三件事。

1. 划清边界：哪些能力自己做，哪些能力买组件？

对业务敏感度高、强依赖内部规则和数据的能力，可以考虑自研或深度定制；

对算法要求高、需要长期模型训练和标注投入的能力（如 OCR、条款识别、比对算法等），更适合买成熟组件；

在投标和方案里，要能清楚地讲清“主干 + 能力基座”的分工，而不是含糊其辞。

一个实用的原则是：

凡是“每个项目都要重复造”的通用能力，优先考虑买组件；凡是“只有本公司会这么玩”的极端需求，再考虑自建。

2. 在架构上为“能力基座”预留插座

即便短期内还没选好能力供应商，也可以先做几件准备工作：

在关键链路上预留“AI 节点”和“人工节点”的切换开关；

在数据模型里区分“系统建议”和“人工采纳”，为未来接入能力基座打好标记；

在低代码/工作流引擎里，把调用外部能力抽象成标准节点，而不是散落在代码各处的 HTTP 调用。

这样，当你真的引入某个能力提供方时，

只需要在这些节点后面接上对应组件；

不必推翻现有业务流程和数据模型。

3. 用“任务视角”而不是“页面视角”评估能力价值

在评估引入某个能力组件时，尽量别只看它的 Demo 有多炫，而是回到那条老问题：

它帮哪个角色，在哪条任务流上，节省了多少时间、减少了多少错误？

如果把它拆掉回到“纯人工”，这一段链路会变成什么样？

这些提升，能不能在数据上被长期看到，而不是只在试点项目里亮眼？

当你能用“任务流 + 组件”的语言和能力提供方对话时，

双方才有可能谈的是“一起把这条链拉顺”，而不是“你多给我几个按钮”。

七、结语：把自己当成“能力工厂”的一员

回到这篇一开始的问题：AI 合同能力应该被拆成哪些组件？

如果只从技术栈出发，很容易陷入模型、参数、框架的泥潭；

但从产品和业务出发，我们更关心的是：

每一块能力究竟在哪个环节发挥作用；

它能不能在多个系统里反复复用，而不是绑死在某一套壳里；

它能不能被清晰地描述、度量、计价和演进。

在这个意义上，“能力基座”不只是肇新这样的厂商要做的事，也是每一个认真做合同产品、做 AI 能力的团队需要面对的现实：

你终究要从“堆功能”走向“供能力”。

当主干系统敢于做减法，把自己聚焦在流程、数据、权限和集成；

当能力提供方愿意做加法，把一块块成熟的 AI 能力打包成组件、基座和生态；

当产品经理习惯用“任务 + 能力 + 指标”的方式来思考系统形态，

AI 时代的新合同系统，才有可能真正摆脱“电子档案柜”的影子，长成一座可以持续供电的能力工厂。