这篇文章是《AI 时代的新合同系统》系列的第 1 篇，彦祖会先站在产品经理的视角，试着把“为什么要重构合同系统”“下一代系统大概长什么样”“主干系统 + 能力组件”这套思路聊顺一点。后面几篇会把每一个关键能力单拎出来慢慢拆开。这更像是一个土木出身、半路改行做产品的人，对 AI 合同系统的一点个人畅想，写出来抛砖引玉，欢迎大家拍砖指正，一起多聊聊未来可能的方向。

一、为什么现在是重构“合同管理”的最好时机？

如果只看日常体验，很多企业今天的“合同管理系统”，本质上还是一个“电子档案柜 + 审批流”：

• 文档在线存放
• 审批在线流转
• 导出几个台账报表

但从产业数据看，这块正在快速进入一个必须重构的阶段。

• 全球 CLM 市场：2024 年全球合同生命周期管理（CLM）软件市场规模已达 21.48 亿美元，预计到 2031 年将增长至 38.06 亿美元，年复合增长率 8.6%，其中美国约占 37%，亚太 33%，欧洲 25%（QYR 恒州博智）。
• 中国合同管理市场：2024 年市场规模约 217.6 亿元，预计到 2031 年接近 409.5 亿元，未来六年 CAGR 9.1%（恒州诚思）。

同时，企业的痛点依然非常基础：

• 超过 60% 的企业仍主要依赖线下、邮件或手工台账管理合同；
• 单次合同审批平均耗时 3–5 天，条款修改频繁时周期可拉长至两周以上；
• 人工操作错误率高达 15%（搜狐网）。

这意味着：一边是高速增长的市场，一边是停留在“纸质 + Excel + 邮件”的管理现实。
再叠加 AI 的加速落地，今天其实是重构合同管理系统的“窗口期”。

我的核心观点是：

AI 时代的合同管理系统，不再是一个单体应用，而是“主干系统 + 若干可插拔能力组件”的集合。

• 主干系统负责：流程、权限、合规、数据底座、跨系统协同。
• 各种智能与业务能力，被做成标准化组件，可以拖拉拽、可替换、可对外输出。

泛微今承达走的是“低代码主干 + 组件化”的路线；
肇新科技则走的是“把智能能力拆成组件，对内对外都可复用”的路线。
这两条路径，加在一起几乎就是 AI 时代合同管理系统的答案空间。

---

二、传统合同管理的“低效循环”：为什么必须被打破？

看几组公开数据和典型案例，会更有画面感：

• 管理模式：超 60% 企业仍受困于合同管理的“低效循环”，严重依赖线下、邮件、手工台账。
• 流程效率：传统模式下，合同从草拟到归档，需要多次线下沟通、手工核对，单次审批平均 3–5 天；遇到反复修改条款时，周期可拖到两周。
• 错误与风险：人工操作错误率高达 15%，很多风险不是没管，而是“人在疲劳边界内管不过来”。
• 系统形态：近 60% 企业合同管理停留在“信息化阶段 2”，系统与 ERP、CRM 等业务系统割裂，数据无法互通（搜狐网）。

换句话说，大量企业的“合同管理系统”只是：

• 把纸质合同搬到线上，
• 把线下审批搬到 OA 流程里，
• 但并没有真正“用合同里的数据做决策”。

更严重的是“数字化断层”：

• 2023 年中国企业 OA 系统市场规模已突破 400 亿元，协同办公平台渗透率持续攀升；
• 但近 60% 企业的合同系统与 OA / ERP / CRM 割裂，
  • 财务拿不到实时的付款节点；
  • 业务看不到履约进度；
  • 法务的风险判断无法成为业务日常决策的一部分。

这就解释了：
为什么 CLM 市场体量和增速都不小，但用户“体感价值”偏低。

---

三、AI 不是“给老系统加个大模型入口”，而是换一套架构思路

如果只是给传统系统加一个“AI 审核”“AI 问答”的按钮，本质还是旧系统 + 新能力的补丁，很难真正穿透到价值层。

我认为，在 AI 时代重新设计合同管理系统，应该先做一个架构层的选择：

从“单体系统”切换到“主干系统 + 能力组件”的架构。

• 主干系统：

  • 全生命周期流程：拟定、审核、会签、签署、履约、变更、终止、归档；
  • 统一合同数据模型：合同、条款、相对方、项目、里程碑、收付款计划等；
  • 权限、合规与审计：谁能看到什么、改什么、导出什么，全程留痕；
  • 与 OA / ERP / CRM / 财务 / 项目系统的集成编排。

