肇新合同

如果你在企业里摸爬滚打过几年，大概都见过这种场景：

花了几个月、几百万，上了一套“新一代合同管理系统”，上线动员会红红火火，等到一年后再看，大家日常还是在 OA 里跑流程、在 Excel 里记台账，合同系统躺在菜单里吃灰——理由千奇百怪，但总结起来就一句话：“好像也没比原来强多少。”

AI 这两年又给了合同系统一个“重启”的机会。问题是，如果我们继续沿用过去那种“再造一个大系统”的思路，顶多就是多了几个“智能按钮”，很难真正把合同管理带进“能力工厂”的时代。

在上一篇总论里，彦祖抛了一个大框架：AI 时代的合同系统，更像是一套主干系统 + 一排可插拔能力组件。这篇我们就先不急着谈 AI，专门聊聊那根“主干”——它为什么适合建在低代码平台上，以及怎么设计，才不至于变成“另一套 OA”。

一、先把话说死：低代码不是“玩具”，但也不是“银弹”

先统一一下概念。阿里云那篇《万字长文读懂低代码》里，总结得很到位：低代码本质上是一种可视化的应用开发方式，用拖拽、配置为主，少量代码补洞，目标是“用较少代码、较快速度交付企业应用”。它要做的事情，大致可以拆成三块：

把大量重复性的底层代码封装成组件或“自动化动作”；

用图形化界面（GUI）把“表单、流程、页面、权限、集成”暴露给配置人员；

在必要的地方留出代码扩展点，让专业开发补上个性化逻辑。

换句话说，低代码不是在“消灭程序员”，而是在替程序员消灭重复劳动。传统开发里，那些“每个项目都要写一遍”的部分——认证、权限、流程引擎、表单引擎、列表页、导入导出、日志审计、常见集成……在低代码平台中，都被抽成了一块块“积木”。

阿里这篇文章里也提到，低代码平台比较关键的几个能力是：

可视化编程：通过拖拽组件画界面、搭流程；

预置组件与模板：常见业务场景不用从零搭；

快速迭代与一键部署：改完马上预览、快速上线；

多平台支持与集成能力：一次开发，多端运行，并且能跟 ERP / CRM / OA 之类对接；

代码扩展：留出高级定制空间，不把人“锁死”在几个配置项里。

听上去很美，但现实里，低代码也经常被吐槽成“玩具”：

业务同学玩了两周，发现复杂一点的逻辑还是要写代码；

技术同学嫌它“不够自由”“不够优雅”；

管理层担心“平台绑死”“未来难以扩展”。

所以，对合同系统这种长周期、强合规、重集成的产品来说，低代码既不是“万能钥匙”，也绝对不是“只适合做简单工具”的玩具。关键在于，你把什么东西放在低代码上，以及怎么设计“主干”。

二、为什么合同主干系统，天然适合建在低代码平台上？

我们先反过来想一个问题：如果完全不用低代码，只靠传统定制开发来做一套“新一代合同主干”，会遇到什么？

生命周期长、变化多：合同管理相关的流程，从拟定、审核、会签、签署、履约、变更、终止、归档，一改就是一大片；

角色多、权限复杂：业务、法务、财务、内控、管理层，一个角色一套视图，一堆权限矩阵；

集成面广：OA、ERP、CRM、电子签章、招投标平台、项目系统，哪一个不敢轻易碰？

行业差异大：甲方、乙方、工程、制造、金融，每家的合同习惯完全不同。

如果每次改流程、加字段、调权限都需要走一遍“提需求→评估→排期→开发→测试→上线”，你很快就会发现：

产品经理连画原型的心情都没有了，因为知道“要做很久”；

业务线觉得系统“跟不上自己节奏”，开始绕开系统干活；

IT 部门逐渐把这套东西当成“技术债”，谁都不想动。

从这个意义上讲，合同主干系统干的其实是“高频变更 + 重复要素”的活：

表单如何变，字段如何增减，是高频的；

审批流程如何调整、节点如何串接，是高频的；

不同行业/子公司差异化配置，是高频的；

打点、日志、权限、集成这些“底层活”，又极度重复。

而这些，恰恰是低代码最适合发挥的地方：

把“表单 + 流程 + 权限”这几个高频变更项，全部做成可视化配置；

把“日志 + 审计 + 集成”的基础设施固化在平台层，而不是每个项目复制粘贴一遍；

把行业差异沉到“配置和模板”里，而不是分支代码里。

泛微今承达这一路走下来，思路其实很清晰：

