# 法大大专业合同起草 > 合同智能起草专用 skill。当用户需要起草、撰写、生成合同文本时必须使用本 skill，包括但不限于： - 用户说"帮我起草一份合同"、"写一份协议"、"生成合同"、"起草合同正文"等 - 用户提供了甲乙双方信息、合同目的、核心条款需求，希望生成完整合同文本 - 用户上传了合同模板文件，希望按模板框架填入自己的具体业务内容 - 用户上传了标书、参考合同、行业标准等参考文件，要求据此起草合同 - 用户说"用模板起草"、"按照这个格式帮我写合同"、"参考这份合同帮我起草"等 - 即使用户只说"我需要一份采购合同"或"帮我写个保密协议"，也应触发本 skill 本 skill 支持三种模式：①自然语言描述起草 ②上传模板+描述需求填空起草 ③上传参考文件辅助起草。 - Skill: `ahang1598/skill-200` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add ahang1598/skill-200` - Raw SKILL.md: https://api.skillmd.com/api/skills/ahang1598/skill-200/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: ahang1598 (https://skillmd.com/u/ahang1598) - Updated: 2026-09-09 - Page: https://skillmd.com/skills/ahang1598/skill-200 --- # 合同智能起草 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 语法符号（`**`、`#`、`---`、`-` 列表前缀），占位符 `【】` 和 `___` 保留原样。 **回复规范**：排版格式属于后台默认处理，**不得**在对话回复中列出或说明任何排版参数（字体、行距、页边距等）。回执只需告知文件名和保存路径。 ### 用户指定格式时 | 用户说 | 执行动作 | | --------------------------------- | ------------------------------------------------------------ | | "只在窗口看就行" / "不用生成文件" | 仅窗口展示，不生成 Word | | "给我 Word" / "保存文档" / "下载" | 生成 `.docx` 文件并返回保存路径；用户要求时再在窗口展示全文 | | "给我 PDF" | 调用 `pdf` skill 生成 `.pdf` 文件，默认保存到**当前工作目录**，并返回保存路径 | ### 模式二（模板填空）的特殊处理 若用户上传的模板是 `.docx` 格式，**不得修改原模板文件**。调用 `doc` skill 新建一份文档，以模板的样式和结构为参照重新排版，将填入内容写入新文件，原模板保持不变；若用户明确指定保存路径，则按用户路径输出。 ## 常见合同类型参考 | 合同类型 | 核心条款重点 | | ------------- | --------------------------------------- | | 服务合同 | 服务范围、交付物、验收标准、服务期限 | | 采购/买卖合同 | 货物规格、数量、质保期、交货方式 | | 保密协议(NDA) | 保密信息定义、保密期限、违约金 | | 软件开发合同 | 需求文档、里程碑、知识产权归属、BUG修复 | | 劳务/外包合同 | 工作内容、结算方式、社保责任 | | 租赁合同 | 租赁物状态、租金、押金、维修责任 | | 合作协议 | 合作范围、收益分配、退出机制 | --- ## 注意事项 - 本 skill 生成的合同为**参考草稿**，建议用户根据实际情况调整，重要合同建议法律专业人士审核 - 涉及特殊行业（金融、医疗、建工等）时，需提示用户注意行业监管合规要求 - **模式二（模板填空）原则**：最大程度尊重模板原有条款和结构，仅在用户有明确需求时新增或修改条款，每处改动须标注说明 - 若用户上传文件无法读取（加密、损坏，或经 OCR 后仍不可识别），立即告知用户，请其提供可读版本