• 能力组件（可以来自自研，也可以来自第三方能力厂商）：

  • 智能文档比对（差异对焦、条款对齐、多版本管理）；
  • 智能信息提取（当事人、金额、期限、违约责任、关键义务等结构化）；
  • 智能合同合成（根据业务参数 + 模板库生成草稿）；
  • 风险识别与评分（结合历史纠纷、内部风控策略）；
  • 智能履约提醒与进度监控；
  • 合同数据分析与洞察（条款接受度、价格带分布、谈判空间等）。

这样的结构，才能撑得住两个趋势：

一方面，AI 能力迭代极快，模型、算法、Prompt 策略几乎半年一换，必须保持模块化；另一方面，系统间协同要求越来越高，合同智能能力不能只服务“合同系统”，还要服务 OA、采购、项目、法务等多个入口。

---

四、路径一：以泛微今承达为代表的“低代码主干 + 可拖拽组件”

先看低代码路径。以泛微今承达为代表的厂商，本质上是把“合同系统”构建在自家低代码平台之上：

• 他们真正卖的是平台能力：
  合同只是跑在平台上的一个“典型行业应用”。流程引擎、表单引擎、权限体系、集成中台，本身就是可配置组件。

• 业务逻辑被拆成“拖拉拽组件”：
  审批节点是组件、台账视图是组件、提醒规则是组件、接口调用是组件；
  行业差异，通过配置和拖拽的组合来承载，而不是每个客户单做一套代码分支。

这套逻辑非常适合中国企业市场：

• 行业差异大，
• 个性化需求多，
• 预算有限但变化频繁。

从行业实践和公开案例看：

• 像简道云这类轻量级合同 / 流程工具，简单流程可在 1–2 周快速搭建上线，而传统定制开发往往需要数月。

这说明：“低代码 + 组件化”的主干，在交付效率和持续演进上，都比纯定制更有优势。

到了 AI 时代，这条路线可以进一步演进成：

在低代码平台上，把 AI 能力也做成“节点组件”，让业务配置人员通过拖拉拽就能编排一条“智能合同流水线”。

一条典型的流水线，大概会长成这样：业务把合同扔进来，系统先自动触发 OCR 和文本解析，把纸质或 PDF 变成结构化的文本；解析结果再被送进条款识别组件，贴好“这是付款条款、这是违约责任、这是履约保障”这样的标签；之后拿着识别结果去和标准模板做一次智能比对，把偏离的地方用高亮方式“抠”出来；再由风险评分组件给关键条款打个分，看看哪些是可以接受的“黄灯”，哪些已经到了需要法务重点关注的“红灯”；最后，这些结果被通过机器人或待办组件分发给相应角色，业务、法务、管理层各自看到和自己相关的那一块。

产品经理在这里要想清楚的，不是“再多加几个 AI 按钮”，而是每个 AI 节点到底吃什么、吐什么，在低代码平台上应该以节点、控件还是规则块的形式暴露给业务同学，用怎样的方式把这些节点接成一条顺畅的线，而不是散落在页面各个角落的几个“智能功能”按钮。

类似这种已经在市面上跑得很成熟的形态，彦祖更多是抱着学习和拆解的心态，把它拉出来和大家一起聊聊；但说实话，在彦祖自己脑子里，这大概还不是 AI 时代合同系统的终局形态。

---

五、路径二：以肇新科技为代表的“AI 能力组件基座”

另一条路径，是把智能能力做成一个个可嵌入任意系统的组件，典型代表就是肇新科技这种厂商：

• 能力拆解：

  • 智能文档比对组件
  • 智能信息提取组件
  • 智能合同合成组件

• 前端开源 / SDK 开放：
  不只做一套“自家合同系统”，而是以 API + SDK + 前端控件的形式开放，
  让任何 OA / 合同 / 项目 / 采购系统，都可以像引入一个 UI 控件一样，引入这些智能能力。

一些公开的实践数据，直接刻画了这种“能力组件”的效果边界：

• 效率提升：

  • 某科技客户通过肇新科技系统，将合同审批周期从线下不可追踪，变为线上可控的 最多 3 天，效率提升 70%+；
  • 某银行 ISDA 主协议审查从 7.2 天 缩短至 1.8 天，效率提升 75%。

• 准确率表现：

  • 智能文档比对技术在字符级差异识别上，准确率可达 95%+；
  • 在风险识别双盲测试中，AI 系统 Precision 93.7%、Recall 89.1%、F1 值 91.3%，显著优于人工审查的 82.4% 准确率。

