法大大专业合同起草

合同智能起草 Skill

概述

本 skill 指导智能体根据用户提供的合同背景信息，智能分析并起草完整、专业的合同文本。起草流程分三步：信息理解 → 合同大纲 → 合同正文。

第一步：判断起草模式

首先判断用户是否上传了文件，据此进入不同分支。

在进入各模式之前，先完成意图澄清判断：

意图澄清：何时发起结构化澄清

优先使用当前运行环境提供的结构化交互能力发起澄清（如桌面端可选项窗口）。若当前环境没有该能力，则改为用一句简短自然语言问题澄清后继续，不得因缺少弹窗工具而中断起草流程。

以下情况应先澄清，不得自行假设后直接起草：

情况一：上传了单个文件，但意图不明

触发条件：用户上传文件后，描述语句中没有出现"模板"、"套用"、"参考"、"按这个格式"等明确意图词，且文件内容读取后既可能是模板也可能是参考材料（如：一份完整的合同文本，但不确定用户是要套用它还是参考它）。

澄清问题：

question: "您上传的这份文件，您希望如何使用？"
options:
  - "套用它的框架和条款结构，填入我的业务信息"   → 进入模式二
  - "仅作为参考背景，请帮我重新起草一份"         → 进入模式三

情况二：上传了多个文件，角色不明

触发条件：用户上传了 2 个及以上文件，且未说明各文件的用途。

澄清问题：

question: "您上传了多份文件，请问它们的用途是？"
options:
  - "其中一份是模板，其余是参考材料"
  - "全部都是参考材料，请综合起草"
  - "让我来分别说明一下"

若用户选择"其中一份是模板"，则进行第二轮澄清：

question: "请问哪份文件是您要套用的模板？"
options: [列出上传文件的文件名供用户点选]

情况三：合同类型不明，且无法从上下文推断

触发条件：用户描述过于简短（如仅说"帮我起草个合同"），既没有上传文件，也没有任何关于交易类型、业务场景的描述。

澄清问题：

question: "请问您需要哪类合同？"
options:
  - "服务 / 委托合同"
  - "采购 / 买卖合同"
  - "保密协议（NDA）"
  - "其他（我来描述）"

若信息仍不足以判断（比如用户选了"其他"后描述依然模糊），可再追问一次，但最多澄清 2 次，之后根据已有信息做出合理假设并继续，不得反复追问。

何时不需要弹出，直接判断进入模式

• 用户描述中有明确意图词：直接进入对应模式
• 文件名或文件内容已能明确区分用途（如文件名含"模板"、"template"、"标书"等）
• 用户上传文件的同时提供了充分的业务描述，说明是要填入的内容：直接进入模式二

模式一：纯描述起草（无上传文件）

用户以自然语言或结构化方式描述需求，由智能体从零起草。

参考输入格式（用户也可自由描述）：

帮我起草一份[合同类型]，
我方为[甲方/乙方、名称、联系方式等]，
相对方为[甲方/乙方、名称、联系方式等]。
本合同目的是[项目/业务/交易说明]，
合同中需明确[标的、费用与支付、双方权利义务、违约责任、争议解决等]。
本合同我方核心要求为[如保密义务、验收标准、知识产权归属等]。

提取信息后 → 进入第二步（起草大纲）→ 第三步（起草正文）。

模式二：上传合同模板 → 填空起草

用户上传了一份合同模板（自己公司的标准合同、行业范本等），希望保留模板的框架和条款结构，将自己的业务信息填入其中。

识别特征：用户说"用这个模板"、"按这个格式"、"参照这份合同"，或上传文件后描述的是具体业务信息而非起草要求。

执行步骤：

1. 读取模板文件

   • 若为 DOCX/PDF 文字层：直接提取全文结构
   • 若为扫描件 PDF（无文字层）：调用 fadada-scanned-ocr skill 先做 OCR，再提取结构
   • 提取模板的：章节结构、空白占位符（如"___"、"【】"、"[ ]"）、固定条款、可变条款

2. 分析模板框架，向用户简要确认：

   已读取您的合同模板，框架如下：
   - 合同类型：___
   - 共 X 条，主要条款：[列举核心条款名称]
   - 需要填入的关键信息：[列出空白项，如甲乙方名称、金额、期限、服务内容等]
   
   请确认是否按此框架起草，或说明需要调整的地方。
   

3. 提取用户描述中的业务信息，对照模板空白项逐一匹配填充

4. 处理模板未覆盖的用户需求：

   • 若用户有模板中不存在的条款需求（如特殊的知识产权约定），在对应位置新增条款并注明"【新增】"
   • 若模板某条款与用户需求冲突，保留用户需求版本并注明"【已调整】"

5. 输出完整合同正文，末尾附【调整说明】，列出新增或修改的条款及原因

模式三：上传参考文件 → 辅助起草

用户上传的是参考材料（项目标书、行业标准、对方给的草稿等），不是要直接套用的模板，而是作为起草的上下文和依据。

识别特征：上传的是标书、招标文件、技术方案、对方合同草稿等，用户说"参考这个"、"根据这份材料"。

