AI 起草合同不是生成一篇小作文：条款库怎么让模板活起来

AI 合同起草是 2025 年以来电子签平台最热闹的功能方向。有一种听起来很诱人的叙事：给大模型一个指令——比如起草一份上海市标准商铺租赁合同——大模型在几十秒内生成一份几千字的合同文本。技术上是可行的，但实际用起来问题很大。

第一个问题是不可控。大模型生成的内容没有条款级别的追溯——你不知道某一个条款引用的是哪部法规的第几条、上一次是谁修订的、和公司的标准条款是否有出入。第二个问题是不可管理。生成了一千份合同之后，如果需要统一修改某一个条款，比如违约金比例调整，你没法批量化地改——每一份都是独立生成的文本，版本是散的。

真正适合企业级场景的 AI 合同起草，不是在空白页面上凭空生成文章，而是在已有的条款库和模板结构上做智能填充和组合。这个逻辑理顺了，AI 才能从好玩变成好用。

条款库：AI 起草的地基

合同条款库是 AI 起草最基础的一层，也是最容易被跳过去的一层。它的功能看似简单——把企业的标准化条款分类录入系统——但这一步决定了后续所有 AI 操作的质量天花板。

条款库把散落在不同法务脑子里的标准条款，变成了可检索、可分组、可追踪版本的系统资产。法务部门最头疼的场景之一是人走了条款也走了——一个资深法务离职后，他用了五年的定制条款、他知道但没写成文档的条文边界，全部消失。条款库把这些隐性知识显性化了：不是替代法务的判断，而是给法务的判断留下记录。

从实践角度，条款库的上线顺序应该是：先把使用频率最高、争议风险最大的那几类条款入库——违约金条款、解约条款、保密条款、知识产权归属条款。这四类条款几乎出现在每一份商业合同中，而且一旦出问题就是大问题。之后逐步扩展至行业特定条款、关联交易条款等长尾场景。

e签宝的条款库支持按场景分类录入条款，每条条款有明确的适用场景标签和引用来源。法务部门可以把采购合同中适用于 100 万以上订单的违约金条款和适用于标准订单的违约金条款分别录入两组，标注不同的触发条件。条款库目前支持 200 条条款的上限，支持分组管理和搜索，支持引用追踪——每一份使用了该条款的合同都可回溯到条款库的当前版本。

有了这一层，AI 起草就不再是让大模型自由发挥，而是根据合同类型和场景条件，从条款库中调取匹配的条款组合。输出的每一段文本都是可追溯的——法务可以逐条确认：这一条来自条款库序号 37，版本 V2，2025 年 11 月由法务总监审定。

模板控件联动：从条款到合同的桥梁

条款库解决了有什么条款可用的问题，模板控件联动解决的是怎么把条款填进合同里的问题。

条款库和模板控件联动的底层逻辑是：让 AI 不碰不可控的文本生成，而是做可审计的结构化匹配。这个设计理念决定了 AI 合同起草在企业级场景中的天花板比纯大模型方案更高——因为每一次输出都可以逐条回溯到条款库中的源条款，法务的审核工作从"通读全文判断是否合理"变成了"逐条确认条款匹配是否正确"。审核效率的差异在合同量大的企业里会被放大几十倍。

传统合同模板是一个静态的框架——固定文本加需要手动填写的空白区域。AI 智能添加控件之后，系统可自动识别合同文本中哪些位置需要填写、自动匹配对应的控件类型并预填结构化数据。更进一步，模板控件之间可设定联动规则：如果合同金额超过 50 万，自动触发某一条风险提示条款；如果合同类型是采购，自动从条款库中调取采购场景的标准条款组。

这个逻辑和条件规则引擎类似——模板不再是一个死文档，而是一套输入条件匹配条款生成合同的规则引擎。AI 在这里的角色不是创作，而是匹配和组合。

协商起草：AI 参与的下一站

单方面起草是 AI 的第一步，合同协商才是真正的重头戏。甲乙双方对合同条款有分歧时，传统做法是在 Word 里来回批注、邮件往返沟通、最终由法务手工合并定稿。这个过程在跨企业场景下尤其痛苦——每一方有自己的版本和修改偏好。

e签宝的协商起草功能对接了 WPS 在线编辑，支持多角色修订批注和版本管理。跨企业协作时甲乙双方各有独立的编辑权限，修订记录清晰可查，最多支持 20 人同时在线、500 条修订记录。定稿后直接发起合同签署——起草、协商、签署在同一套系统里闭环。这意味着从 AI 起草第一稿到双方协商定稿再到电子签署，合同全流程的文本版本都是连贯可追踪的。

AI 合同起草的价值不在快，在可追溯。单纯用大模型生成一篇合同文本，快则快矣，但企业级的合同管理需要回答的不是这段文字通顺不通顺，而是这段条款的依据是什么、上一次修改是什么时候、改了之后谁审的。没有条款库和模板控件联动做地基，AI 合同起草就是空中楼阁。