• 成本与风险：

  • 某制造企业通过 AI 合同管理，人力成本从 360 万元 降到 120 万元，降低 67%，合同纠纷导致的损失金额平均下降 70%；
  • 某金融机构通过 AI 审核系统，合规风险降低 80%。

这些数字背后，隐含了两个重要判断：AI 合同能力已经不再停留在“Demo 阶段”，而是真正可以量化 ROI 的生产力；同时，只要把它们做成标准化组件，就可以在多个系统、多条业务线里平摊开发和训练成本，形成明显的“能力杠杆”。

站在产品经理视角，如果把自己想象成“能力提供方”，脑子里的问题就会从“我要不要再做一套系统”，变成“每一种 AI 能力应该被抽象成什么样的组件，它的输入输出、性能指标、反馈机制分别是什么，怎么设计，第三方开发者一眼就能看懂、接得上、集成得起”。真正值得花时间想的，是这些底层能力怎么被拆开、打包、暴露出来，而不是天天纠结“我这套合同系统界面够不够好看”。

---

六、为什么 AI 时代一定要做“能力组件化”？

如果把前面的市场和现状数据放在一起看，会发现一个很强的张力：一边是年复合 8.6% 的全球 CLM 市场增速、中国 9.1% 的本土市场增速，一边是超过 60% 的企业还在用手工台账、邮件往来、简单 OA 流程来支撑合同管理，整体仍然停留在“信息化 2 阶段”。这意味着，需求端和供给端都在快速扩张，但中间真正承接价值的“能力层”仍然相当原始。

与此同时，AI 在合同领域的试点已经证明它不是“看起来很美”的概念，而是可以量化 ROI 的生产力工具：从 7.2 天缩短到 1.8 天的合同审查周期、被压缩到最多 3 天的审批周期、67% 的人力成本下降以及 70% 的合同纠纷损失降低，都在说明只要把合适的能力嵌入到合适的环节，效率和风险两端都会发生量级变化。问题不在于“AI 值不值得用”，而在于“用在哪儿、怎么用，以及如何在不同系统里复用”。

站在产品和技术实现的角度看，如果每一次想要引入这些智能能力都必须从零重做一套系统，或者在原有系统里做一次“开膛手术式”的重构，那无论是开发成本、测试成本还是组织变更成本，都会高到让人望而却步。相反，把模型、算法、规则、交互封装成标准化的能力组件——无论是内嵌在低代码平台里，还是通过 API / SDK 提供——就可以在数周甚至数天内完成一次集成，把复杂度收敛在组件内部，把弹性释放在业务外部。

更现实的一点是，中国企业的数字化基础设施是“多入口、多系统”的：OA、ERP、CRM、采购平台、项目系统……合同相关的动作分散在这些系统里进行。2023 年 OA 市场已经超过 400 亿元，但近 60% 的合同系统依然与这些业务系统割裂，形成“数字化断层”。如果合同 AI 能力被紧紧绑死在某一个合同系统里，其他入口就只能“干看着”，很难真正享受到效率和风控的红利，也就谈不上公司级的收益最大化。

从这个意义上讲，AI 时代的合同管理如果还坚持用单体系统的思路来做，而不是围绕“能力组件化”去重构架构，本身就是在和技术趋势、业务现实对着干：升级一次要付出极高代价，能力无法跨系统复用，很难沉淀出一个对内对外都具有吸引力的生态位。组件化并不是一个“好听的架构词”，而是在市场规模、效率收益和集成成本这三条曲线上，综合权衡之后几乎唯一合理的解。

---

七、产品经理视角：设计“主干 + 组件”的三层能力模型

站在产品经理角度，可以把未来的合同管理系统抽象成三层：

1. 数据基础层：让合同“变成数据”

这一层要回答的问题是：合同里的信息能不能被机器理解和复用？ 表层看，它接住的只是 Word、PDF 或扫描件这样的原始文档，底下要拆出来的却是一整套结构化数据：合同基本信息、条款清单、当事人、金额、币种、时间、里程碑、保证金等等；还要和订单、项目、发票、付款记录这些业务对象建立起清晰的关联，并且把“谁在什么时候上传、修改、审批、导出”的行为日志都记下来。

对产品经理来说，这一层的工作，更多是在后台帮 AI 和业务“打地基”。要提前想清楚字段模型和条款模型，哪些信息必须结构化存储，哪些可以暂时放在附件里；给不同来源打好标记，是系统生成的、人工修改的，还是 AI 给的建议；再反推一遍，这些数据未来会服务哪些 AI 能力组件和管理报表，避免为了“表单看起来很完整”硬塞一堆没人填、也没人用的字段。