执行步骤：

1. 调用 fadada-contract-extractor skill 提取文件中的结构化信息

   • 若待抽取文件为扫描件，可先调用 fadada-scanned-ocr 获取正文文本；若 extractor 自身预处理链路已覆盖该步骤，则按其既有链路执行，不在本 skill 中重复抽取
   • 运行基本信息模式，提取甲乙方、金额、期限、标的、交付物等字段
   • 若参考文件本身是一份合同草稿（如对方提供的版本），可同时运行履约信息模式，抽取付款节点、交付安排等事件作为起草依据
   • 若参考文件是标书、技术方案等非合同文件，只跑基本信息模式，不运行履约信息模式（此类文件缺乏合同履约结构，履约抽取无意义）
   • 抽取字段使用 fadada-contract-extractor 的系统默认字段，无需额外指定

2. 将抽取结果与用户的文字描述合并补全，形成完整的合同要素清单（抽取结果优先，用户描述补充缺失项）

3. 按模式一的流程：起草大纲 → 起草正文，以合并后的信息为事实依据填充各条款

模式二的信息提取补充

模式二（模板填空）中，若用户同时上传了模板文件和其他业务材料（如同时上传了"我司标准服务合同.docx"和"项目标书.pdf"），则：

• 对模板文件：读取框架结构，不调用 extractor
• 对业务材料：调用 fadada-contract-extractor 基本信息模式抽取填充所需字段
• 将抽取结果对照模板空白项逐一填入

信息提取清单（三种模式通用）

起草控制变量

合同立场

• 用户明确说明“我方是甲方 / 乙方 / 买方 / 卖方 / 委托方 / 受托方”等时，按该立场起草
• 用户未明说但上下文可推断时，可直接推断，并在大纲中点明角色
• 若立场仍不清楚，优先澄清；无法澄清时按中性版本起草，不擅自明显倾斜风险分配

第二步：起草合同大纲

在生成正文前，必须先完成合同大纲规划。该大纲作为内部组织步骤使用；若用户未要求查看大纲，则不要把 Markdown 大纲作为最终交付内容写入 docx。格式如下：

## 【合同名称】起草大纲

**合同类型**：___
**甲方**：___（角色：___）
**乙方**：___（角色：___）

### 章节结构

第一条 定义与解释
第二条 合同标的
第三条 合同价款与支付方式
第四条 履约期限与交付
第五条 双方权利与义务
  - 甲方权利义务
  - 乙方权利义务
第六条 验收标准与程序（如适用）
第七条 知识产权归属（如适用）
第八条 保密条款（如适用）
第九条 违约责任
第十条 不可抗力（如适用）
第十一条 合同变更与解除
第十二条 争议解决
第十三条 其他约定
第十四条 附则（签署页）

**我方核心保护条款重点**：___
**待补充信息**：___（如有）

根据合同类型灵活调整章节，如保密协议可简化为5-7条，工程合同可增加质量保证、安全生产等专项条款。

大纲生成规则

• 若用户已提供章节结构、模板章节或明确目录，必须优先保留该结构，仅补足缺失的必要章节并优化命名和顺序
• 若用户未提供结构，则根据合同类型、合同立场和核心交易条款生成完整大纲
• 大纲默认控制在两级结构内；除非用户明确要求，不再向下细分三级标题
• 大纲中不要单独设置“各方基本信息”“合同份数”“签字盖章”之类章节；这些内容属于正文抬头、尾部或签署页
• 各章节之间不得明显重叠；付款、验收、知识产权、保密、违约责任、争议解决等高冲突条款应各自独立
• 若需要更细的大纲编号或二级标题描述写法，参见 references/outline-generation.md

第三步：起草合同正文

起草原则

1. 法律规范性：条款表述严谨，使用法律惯用语，符合《中华人民共和国民法典》合同编及相关法规要求
2. 我方利益保护：在平等原则下，重点强化用户标注的核心要求条款
3. 完整性：每个章节均需实质性内容，不得出现空置条款
4. 可执行性：金额、期限、标准等关键信息明确量化，避免模糊表述

正文格式规范

[合同名称]

合同编号：___________

甲方：___________
地址：___________
联系人：___________
电话：___________

乙方：___________  
地址：___________
联系人：___________
电话：___________

鉴于甲乙双方本着平等自愿、诚实信用的原则，经友好协商，就[合同事项]达成如下协议：

第一条 【条款名称】
  1.1 ...
  1.2 ...

第二条 【条款名称】
  ...

[各条款正文]

本合同一式___份，甲乙双方各执___份，具有同等法律效力。

甲方（盖章）：___________     乙方（盖章）：___________
法定代表人（签字）：_______   法定代表人（签字）：_______
日期：___年___月___日         日期：___年___月___日

具体可参见references/chapter-drafting.md

正文生成规则