不把自己定位成“某个垂直行业的合同系统供应商”，而是定位成：用低代码承载各种合同/流程场景的主干平台；

合同只是这条主干上的一个“典型行业应用”，流程引擎、表单引擎、权限体系、集成中台，本身就是平台的组件。

所以，对合同主干系统来说，低代码并不是锦上添花，而是“避免被复杂度拖死”的必需品。

三、一个靠谱的“合同主干”，要扛住哪些事？

既然我们打算把合同主干架在低代码上，那这根主干到底要扛住什么？简单粗暴列一下，主干至少得干这几件事：

管全生命周期：从拟定、审核、会签、签署、履约、变更、终止、归档，系统里要有完整链路，别让用户在三个系统里来回穿梭；

管数据模型：合同、条款、相对方、项目、里程碑、收付款计划、保证金这些核心对象，要有统一的结构化表达方式；

管权限和合规：谁能看、谁能改、谁能导出、谁能作废，要说得清、查得出；

管审计和日志：每一次关键操作都要有记录，出事能追溯；

管集成：跟 OA 的流程、和 ERP 的收付款、和 CRM 的商机、和招标系统的标段，要有可维护的连接点。

这些事情有几个共同特点：

一旦设计好，就不会天天推倒重来，但会高频小改——比如多一个审批节点、多一个必填字段、多一条通知规则；

对安全性、稳定性要求很高——合规部门不会允许你每天在这里做“技术实验”；

和每一家企业的组织结构、流程习惯高度耦合——不可能统一一个版本喂所有人。

所以更现实的策略是：

在低代码平台上，把“生命周期 + 数据模型 + 权限 + 日志 + 集成”这几个大骨架先搭好；

允许每家在这个骨架上，通过配置去调整字段、流程、权限细节；

把“合同主干”当成一个**“可配置的产品模板 + 一组平台能力”**，而不是一个写死的成品系统。

阿里那篇长文里提到的“预置组件与模板”“多端支持”和“快速迭代”，其实就是在做这件事：

提供一套通用的“合同应用模板”，帮你少走一些弯路；

在这个模板之上，允许你按自己组织的玩法做差异化配置；

但无论你怎么改，底层的数据、日志、权限、集成都保持一致性。

四、在低代码平台上拆逻辑：让合同变成一盒可以“装配”的组件

站在产品经理视角，你在低代码平台上做合同主干，最核心的一件事不是去堆多少“页面”，而是把业务逻辑拆成一块块可以重用的组件。

举个简单的拆法：

“新建合同”不是一个页面，而是一条任务链：收集参数→选模板→生成草稿→触发审核；

“审批合同”不是一个按钮，而是一个审批节点组件：谁来审批、看到哪些字段、能改什么、不同意见怎么走；

“跟踪履约”不是一个报表，而是一组里程碑+提醒规则组件：约定什么节点看什么指标、谁收通知、逾期怎么升级。

在低代码平台上，这些都可以变成“可以拖的东西”：

表单组件（收集信息）、审批节点组件、通知组件、机器人组件、调用外部接口的组件……

产品经理和实施顾问真正要做的，是把这些组件按某个行业的“惯用打法”装配起来。

泛微今承达的玩法，本质上就是：

把大量通用组件（表单、流程、报表、门户、集成节点）打包放到平台里，

然后用一套可视化设计器，让顾问可以像搭乐高一样，把“一个行业的合同系统”搭起来。

你甚至可以想象未来这样一个场景：

“建筑工程行业合同套件”，点击创建，

平台自动给你生成：一套行业典型流程、一组合同模板、一堆预配置的提醒规则和台账视图，

你只需要根据自己公司情况做微调。

**这就是“主干 + 组件”的意义：**主干保证骨架稳、数据正、审计全；组件给你自由度，让你能按照自己行业和组织的节奏去玩。

五、AI 上场：把智能能力也做成“节点”，拖出一条“智能合同流水线”

说回 AI。上一篇我们聊过，AI 在合同领域最典型的几个能力包括：文档解析与 OCR、条款识别与结构化、智能比对、智能生成、风险识别与评分、智能提醒等。

在低代码主干的语境里，这些能力最理想的落地方式，就是变成“节点组件”：

一个“文档解析节点”，输入是原始合同（Word/PDF/扫描件），输出是结构化文本和版面信息；

一个“条款识别节点”，输入是文本，输出是打好标签的条款对象；

一个“比对节点”，输入是两版合同或合同+模板，输出是差异列表；

一个“风险评分节点”，输入是条款集合，输出是若干风险标签和分数；