2. 智能能力层：把 AI 能力做成可插拔组件

这一层是 AI 真正发挥作用的地方，也最适合做成“组件市场”。你可以把它想象成一排能力积木：有负责文档解析与 OCR 的，有负责条款识别与分类的，有负责多版本、多模板智能比对的，有负责生成合同草稿和条款重写的，也有专门做风险评估的组件，用 Precision、Recall、F1 这些指标来衡量表现。

根据公开披露的精度数据（ai的能力数值P=93.7%、R=89.1%、F1=91.3%，全部都优于人工 82.4%），我们大概能看清一条能力上限线：只要嵌得对，AI 确实可以在准确率上跑赢人工。产品经理在这里要做的，不只是“把模型接进来”，而是给每个组件定义清晰的 KPI，比如准确率、召回率、处理时延、用户采纳率等等；在不同模型、不同参数之间设计好 A/B 测试的空间；同时设计好回退机制，例如当置信度过低时自动降级为“只标记疑点，由人工来做最终裁决”，避免一上来就“全自动”把自己坑死。

3. 业务编排层：围绕“任务”而不是“菜单”设计系统

这层决定用户真正体验到的，是“我在这个系统里能不能把事办完”。

对业务同学来说，他们更关心的是能不能快速生成一份像样的合同草稿，随时看清审批进度和履约状态，在关键节点收到提醒；法务更希望系统帮自己快速识别出偏离标准的条款，把风险摘要和修改建议整理好，还能复用条款知识库，少做重复劳动；管理层则会盯着合同对营收、利润、现金流和风险敞口的影响，希望尽快识别出高风险客户和高争议条款。

所以在这一层，产品经理真正要画的，不是一张张“模块菜单”，而是一条条“任务流”。每一种典型任务需要串起哪些能力组件，中间有哪些角色接力，哪一步该由人拍板、哪一步可以交给算法；绝大部分技术复杂度应该被包在系统内部，对外只暴露几个自然语言入口和少量关键决策点，让用户感觉是在“跟系统商量怎么把事情办好”，而不是在“找菜单找按钮”。

---

八、两种可能的未来形态：一个对话框，还是一座“软件工厂”？

站在 3–5 年的时间尺度，我觉得合同管理产品大概率会在两种形态之间摇摆甚至并存。

形态一：用户只看到一个“对话框”的合同系统

对于很多业务、法务、管理者来说，他们真正想要的不是一堆菜单，而是有人直接告诉他：今天有哪些合同相关的事要处理，这份合同的关键风险是什么，这类合同在全公司一般是怎么谈成的、有没有谈判空间。

所以对应的产品形态，大概率会是：入口就是一个对话框加个性化首页，用户用自然语言发起任务，系统在背后自动调用比对、识别、生成、分析等组件，再把人带到合适的页面或视图，而不是让大家在左侧菜单里来回迷路。

从产品设计角度看，这意味着 UI 架构的重心从“模块导航”变成了“意图识别 + 任务编排”，交互重点也从“点哪儿”变成了“说什么、系统如何解释结果”。

形态二：像“小米供应链”一样的“工厂式合同软件装配”

另一种形态，是把软件行业往传统制造业方向推进。合同系统厂商更像“整机厂”，负责提供主干架构、统一数据模型和基础能力；各类 AI 能力提供商、垂直方案商则像“零部件供应商”，在某一项能力上做到极致，例如特定行业的条款风险模型；最终针对不同行业、区域、规模的客户，由产品经理和交付团队像装手机一样——选配组件、组装、调优、交付。

在这种模式下，“组件市场”的重要性会越来越高：要有明确的接入标准和认证体系，有透明的性能指标和计费模式，让不同组件之间既可以竞争，也可以互补。

产品经理的部分角色，也会慢慢往“装配工艺工程师 + 生态运营”方向迁移：一边帮客户选一套“既够用又可演进”的组件组合，确保不同供应商组件之间的兼容性和体验一致性；一边持续跟踪组件的性能、成本和反馈，用数据来做“要不要换供应商、要不要换一批组件”的决定。

---

九、AI 时代，合同管理产品经理的五个关键思考

最后，回到“产品经理应该怎么想”的问题，我会给出五条实践向的建议。

1. 用“任务列表”替代“功能列表”

从一开始就别急着罗列“功能模块”，而是先问自己：不同角色在合同生命周期里最核心的那 10–20 个任务到底是什么，其中哪些任务既高频、痛点又明显，而且一旦引入 AI 或组件化手段，就有机会把效率直接拉高 50% 以上。

