AI 起草不是让模型写小作文：条款库怎么把模板变成可用资产

AI 起草的短板不在文笔，在条款资产

让模型写一份合同，出来的稿子读起来通顺，拿给法务一看却满是问题。条款该有的兜底没写，该留的选择权没留，风险分配的落点全是空的。

问题不在模型的写作能力。模型缺的是这家企业的条款资产：哪些条款是这家公司反复在用的、哪些措辞是法务逐字打磨过的、哪些条件必须按业务类型切换。这些内容不在公开语料里，只在企业自己的合同库里。

条款库要拆到能被组合的粒度

条款库的第一步不是收集整份合同，是把合同拆到条款级。

拆到条款级，才谈得上组合。一份采购合同可以拆成主体条款、标的条款、价款与支付、交付与验收、质量保证、违约责任、争议解决几个模块。每个模块下再分几个可选条款，分别对应不同的业务情形。

颗粒度太粗，条款库就退化成模板库，换汤不换药；颗粒度太细，条款之间互相依赖，拼起来反而容易冲突。落点是把「一段完整意思表达」作为一个条款单元，能独立成立，也能和其他条款拼接。

拆的动作要跟签署链路对上。条款库里的模块划分，应该和合同生成时的变量字段一一对应：交付条款对应交付节点字段，价款条款对应付款方式字段。对不上的条款，说明它还没被拆到可调用的程度。

每个条款要标清楚三件事

条款进库，必须带上可判断的标签，光有一段文字没有用。

第一是适用条件。这一条在什么业务类型下启用，什么情况下必须删掉。适用条件写清楚，AI 才知道什么时候该调它。

第二是风险等级。这一条是常规表述，还是法务重点关注的高风险兜底。风险等级决定它是否可被修改，以及修改后要不要回审。

第三是来源与版本。这一条是谁定的、依据什么来的、上次改是什么时候。版本可追溯，条款库才不是一潭死水。

三件事标齐，条款库才算从文档集合变成了可调用的资产。

标完之后还要能查。法务提一个改动要求时，系统要能回答：这条改动影响哪几类合同、哪几个模板、哪些已发出的流程在用旧版本。答不上来，条款库就没法被放心修改。

AI 起草的动作是组装，不是从零写

有了条款库，AI 起草的动作就变成组装。

系统按合同类型和业务要素，从库里挑出适用条款，按预设顺序拼成初稿。付费方式、交付节点、保证期这些变量由业务表单填入，条款正文保持库里的原样。

这样出来的初稿，措辞是法务确认过的，风险点该有的兜底都在。AI 不再自由发挥，改动范围也被限定在变量填空和条款取舍上。

关键设计是留痕。哪一条是 AI 挑的、哪一条被人改过、改成了什么，系统要记下来。这份记录后面回审时用得上。

留痕还有第二个作用：哪些条款经常被人工改掉，说明库里的表述和业务实际不吻合。这类条款是重点优化的对象。

模板库和条款库不是一回事

很多企业已经有模板库，容易把两者当成一回事。它们的差别在复用粒度。

模板库复用的是整份文件。一份「标准采购合同模板」拿到手，要改的地方如果只是换个付款方式，也要在整份文档里改。模板一多，改一处口径要动很多份。

条款库复用的是条款。付款条款改一次，所有引用这条的合同类型同时生效。条款是共享的，模板是条款的组合结果。

两套并行维护会互相打架：模板里的条款和条款库里的版本对不上，法务不知道该以哪边为准。合理的关系是模板由条款组装而成，模板本身不存条款正文，只存条款引用顺序和变量映射。

生成结果怎么回到审查

AI 起草和 AI 审查不该是两套系统。生成的稿子要能直接进审查环节。

审查这一端要能识别出哪些条款来自库、哪些是人工新增。来自库的条款按库里的规则审，人工新增的条款按通用风险规则审。两者的审查标准不一样，混在一起审会浪费注意力。

审查结论要能回写到条款库：某一条款在多次审查中都被判定为高风险，就说明这一条的表述本身有问题，该进库改。库改好了，下一次生成的初稿质量就往上走一格。

形成这个循环，条款库才是活的；不形成，它就是一堆静态文档，AI 每次都要重新踩同一个坑。

审查结论回到原文也是同一个道理。判定某一条有风险，审查结果必须能定位到条款库里的哪一条，而不是只给一个笼统的分数。定位得到，改动才有落点。

制造业客户的模板批量处理怎么落地

制造业的合同场景能检验条款库设计。这类企业合同类型多、批量大，模板管理一直是难点。

一个制造集团的合同类型可以到几十种，采购、销售、委外加工、设备租赁、物流服务各不相同。每个类型下又有标准条款和业务特批条款混用。模板各业务线自己做自己的，同一份采购合同在不同工厂的条款口径对不上。

把条款收进统一库之后，模板由条款组装而成，业务线只选条款和填变量，不再各写各的模板。批量发起时按 Excel 导入要素，系统按模板生成文件并预设签署位置，一次发起多份。

对账单、采购合同这类高频文件用同一套条款口径，跨工厂的合同条款就能对齐。对齐之后，集团层面的合同审查和统计才有统一的比较基准。

什么场景先别上条款库

条款高度非标的合同，不放进第一批。

工程总承包、投融资协议这类合同，每份的核心条款都和项目强绑定，可复用的只是框架，硬拆成条款反而增加维护负担。这类合同先把结构化字段管住就够了。

判断标准是复用频率。一个条款在一类合同里反复出现，才值得进库；一份合同里的条款都是独一无二的，进库只是换个地方存文档。

条款库该从哪一步开始

先别急着把历史合同全搬进来。

从当前使用频率最高的三五个合同类型入手，把这几类的条款拆出来、标好适用条件和风险等级，跑一轮 AI 起草加审查的循环。跑通了，再往其他类型扩。

一开始就追求全覆盖，条款标不完，标完了也没验证过，最后变成没人维护的静态文档。条款库的价值来自被调用和被迭代，不来自条目数量。