一个“提醒节点”，输入是履约计划和执行数据，输出是各种消息和待办。

在这种设计下，低代码平台不是在“贴几个 AI 按钮”，而是在帮你画一条“智能合同流水线”：

业务上传或生成合同草稿；

系统自动触发解析+条款识别；

拿识别结果去和标准模板、历史合同做一次比对；

对关键条款打风险分，生成一页“智能摘要”；

把这份摘要推给相应的审批人；

合同通过后，自动拆解出履约里程碑，挂到项目和财务的待办里。

对产品经理来说，你要关心的不是“AI 会不会写合同”，而是：

这些节点的输入/输出长什么样，能不能在平台里标准化；

每个节点的KPI是啥：准确率、召回率、时延、采纳率；

节点之间的协作逻辑是什么：出错怎么回退、低置信度怎么交给人工兜底。

阿里那篇文章里提到，低代码平台通常会提供“代码扩展与定制”能力，这是我们在嵌 AI 节点时非常需要的一环：

平台负责大部分可视化编排和通用逻辑；

真正跟你公司业务强绑定的那部分，可以通过代码扩展来补足；

既保留了低代码的开发效率，又不牺牲精细化控制。

六、产品经理在这条路线上，具体要做哪几件事？

说了这么多，落到你我这种一线产品经理身上，在“低代码主干 + 可拖拽组件”这条路上，具体要干的事，大致有这么几条：

1. 先把“主干该管什么、不该管什么”说清楚

画一张非常粗的边界图：

主干一定要管的：生命周期流转、核心数据模型、权限/审计、日志、集成能力；

可以放到组件和生态里的：具体 AI 能力、特定行业的风控规则、复杂报表分析；

明确哪些事情“永远不想写死在主干里”，比如某几个大客户的极端定制诉求。

这一刀如果不早点切，后面就会陷入无尽的“谁来做这块”的拉扯。

2. 把现在业务在合同上的“十件大事”梳理清楚

别从模块出发，从任务出发：

业务：发起合同、看审批进度、查履约状态、看应收/应付节点；

法务：审合同、改条款、维护模板、看风险统计；

管理层：看合同对营收、利润、现金流、风险敞口的影响，识别高风险客户/条款。

每一件事，对应一条任务流；每条任务流，再拆成若干个“可以挂节点组件”的位置。

3. 在低代码平台里，把这些任务流变成“可以拖的图”

这一块比较考验你和实施顾问的沟通功底：

让大家看到的，不再是一堆菜单，而是一张张“任务编排图”；

每个节点的含义都能用一句话说清楚：“这个节点负责什么、谁来操作、输入输出是什么”；

在平台里落成之后，业务能看懂，顾问能改得动，而不是只有少数开发能维护。

4. 提前为 AI 留好“插座”和“护栏”

即便你现在还没准备好上 AI，也可以先为未来预留出接口位置：

在解析、比对、评分这些环节，设计好“由人干”和“由 AI 干”的切换开关；

把“AI 建议”和“最终决策”区分开，底层数据模型里保留好“建议 vs 采纳”的标记；

将来真接入能力时，只要在这些预留位置挂上对应的组件即可。

这样做的好处是：哪怕今天你只用规则引擎去实现“半智能”，明天也可以平滑地换成模型，而不需要推翻整条链路。

七、结语：低代码是“地基”，不是主角

回到标题那个问题：低代码主干系统应该怎么长，才不变成“另一套 OA”？

我自己的答案是：

第一，它要敢于接住合同管理里那些最难搞的“骨架问题”——生命周期、数据模型、权限、审计、集成，而不是只做几个好看的页面模板；

第二，它要把绝大部分复杂度“吃”在平台内部，让业务方和顾问看到的是可以操作的组件和任务流，而不是一大堆技术细节；

第三，它要提前为 AI 预留好节点和护栏，让智能能力进来时，有地方插、有规则管。

在这个意义上，低代码不是“卖点”，而是让合同主干有生命力的地基：

它决定了你以后改东西的成本，是“每一次都是项目”，还是“每一次都是配置”；

它决定了你的合同系统能不能跟上业务和技术的迭代，而不是上线三年就被打入冷宫。

至于上面提到的“能力组件基座”“三层模型”“任务编排”和“开放生态”，我们在后面的几篇里再慢慢拆开聊。对彦祖来说，这一篇更像是在总论篇画的那张大图上，把“低代码主干”这根骨头勾画清楚：它为什么重要、应该长什么样、产品经理在这条路上到底要做些什么。