需求文档里，也尽量把“XX 模块、XX 功能”的写法，换成更贴近场景的描述：某个角色在什么场景下会发起这个任务，他现在是怎么做的，哪里低效、哪里容易出错；如果引入一两个关键组件，这个任务的链路可以被怎样重塑。前面那些关于效率提升和成本节约的数据（70% 审批效率、75% 审查效率、67% 人力成本下降等），就可以直接挂在这些任务后面，成为排优先级时最硬的一根尺子。

2. 把“页面 IA”升级为“能力编排图”

传统 B 端产品画信息架构图，往往只关注菜单、页面和跳转关系；AI 时代的合同产品，更需要一张“能力编排图”和一张“任务流图”：某个任务流需要串起哪些能力组件（比对、识别、生成、评分……），每个组件的输入输出在链路中以什么形式流转，出错或置信度过低时怎么优雅地回退，以及这些东西最终要怎么投影到低代码 / 工作流引擎里，让运营和顾问能像改“配方”一样自己调整节点，而不是每次都开需求找研发。

3. 从一开始就设计“数据与反馈闭环”

调研数据已经证明 AI 合同能力“能干活”，但要持续变好，还得有一套扎实的数据和反馈闭环。系统要能看得见用户是不是采纳了 AI 的建议，精细到条款粒度记录“哪些条款被频繁修改”，同时区分不同客户、行业、法务团队的偏好差异。

这些数据一方面会反哺模型，让 AI 组件越干越聪明，另一方面也会给管理层提供很有价值的洞察——比如“哪些条款是本公司谈判中经常被妥协的点”。所以产品经理最好在 0 阶段就想清楚：哪些事件必须打点，哪些数据要进入模型训练闭环，哪些要沉到管理报表，让数据真正变成决策工具，而不是只在汇报 PPT 里漂亮一页。

4. 接受自己的边界：敢于“只做几个关键组件”，也敢于“只做主干”

面对 200 多亿规模、年增速 9% 的中国合同管理市场，没有任何一家公司可以“从上到下全吃”。对产品经理来说，一个更现实的选择是：要么立志于做一个“主干 + 生态”的平台型产品，把接口和标准打磨得非常干净，把低代码和编排能力做扎实，让别人愿意接在你这棵大树上；要么在若干关键 AI 能力上做到极致，比如专注“金融衍生品合同风险识别”，或者专注“大型工程项目合同条款结构化”，做成行业公认的“能力黑盒”。关键是敢于做减法，不是所有能力都自己做，而是做好组合和取舍。

5. 把“开放性”写进产品设计 DNA

不管你选哪条路，有一点是共性的：**开放性不能是事后补救，而要是设计前提。**API、Webhooks、SDK、前端组件这些基础设施，一个都不能少；日志、监控、调用指标也要提前想好怎么对第三方和客户开放，让别人尽可能像接入一块“标准电源插座”一样，接入你的能力。结合网上公开数据里“集成现成组件后，业务协同效率提升 60%”这一条可以看出：开放的产品，更容易成为别人系统的“加速器”，也更容易形成网络效应和护城河。

---

十、结语：从“电子档案柜”到“智能能力工厂”

回到文章最初的问题：“AI 时代，合同管理系统该怎么做，产品经理应该怎么想？”

结合市场数据和案例，我的答案可以压缩成三个层次来理解。

首先，合同不只是文档，而是企业经营规则与风险边界的载体。传统“电子档案柜 + 审批流”的系统，只解决了“有无”的问题，没有解决“好不好”的问题。

其次，下一代合同管理系统，应该是“主干系统 + 能力组件”的集合。主干负责全生命周期和数据底座，能力组件（无论来自泛微这类平台，还是肇新科技这类能力厂商）负责具体智能能力，并在不同系统中反复复用。

最后，产品经理需要从“堆功能”转向“编排任务与能力”。用调研数据说服业务和管理层，用组件化架构驾驭 AI 的快速演进，让合同真正从“文件”变成“可以被算法使用的资产”。

当我们不再纠结“左侧菜单分几级”，而是认真回答“用户今天在合同上最想完成的 10 件事，以及其中有几件可以被 AI 接手”，
合同管理系统就真正开始跨过“电子化”门槛，迈进 AI 时代的“能力工厂”阶段了。对彦祖来说，这一篇更像是站在 30,000 英尺高度随手画的一张总览草图，后面的几篇会顺着这里提出的“主干 + 组件 + 任务”这条主线，分别落到具体能力、产品设计和落地路径上，也算是一个土木佬半路改行做产品之后，对 AI 能力的一些胡思乱想，写出来博大家一笑。