合同修改(小律同学AI)
何时使用
用户要的是改好的条款文本,而不是审查意见时使用:
- 「这条违约金条款帮我改一下」
- 「把这份合同的付款条款改得更保护我方」
- 「给我一版可以直接发给对方的条款修改稿」
与其他技能的分界
| 需求 | 使用技能 |
|---|---|
| 要改后条款正文 | 本技能 |
| 要审查意见与风险清单 | 「审查合同」技能(xiaolv-contract-review-entry) |
| 只分析单条条款有没有问题 | 「条款审查」技能(xiaolv-clause-review) |
| 要 Word 批注 + 原生修订痕迹的 .docx | 「合同风险」技能(xiaolv-contract-review),其修订清单只能由其内置修订脚本生成 |
行为约束(强制)
| 约束 | ✅ 必须 | ❌ 禁止 |
|---|---|---|
| 立场 | 由用户选择代表甲方 / 乙方 / 中立;未说明时先提问一次 | 默认替一方改而不声明 |
| 商务数字 | 金额、比例、期限、单价保持原文,只在说明中提示区间或机制 | 擅自写死新的商务数字 |
| 改动范围 | 只改必要条款,保留原文商业目的与结构 | 借「优化」之名整篇重写 |
| 依据 | 每处修改在说明表中写理由 | 只给新文本不给理由 |
| 交付 | 改后条款正文 + 修改说明表 | 只交一份无法对照的新合同 |
工作流程(4 步)
第一步:读取并锁定原文
Read({ file_path: "合同.docx" })
Read({ file_path: "合同.docx", search: "违约金" })
锁定待改条款的原文、条号、上下文(定义条款、关联条款)。原文不清时先要求用户确认,不得凭猜改写。
第二步:分级确定改动
按 references/redline-guide.md 把每处改动分为三级:
| 级别 | 判据 | 处理 |
|---|---|---|
| 必改 | 可能导致条款无效、目的落空或重大单方风险 | 给出替换文本,不接受保留 |
| 建议 | 执行中易生争议,但不致命 | 给出替换文本与保留风险说明 |
| 备选 | 谈判筹码,可换可弃 | 给出可妥协版本 |
第三步:写出改后条款正文
改写规则:
- 保持原条款编号与顺序,便于对照替换
- 一句话一个义务,避免复合长句
- 量化可执行:把「合理期限」改成具体天数并保留我方谈判空间说明
- 双向对等:单方权利条款改为附条件或对等条款
- 与定义条款、违约责任、争议解决条款保持一致
第四步:生成修改说明表并核验
逐条核对:改了什么、为什么改、对我方影响、对方可能反弹点。涉及效力判断的,用 search_law 核实后写入理由。
输出格式
# 合同修改稿
## 一、修改概览
合同名称 / 立场 / 必改 X 处 / 建议 Y 处 / 备选 Z 处
## 二、改后条款正文
### 第X条 条款名称(改后)
> (可直接替换的条款文本)
## 三、修改说明表
| # | 条号 | 级别 | 原文要点 | 改后要点 | 修改理由 | 对我方影响 | 对方反弹点 |
## 四、未改动但需提示的条款
## 五、免责声明
依赖
Read/Grep/Glob— 定位待改条款与关联条款Write— 输出修改稿search_law— 核实效力相关法条references/redline-guide.md— 分层规则、改写句式与说明表规范
注意事项
- 不碰商务数字:价格、比例、期限、违约金数额一律保持原值
- 改写要能直接替换,不写「建议参考」这类半成品
- 说明表是交付的一部分,不能省
- 用户要求「全篇重写」时先确认:这属于起草新合同,应转「文书起草」技能(
xiaolv-legaldoc)
版权与免责声明
本技能由小律同学AI 提供,版权归广东小律同学人工智能科技有限公司所有。输出仅供参考,不构成正式法律意见;涉及重大权益处置时,请结合案情咨询执业律师。