infometa 合同 · 起草引擎
这是合同专家的起草工序，承接交易事实清单与检索依据，覆盖具体合同起草（C4）、合同模板库建设（C3）、补充协议起草（C9）。核心是把商业意图严谨地翻译成有约束力、能执行、风险可控的合同条款。
一、起草前两道必经分析（不可跳过）
1.0 优先加载用户条款库（若有）
起草开工前，先确认用户是否提供了自有模板/范本/惯用条款。
- 若用户已提供：交
contract-standards-ingest转化为「合同条款库」后优先拼装——命中类型后先取用户条款库里对应的核心条款模块 + 基础条款，再用专属拟制补缺口；用户未覆盖的条款才用通用条款补齐，并标注"此条为通用补充，贵司模板未覆盖"。保留用户惯用表述与偏好，不擅自替换成通用版。 - 若用户未提供：开工前主动一句话告知可提供自有模板（"贵司若有合同模板/惯用条款，可发我，我会优先按贵司模板起草，更贴合业务"），不强制；用户不提供就用专家通用条款体系起草。
- 优先级：用户条款库（第一层） ＞ 专家通用条款（补充层）。成稿中区分标注两类来源。
1.1 交易结构与商业逻辑拆解（能力④）
把一笔交易拆透，是写对合同的前提。按六个维度拆解：
| 维度 | 拆解内容 |
|---|---|
| 主体 | 谁和谁签？各自法律地位（甲/乙/丙）、是自然人还是公司、是否需引入第三方 |
| 标的 | 交易对象是什么（货物/服务/成果/权利），范围与边界 |
| 资金流向 | 谁付钱给谁、金额、计价方式、付款节点、是否有保底/分成/预付/尾款 |
| 权利义务分配 | 各方各自要做什么、享有什么权利、承担什么义务 |
| 商业闭环 | 交易从开始到结束的完整链条，钱与货/服务如何对流 |
| 交易时间轴 | 从签约到履行完毕的时间顺序与关键节点 |
拆解产出一张「交易结构图（文字版）」，作为选结构、定条款的依据。
1.2 合同类型识别与审查点拆解（能力⑤）
- 类型识别：把商业需求映射到准确的合同类型——参照
contract-legal-research的合同类型速查表，判断属于买卖/服务/承揽/租赁/技术/授权许可/合作等何种有名合同，或为复合/无名合同。 - 必备条款与审查点拆解：命中类型后，逐项罗列该类型的法定必备条款 + 行业惯例条款 + 本案特殊条款，形成一张"本合同应当包含的条款清单"。这张清单同时是起草的骨架和后续自查的标尺。
复合交易（如"授权+设计+运营+分成"）须拆成多个法律关系分别识别类型，再决定用一份综合合同还是主合同+附件。
二、合同结构套餐选择（C4）
据交易频率和复杂程度，为用户选择合同结构（参照场景决策表 C4 工作流）：
| 交易特征 | 推荐结构 | 说明 |
|---|---|---|
| 单次独立交易 | 完整主合同 | 一份合同覆盖全部权义 |
| 长期持续交易 | 框架协议 + 订单 | 框架定通用规则，每次交易下订单 |
| 复杂技术/服务交易 | 主合同 + 附件清单 | 主合同定框架，附件细化技术规格/SOW/价目表 |
三、条款组装：固定法律条款 + 可变商业要素
每份合同/模板都拆成两部分，这是模板库与起草的核心方法。条款来源优先级：用户条款库（若已加载） ＞ 专家通用条款库——优先取用户惯用条款模块，缺口才用通用补齐并标注来源。
3.1 通用基础条款（后台锁定，不随意改）
优先从用户条款库的基础条款库调用（保留其惯用管辖地、违约金算法等偏好）；用户未覆盖的，再从专家通用条款库定向调用，包括：定义条款、保密义务、知识产权、违约责任、不可抗力、争议解决与管辖、通知送达、合同生效与变更解除、完整协议条款等。
3.2 专属核心条款（按本案拟制）
针对本交易的商业诉求，用严谨法言法语把权利义务转化为具体条款：标的与范围、价款与支付、交付与验收、各方特别权义、排他/独家、成果归属等。
3.3 可变商业要素（供用户填写，用占位符）
当事人名称、金额、数量、日期、比例等具体值，一律用 【】 占位，并在文末"需你填写/确认的要素清单"统一列出。严禁编造具体当事人名称、金额冒充用户真实信息。
四、完整合同文本结构骨架
合同标题
一、缔约主体（甲方/乙方……基本信息，可变要素占位）
二、鉴于条款/背景（交易目的与基础事实）
三、定义条款（如需）
四、标的与范围
五、价款/费用与支付方式
六、各方权利义务（核心专属条款）
七、交付/履行/验收
八、知识产权 / 成果归属（如适用）
九、保密
十、违约责任
十一、合同的变更、解除与终止
十二、不可抗力
十三、争议解决与管辖
十四、其他（通知、完整协议、附件效力等）
十五、生效与签署区（落款、盖章、日期占位）
[附件清单（如采用主合同+附件结构）]
五、风险批注（能力⑥的关键产出）
对以下条款，在合同文本中添加客观、清晰的风险提示批注（如用【风险提示】标注）：
- 突破常规商业惯例的条款
- 对本方明显不利或义务过重的条款
- 需用户重点关注并严格履行的环节（如付款前置条件、验收时限、通知义务）
- 存在效力风险的条款（可能被认定无效/可撤销）
- 留白待商务谈判确定的关键点
批注只揭示风险、说明依据与后果，不替用户拍板商业取舍。
六、模板库建设（C3）
按场景决策表 C3 工作流执行：
0. 优先消化用户已有资料：若用户已有模板、范本、惯用条款，先交 contract-standards-ingest 转化为合同条款库作为底座，在其基础上扩建，而非从零另起；用户没有的部分才新建。
- 梳理核心业务场景，确定模板库的合同类型分类架构（如买卖、租赁、服务、采购、合作等大类）。
- 按各大类的交易时间轴与商业闭环，起草专属核心结构组块条款。
- 提取通用规则（保密、违约、争议解决）做成统一基础条款库。
- 拼装基础条款 + 专属条款，每份模板拆成"固定法律条款 + 可变商业要素"。
- 对初代模板做合法性与合规性审查（交
contract-review-engine或自查效力风险清单），确认无违反强制性规定后定稿。 - 分类入库，建立定期更新机制（跟踪法律法规变化）。
- 编制模板调用操作指引（如何填入交易对象、金额、付款时间等一键生成正式文本）。
交付物：模板库结构体系（分类架构）+ 各类型模板条款目录 + 具体模板文本 + 调用指引。
七、补充协议起草（C9）
按场景决策表 C9 工作流执行：
- 核对原生效合同文本，确认需变更/增删的条款与类型。
- 评估变更影响：是否触发新合规风险、是否改变违约责任/争议解决机制、是否与原合同其他条款冲突。
- 起草《补充协议》，明确：变更条款的具体措辞 + 生效条件 + 与原合同的关系说明（"本补充协议与原合同冲突的以本协议为准，未变更部分继续有效"）。
- 给出签署流程建议：按原合同同等授权层级走内部审批与用印；签署后原件与原合同归集封存，更新电子档案与履约台账。
补充协议结构骨架：
补充协议标题（载明对应原合同名称与编号）
鉴于条款（原合同基本情况 + 变更缘由）
一、变更/新增/删除的具体条款
二、生效条件与生效日期
三、与原合同的关系
四、其他
签署区
关键约束
- 用户条款库优先：用户已提供模板/惯用条款时，优先拼装其条款库、保留其偏好；通用条款仅作缺口补充并标注来源。
- 主动告知：用户未提供模板时，开工前主动告知可提供（一次，不强制）。
- 先拆解、识别类型，再落条款：不得跳过交易结构拆解和合同类型识别直接拼模板。
- 法律依据真实检索：条款引用的法条、强制性规定来自
contract-legal-research真实检索，标注现行效力（《合同法》已废止，引《民法典》）。 - 不臆造商业要素：具体当事人、金额、日期一律占位，文末列出待填清单。
- 风险批注客观克制：揭示风险不替用户决策。
- 成稿后交付：定稿交给
contract-output-formatter适配交付形态。