• 正文必须严格围绕已确认的大纲展开，不为了“看起来完整”而加入与当前交易弱相关的低价值通用条款
• 必须体现合同立场，在付款条件、验收标准、知识产权、保密义务、违约责任、解除权、争议解决等关键位置进行一致的风险分配
• 正文中的主体称谓统一使用“甲方”“乙方”“丙方”或“买方”“卖方”等角色称谓；除抬头、签署页或模板保留位置外，不重复写主体全称
• 缺失但必须保留的位置，统一使用 【】 或模板中的既有占位方式，不编造事实
• 若用户提供了参考法规或明确要求引用特定规范，仅能依据已提供材料或可确认的现行规则表述；不要编造具体法条号或不存在的规范依据
• 若按章节逐段起草，或要处理“当前章节”和“参考材料”之间的取舍，参见 references/chapter-drafting.md

关键条款起草要点

参见 references/clause-guidelines.md 了解各类核心条款的起草要点与示例。

执行流程

读取用户输入
        ↓
意图澄清（必要时发起结构化澄清；若无该能力则简短追问）
        ↓
判断是否有上传文件？
    ├── 无文件
    │   → 【模式一】从描述提取信息 → 大纲 → 正文
    │
    ├── 有文件，是合同模板
    │   → 【模式二】读取模板结构 → 确认框架
    │       ├── 若同时有业务材料 → 调用 fadada-contract-extractor（基本信息模式）→ 填空起草
    │       └── 若只有模板 → 从用户描述提取信息 → 填空起草
    │
    └── 有文件，是参考材料
        → 【模式三】调用 fadada-contract-extractor
            ├── 非合同文件（标书/方案）→ 只跑基本信息模式
            └── 合同草稿 → 基本信息模式 + 履约信息模式
        → 合并用户描述 → 大纲 → 正文
        ↓
正文末尾注明【待补充信息清单】（如有缺失字段）
模式二额外附【调整说明】（列出新增/修改条款）

注意：

• 模式一/三：信息充分时大纲+正文连续输出；合同类型不明、双方主体不清时先发起结构化澄清；若当前环境无该能力，则用一句自然语言确认
• 模式二：读取模板后必须先向用户确认框架，再进行填空起草；确认方式同样优先使用结构化澄清，不具备时退化为自然语言确认
• 调用 fadada-contract-extractor 时，字段使用其系统默认字段，不需要额外指定；extractor 负责信息抽取。若待抽取文件为扫描件，可先调用 fadada-scanned-ocr 获取正文文本，或按 extractor 的既有预处理链路执行

输出交付

默认行为（用户未指定格式时，文件优先）

合同正文起草完成后，默认以文件交付为主，按以下顺序执行：

1. 自动生成 Word 文件：调用 docx skill，按以下要求生成 .docx 文件
2. 对话窗口回执：简要告知合同名称、交付模式、输出文件路径和待补充信息；除非用户明确要求，不在窗口重复输出完整正文

默认保存目录为当前工作目录；若用户明确指定保存路径，则以用户路径为准。文件命名规则：【合同名称】_草稿_YYYYMMDD.docx，无法获取合同名称时命名为 合同草稿_YYYYMMDD.docx。

调用 docx skill 的执行要求（必须遵守）

必须使用 docx skill 的 "Creating a new Word document" 工作流，即读取 docx-js.md 后编写 JavaScript 脚本用 docx-js 生成文件。严禁直接将合同文本写入 .docx 文件——那样打开后只会显示原始文本，不是合法的 Word 文档格式。

排版格式：严格按照 references/chapter-drafting.md 中"行文排版格式规范"一节执行，包括：

• 字体：合同名称宋体加粗二号居中；甲乙方信息、正文、小标题均为仿宋四号；编号和数字用 Times New Roman
• 段落：正文首行缩进 2 字符，行距固定值 25 磅；合同名称行距固定值 28 磅；表格单倍行距
• 页边距：上 2.5cm、下 2.5cm、左 3cm、右 2.5cm
• 页码：底端居中，Times New Roman 五号，页脚距底端 1cm

内容清洗：传给 docx-js 前须去除所有 markdown 语法符号（**、#、---、- 列表前缀），占位符 【】 和 ___ 保留原样。

回复规范：排版格式属于后台默认处理，不得在对话回复中列出或说明任何排版参数（字体、行距、页边距等）。回执只需告知文件名和保存路径。

用户指定格式时

模式二（模板填空）的特殊处理

若用户上传的模板是 .docx 格式，不得修改原模板文件。调用 doc skill 新建一份文档，以模板的样式和结构为参照重新排版，将填入内容写入新文件，原模板保持不变；若用户明确指定保存路径，则按用户路径输出。

常见合同类型参考

注意事项

• 本 skill 生成的合同为参考草稿，建议用户根据实际情况调整，重要合同建议法律专业人士审核
• 涉及特殊行业（金融、医疗、建工等）时，需提示用户注意行业监管合规要求
• 模式二（模板填空）原则：最大程度尊重模板原有条款和结构，仅在用户有明确需求时新增或修改条款，每处改动须标注说明
• 若用户上传文件无法读取（加密、损坏，或经 OCR 后仍不可识别），立即告知用户，请其提供可读版本