请想象你是一位家族总厨。每逢节庆，要操办一桌二十人的家宴，你手里捏着一张泛黄的“家宴总谱”——迎宾四碟、主菜八道、羹汤两盅、甜品一款，骨架年年不变。可每次宴请都不轻松：宾客有忌口，食材有差异，主菜与点心偶尔还会相克。直到你请来一位聪明的帮厨：你定骨架，他备菜、查相克、按宾客口味配菜，还在菜谱上留下批注。这位帮厨，就是今天的 AI 合同起草助手。合同，是一桌需要用心操办的“宴席”；模板，是那张代代相传的总谱；每一段正文，是一道菜的完整做法；而查相克、配口味、做批注，对应着 AI 在起草过程中默默完成的关键动作。这篇文章将带你从零看懂，AI 如何把“定骨架、备菜、查相克、配口味、记批注”这套家宴功夫，迁移到法律文书这件大事上。它不取代法务，而是让法务从埋头抄写的苦活中抬起头来，把精力留给真正需要人来做判断的地方。

岗位关联

掌握 AI 合同起草的模板工程、条款生成、冲突检测、商务推荐与版本管理全链路，你就能在法务科技产品中设计出合规、高效、可落地的智能起草方案，为法律行业的数字化转型提供 AI 从业者的核心价值。

目录
  1. 可视化演示
  2. 合同模板设计
  3. 条款智能生成
  4. 冲突检测机制
  5. 商务条款推荐
  6. 版本管理协作
  7. 部署效果评估
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示模板填充与LLM生成双轨起草、条款冲突检测及风险平衡评估，支持敏感度调节。

本节配有交互动效（进入视口后自动加载，约 3KB）。

模板填充与LLM生成双轨起草 蓝色模板定义合同骨架与必填条款 绿色LLM生成具体条款表述与过渡语句 Draft = Template(skeleton) + LLM(clause text) 双轨方案兼顾结构合规与表述灵活性

合同模板设计

家宴总谱的骨架——四碟八菜两盅一品，是多年沉淀的“硬规矩”。谁也不会为一场普通家宴从零发明一种全新宴席结构，而是在既定架子里调整菜色。技术世界里的合同模板，就是这台宴席骨架。它把商业交易的通用环节固化成结构，比如当事人信息、定义、标的、价款、交付、违约、争议解决。模板设计的核心是“该有的环节一个不少、可变的环节留出空位”。

模板设计要解决三件事。一是必备条款枚举，参考《民法典》合同编和行业惯例，整理出该类合同“缺了会出事”的条款清单；二是占位符体系标准化，用 {{甲方名称}}、{{交付日期}} 这类标记把业务变量和固定文本分离；三是复用机制，把高频段落沉淀为“模板零件”。衡量模板好坏的直接指标是完整度——相当于宴席上桌后，凉菜热菜甜点是否齐活。

骨架齐了，家宴就稳了一半；模板库把“硬规矩”沉淀成可复用的总谱，AI 合同的每一次起草，都站在前人的肩膀上开席。法务不需要每次从空白文档开始，而是像翻开总谱一样，从一张结构健全、字段清晰的模板出发。

Completeness⁡=CcoveredCrequired×100%\operatorname{Completeness} = \frac{C_{\text{covered}}}{C_{\text{required}}} \times 100\%
通俗说明：完整度就像清点宴席菜品：已经端上桌的必备菜 ÷ 原计划应有的必备菜。低于 80% 就得赶紧补菜（补条款）。
  1. 分子 C_covered统计当前合同实际包含的必备条款数量。比如标准要求六项，模板只覆盖四项，则 C_covered = 4。
    Ccovered=4C_{\text{covered}} = 4
  2. 分母 C_required由行业规范或机构沉淀而来的必备条款总数，是衡量结构的“标准刻度”。此处 C_required = 6。
    Crequired=6C_{\text{required}} = 6
  3. 相乘取百分数两者相除再乘 100%，得到完整度百分比；低于阈值时触发补全提醒，防止结构性漏项。
    46×100%≈66.7%\frac{4}{6} \times 100\% \approx 66.7\%

条款智能生成

帮厨备菜时，会从记忆库里调出每道菜的“标准做法”，再根据今天手里的食材——甲方要的交付节奏、乙方能接受的付款方式——当场改编。AI 生成条款，正是这个“标准做法改编”的过程。技术实现上，把合同类型、当事人身份、交易要素作为输入，交给经过合同语料训练的大语言模型（LLM），让它输出条款初稿。提示词里明确“你是资深法务，请起草……”，相当于告诉帮厨“今天按粤菜清淡风格来做”。

生成只是第一步，质量评价才是关键。业界常用三维度加权评分：合法性 L（是否引用有效法律依据）、规范性 S（表述是否严谨无歧义）、完整性 P（必备要素是否齐全）。加权求和后得到一个 0-100 的质量分，低于阈值的条款自动退回重写。同时，AI 生成内容必须在界面上标注“由 AI 生成，需人工复核”，把责任边界画清楚。

帮厨备好的菜再漂亮，总厨也得亲口尝一尝。AI 生成的条款只是“半成品初稿”，法务的确认环节是最后一道试味——千万别省。大模型写得再流利，它并不了解这笔交易背后的人情与风险，只有法务才握有最终的下勺权。

Q=w1L+w2S+w3PQ = w_1 L + w_2 S + w_3 P
通俗说明：条款质量 Q 是三位评委（合法性、规范性、完整性）的加权打分。权重 w 表示谁的话语权更大——比如合规要求高时，合法性权重自然抬升。
  1. 维度分 L / S / P三个子项都是 0-100 分，例如 L=85 表示合法性审查较满意、S=90 表示表述规范、P=80 表示要素有缺漏。
    L=85,S=90,P=80L = 85, \quad S = 90, \quad P = 80
  2. 权重 w_i三个权重和为 1，代表业务侧对各维度的重视程度，如 w1=0.5、w2=0.3、w3=0.2。
    w1+w2+w3=1w_1 + w_2 + w_3 = 1
  3. 加权求和各维度分乘各自权重后相加，得到该条款总质量分；90 分以上可进入人工复核队列，低于阈值则打回重写。
    Q=0.5×85+0.3×90+0.2×80=85.5Q = 0.5 \times 85 + 0.3 \times 90 + 0.2 \times 80 = 85.5

冲突检测机制

家宴上，最怕食材相克：海鲜配大量维C可能让人闹肚子，菠菜豆腐同食影响钙吸收。老练的帮厨手里有一张“相克表”，上菜前把每对食材快速过一遍。合同条款也会“相克”：A 条款写“货到验收后一次性付款”，B 条款却规定“分三期支付”，这就是典型的逻辑冲突。AI 冲突检测引擎把合同里的条款两两配对，像核对相克表一样扫描矛盾。

检测手段分两层。第一层是规则引擎：维护一张显式冲突规则表，例如“分期付款 ↔ 一次性付款”“无限责任 ↔ 有限责任上限”，命中规则即报警。第二层是语义分析：把条款文本向量化，用余弦相似度衡量语义相近度，捕捉“不同词但同矛盾”的条款。冲突结果按严重程度分三级：致命（必须修改）、警告（建议调整）、提示（可选优化）。

有了“相克表”和“尝菜经验”双保险，家宴才不容易翻车；规则加语义双通道，冲突检测既快又稳。规则引擎解决“已知的相克”，语义分析兜住“变着说法打架”的隐蔽矛盾，二者互补，才能把风险拦在签约之前。

sim⁡(A,B)=A⋅B∣A∣ ∣B∣\operatorname{sim}(A,B) = \frac{\mathbf{A} \cdot \mathbf{B}}{|\mathbf{A}| \, |\mathbf{B}|}
通俗说明：把条款 A、B 各变成一长串数字（向量），相似度就是两串数字夹角的余弦值。接近 1 说明语义相近，值得重点复查；接近 0 说明基本无关。
  1. 向量 A、B条款文本经过词向量或句向量模型映射成固定长度的数值序列，每个位置是一个语义维度的取值。
    A=[0.2,0.7,0.1],B=[0.1,0.6,0.2]\mathbf{A} = [0.2, 0.7, 0.1], \quad \mathbf{B} = [0.1, 0.6, 0.2]
  2. 点积两个向量逐位相乘后求和，反映它们在各维度上的“对齐程度”。
    A⋅B=∑kAkBk=0.2×0.1+0.7×0.6+0.1×0.2=0.46\mathbf{A} \cdot \mathbf{B} = \sum_k A_k B_k = 0.2 \times 0.1 + 0.7 \times 0.6 + 0.1 \times 0.2 = 0.46
  3. 模长向量自己与自己做内积再开平方，表示向量的“长度”。
    ∣A∣=0.22+0.72+0.12≈0.735|\mathbf{A}| = \sqrt{0.2^2 + 0.7^2 + 0.1^2} \approx 0.735
  4. 归一化比值点积除以两个模长之积，得到 [-1,1] 的相似度；超过阈值（如 0.8）即进入人工复查清单。
    sim⁡(A,B)=0.460.735×0.633≈0.99\operatorname{sim}(A,B) = \frac{0.46}{0.735 \times 0.633} \approx 0.99

商务条款推荐

帮厨记得老主顾的口味档案：张总清淡、李总无辣不欢，今天是家常便饭还是商务宴请，决定了这道菜是甜口还是咸口。合同里的“商务条款”——付款周期、违约金比例、质保期、知识产权归属——就是这桌菜的“火候与口味”。AI 从历史成交合同库中提炼规律，结合当前交易场景给出一套适合的商务参数。

推荐流程输入四类特征：交易类型（采购、销售、保密、合作）、双方市场地位（买方强势/卖方强势）、行业惯例、历史成交价。输出端为每个候选方案算加权总分：每个商务参数在 0-10 分区间内打分，再乘以该参数在当下场景的权重，求和得到方案分。例如卖方主导市场，违约金的权重被调高，推荐“每日 0.1%”的惩罚性条款；买方主导市场则推荐更温和的 "0.05%"。

会看人下菜的宴席才受欢迎。AI“看场景下条款”，让每一份合同的商务部分都不温不火、恰到好处，双方都舒服地成交。而这一切的底气，来自历史成交数据——就像帮厨多年攒下的口味档案，数据越丰富，推荐越懂行。

Score=∑i=1nwisi\text{Score} = \sum_{i=1}^{n} w_i s_i
通俗说明：每个菜品的“好评度”s_i 乘上它在这桌宴席上的“重要度”w_i，全部累加，得到整桌菜的配合得分。得分最高的方案优先推荐。
  1. 参数得分 s_i第 i 个商务参数（如付款周期、违约金比例）的打分，0-10 分，越高表示该取值越贴合当前场景。
    s1=8,s2=6,s3=9s_1 = 8, \quad s_2 = 6, \quad s_3 = 9
  2. 权重 w_i该参数在当前交易场景中的重要程度，所有权重相加等于 1。
    wi∈[0,1],∑i=1nwi=1w_i \in [0,1], \quad \sum_{i=1}^{n} w_i = 1
  3. 加权求和累加每个参数的加权得分，得到候选方案总分，多方案对比后取最高者。
    Score=0.4×8+0.35×6+0.25×9=7.55\text{Score} = 0.4 \times 8 + 0.35 \times 6 + 0.25 \times 9 = 7.55

版本管理协作

老菜谱的页边写满铅笔批注：“2022 年糖减半”“2023 年换低筋面粉”。可如果没有署名和时间，谁也说不清是哪年谁改的。聪明的帮厨给每一次改动盖上了带签名的时间戳。合同起草从来不是一锤定音：法务改一版，业务提意见，对方律师再改一版……AI 起草系统必须把“过程”管起来。版本管理机制记录每次修改的快照、差异、修改人和时间，审阅流程通过状态机把协作串起来：待审 → 会签 → 定稿 → 用印。

三个关键机制构成了版本管理的骨架。一是快照：保存某一时刻的合同全文，像菜谱某年某月的完整抄本，随时可回滚。二是变更追踪：用编辑距离的归一化值量化两个版本的差异大小，差异超过阈值强制发起二次评审。三是权限控制：不同角色只能看到自己负责的章节，避免无关人员误改。

有了带签名的批注和时间戳，家宴菜谱才能代代改良、有据可查；合同版本链路清晰，出了争议也能追根溯源，谁的改动、因何而起、何时落笔，一目了然。版本管理不是“多存几份文件”，而是把协作过程变成可信的证据链。

d(A,B)=edit⁡(A,B)max⁡(∣A∣,∣B∣)d(A,B) = \frac{\operatorname{edit}(A,B)}{\max(|A|, |B|)}
通俗说明：两个版本差多少？把 A 改成 B 最少需要的增删改次数，除以较长文本的长度，得到一个 0~1 之间的“差异度”。越接近 1，说明改得越天翻地覆。
  1. 编辑距离 edit(A,B)把文本 A 变换到文本 B 所需的最小单字符编辑（插入、删除、替换）次数。比如“一次付清”到“分三期付清”，需要插入 3 个字、改 1 字，共 4 次编辑。
    edit⁡(A,B)=4\operatorname{edit}(A,B) = 4
  2. 分母 max(|A|,|B|)取两个文本长度的较大值，作用是归一化，让差异度落在 0 到 1 之间。
    max⁡(∣A∣,∣B∣)=8\max(|A|, |B|) = 8
  3. 相除得到差异度编辑次数除以最大长度，得到 0~1 的差异度；业务上可设阈值，如 d > 0.3 视为“重大修订”，需重新走会签。
    d(A,B)=48=0.5d(A,B) = \frac{4}{8} = 0.5

部署效果评估

一场家宴办完，好的总厨不会马上躺下，而会复盘：哪道菜光盘最快？哪位宾客的忌口没照顾好？把答案记回总谱，下一场才能更漂亮。AI 合同起草系统部署上线只是开始。要判断它是否“好用”，得靠数据说话。评估通常覆盖四大类指标：效率（起草时间缩短率）、质量（条款完整度提升、冲突数下降）、合规（法务抽检通过率）、稳定性（调用成功率与失败率）。

在模型层面，常用精确率（Precision）和召回率（Recall）衡量风险识别的“准”和“全”。但单独看任何一个都可能骗人——召回率做到 95% 可能是靠把所有条款都标成风险实现的。于是用 F1 分数（两者的调和平均）作为综合指标：调和平均对“偏科”惩罚明显，逼着模型既要报得准、也要找得全。上线后还要定期抽检、更新规则库、监控数据漂移，形成“生成-检测-反馈-迭代”的闭环。

一场复盘是一场更出色的宴席的开始。AI 合同助手也应当持续“办宴席、做复盘”，在真实业务厮杀中反复打磨，才能从“能演示”走向“能顶用”。评估不是终点，而是下一轮迭代的起点。

F1=2×P×RP+RF1 = \frac{2 \times P \times R}{P + R}
通俗说明：F1 是精确率 P 和召回率 R 的调和平均。就像办宴席，既关心“端上来的菜都好吃”（准），又关心“好菜没被漏掉”（全），两者都重要，哪个瘸腿都不行。
  1. 精确率 PAI 标记为风险条款中真正有风险的比例，衡量“报出来的别报错”。
    P=TPTP+FPP = \frac{TP}{TP + FP}
  2. 召回率 R真正有风险的条款中被 AI 正确找出来的比例，衡量“该找的别漏掉”。
    R=TPTP+FNR = \frac{TP}{TP + FN}
  3. 调和平均将 P、R 代入公式得到 F1，范围 0-1。P 与 R 差距越大，F1 被拉得越低，以此引导模型均衡优化。
    F1=2×0.9×0.70.9+0.7≈0.787F1 = \frac{2 \times 0.9 \times 0.7}{0.9 + 0.7} \approx 0.787

AI 应用场景

企业法务部的合同智能起草台

阶段：智能起草与风险预检

解决的问题：传统起草靠法务逐字敲模板，一份采购合同耗时两三个工作日，且漏条款、前后矛盾频发。AI 方案将高频合同模板化，用大模型按要素生成初稿，再经冲突检测与商务推荐修正，把起草时间压缩到几十分钟，法务只需做最终判断。

具体案例：某制造企业法务部每年对外签署 3000 余份合同。部署 AI 起草台后，销售、采购、保密协议三类高频合同接入系统：业务人员填要素、AI 出初稿、系统自动扫冲突、法务在线审阅定稿。合同平均起草时间由 8 小时降至 40 分钟，漏项率由 18% 降至 3%，企业当年法务人力成本下降约 25%。

律师事务所的合同审查辅助服务

阶段：风险审查与语义分析

解决的问题：律师面对几十页合同时逐条比对耗时且易漏。AI 通过规则引擎与语义向量相似度先行扫描，输出“高风险条款清单”，让律师从低价值核对中解放，集中精力做高价值判断。

具体案例：某律所处理并购尽调时，把 AI 冲突检测接入工作流。系统将送审合同中“无限责任”与“有限责任上限”等语义矛盾条款（向量相似度超过 0.85）标红并生成修改建议；实习律师据此快速修订，合伙人只复核核心争议点。合同审阅效率提升约 3 倍，复核通过率稳定在 95%。

电商开放平台的入驻协议自助生成

阶段：大规模个性化生成

解决的问题：电商平台商家类型多样，统一协议一刀切不适用，人工逐份定制又成本过高。AI 根据类目、规模、保证金档位自动生成带个性化商务条款的协议，兼顾平台风控与商家体验。

具体案例：某电商平台基于“商务条款推荐”能力重构入驻流程：小微商家自动匹配基础保证金与简易结算周期，头部商家匹配账期缩短与服务承诺条款。上线后商家协议签署率提高 12%，因条款歧义引发的入驻纠纷下降 30%。

Python 演示

python95 行
class ContractDraftAssistant:    def __init__(self, template):        self.template = template          # 模板：必备条款与可选条款清单        self.clauses = {}                 # 已填充条款字典        self.conflicts = []               # 冲突记录列表        self.versions = []                # 版本历史列表        self.vsn_count = 0                # 版本号计数器        self.recommend_map = {}           # 推荐结果缓存     def fill_clause(self, key, text):        """填充条款：只允许填入模板中声明的条款，防止越界。"""        if key not in self.template['required_clauses'] + self.template['optional_clauses']:            return False        self.clauses[key] = text        return True     def completeness(self):        """计算合同模板完整度，对应正文 Completeness 公式。"""        req = self.template['required_clauses']        covered = [k for k in req if k in self.clauses]        return len(covered) / len(req) * 100     def detect_conflicts(self):        """冲突检测：用规则表扫描条款两两之间的显性矛盾。"""        rules = [            ('分期付款', '一次性付款'),            ('先验收后付款', '先付款后验收'),            ('违约金上限', '违约金无上限'),        ]        self.conflicts = []        for a, b in rules:            has_a = any(a in v for v in self.clauses.values())            has_b = any(b in v for v in self.clauses.values())            if has_a and has_b:                self.conflicts.append((a, b, 'high'))        return self.conflicts     def recommend_clauses(self, scenario):        """商务条款推荐：按市场地位选择不同的条款参数。"""        rec = {}        if scenario == 'seller_market':            rec['付款方式'] = '预付 50%，交付后付 50%'            rec['违约金比例'] = '每日 0.1%'        elif scenario == 'buyer_market':            rec['付款方式'] = '验收合格后一次性付款'            rec['违约金比例'] = '每日 0.05%'        else:            rec['付款方式'] = '按里程碑分期付款'            rec['违约金比例'] = '每日 0.08%'        self.recommend_map = rec        return rec     def save_version(self, note=''):        """保存版本快照：复制当前条款，生成不可变记录。"""        self.vsn_count += 1        snapshot = (self.vsn_count, dict(self.clauses), note)        self.versions.append(snapshot)        return snapshot     def summary(self):        """汇总评估指标，对应部署评估中的质量维度。"""        return {            'completeness': self.completeness(),            'conflict_count': len(self.conflicts),            'version_count': len(self.versions),        }  def main():    template = {        'required_clauses': ['当事人信息', '标的物', '交付方式', '付款方式', '违约责任', '争议解决'],        'optional_clauses': ['保密条款', '知识产权', '不可抗力'],    }    assistant = ContractDraftAssistant(template)    assistant.fill_clause('当事人信息', '甲方：某某科技有限公司；乙方：某某实业有限公司')    assistant.fill_clause('标的物', '货物：智能传感器 500 套')    assistant.fill_clause('交付方式', '分两批交付，每季度交付 250 套')    assistant.fill_clause('付款方式', '货到验收后一次性付款')    assistant.fill_clause('保密条款', '双方约定分期付款相关信息均需保密')    assistant.save_version('初稿：按买方市场惯例起草')     conflicts = assistant.detect_conflicts()    rec = assistant.recommend_clauses('buyer_market')    print('完整度: %.1f%%' % assistant.completeness())    print('冲突数量:', len(conflicts))    for a, b, level in conflicts:        print('  - 冲突:', a, '<->', b, '(风险:', level, ')')    print('推荐条款:', rec)    assistant.fill_clause('付款方式', rec['付款方式'])    assistant.save_version('修正：采纳智能推荐条款')    print('版本数:', len(assistant.versions))  if __name__ == '__main__':    main()
目的：用一个可运行的 Python 类演示 AI 合同起草闭环——模板填充、完整度计算、规则冲突检测、商务条款推荐和版本快照保存，完全对应正文六个环节。
  1. assistant = ContractDraftAssistant(template)创建起草助手实例，相当于总厨就位，把“总谱”（模板）装进记忆。
  2. if key not in self.template['required_clauses'] + self.template['optional_clauses']:白名单校验，只允许填模板中声明的条款，防止乱填。
  3. return len(covered) / len(req) * 100完整度计算的实现，对应正文里的 Completeness 公式。
  4. for a, b in rules:遍历冲突规则表，像帮厨逐对检查食材相克。
  5. self.conflicts.append((a, b, 'high'))同时命中两个对立关键词即记为高风险冲突。
  6. if scenario == 'seller_market':商务推荐的分支逻辑：根据市场地位给出不同条款参数。
  7. self.recommend_map = rec返回推荐结果并保存在实例属性中，供后续环节读取。
  8. self.vsn_count += 1生成新版本号，作为快照的唯一标识。
  9. snapshot = (self.vsn_count, dict(self.clauses), note)用 dict 拷贝当前条款，形成不可变快照，避免后续修改污染历史。

常见误区

误区“AI 能自动生成完整合同，法务只需要等着签字盖章，所以完全可以裁掉法务岗。”

正解AI 更像“帮厨”，能备菜、查相克、按口味推荐，却无法为整桌宴席负责。合同的风险判断最终需要法务对具体商业背景负责，AI 提供初稿与风险提示，人工确认是必备环节。大模型生成的是“看起来合理”的文本，而不是“经得起博弈”的权利义务安排。

为何常见：大模型输出的流畅文本给人“全知全能”的错觉，忽略了法律文本背后是利益的反复博弈，而博弈需要人对商业意图的判断。

误区“一份合同把网上能找的条款都塞进去，覆盖得越全就越保险。”

正解条款过多会引入自相矛盾和冗余：比如同时出现“分期付款”和“一次付清”，反而增加纠纷点。好的模板像家宴总谱——环节精炼、搭配得当，必要条款齐整优先于数量堆砌。真正专业的模板是“少而准”，每个条款都有存在的理由。

为何常见：把“防御性心理”误认为“完备性”，没意识到条款之间相互制约，数量堆砌反而制造新的冲突。

误区“只要在模板里写死'严禁同时出现 X 和 Y'，就能挡住所有条款冲突。”

正解现实中冲突往往是语义层面的：“全部预付”和“货到付 30% 尾款”虽没有相同关键词，但在逻辑上矛盾。规则引擎只能防已知组合，还要靠向量相似度对语义相近的条款做二次扫描。关键词规则是“相克表”，语义分析才是“尝菜经验”，两者缺一不可。

为何常见：关键词规则直观可解释，让人误以为已经覆盖了全部风险；但法律表达千变万化，规则永远追不上语义。

误区“每次修改另存为'合同 v2 最终版 v3 真最终版'就行，版本管理只是文件管理。”

正解科学的版本管理要有快照、diff、责任人、时间戳和审阅流程状态。它能回答“谁在什么时间改了什么、为什么改”，遇到纠纷时是整个谈判过程的可信证据链。像菜谱上的批注要署名和时间，合同版本也要能追溯到每个决策节点。

为何常见：日常用 Word/共享盘的习惯，让人觉得版本管理只是复制文件，忽视了协作中的权责追溯。

误区“上线时 F1 很高，说明系统已经成熟，不需要再维护。”

正解法律环境、监管政策、客户结构都会变，模板和推荐策略需要随场景更新。评估效果是持续过程：定期抽检、监控调用成功率、更新规则库，像家宴复盘一样不断改良菜谱。F1 高只代表此刻的模型对此刻的数据表现好，不代表明天依然成立。

为何常见：把机器学习模型当成静态软件，忽略了法律知识本身在演进，也忽略了数据漂移——今天的成交样本，未必能预测明天的交易结构。

面试题

Q1. 合同模板中“占位符”的主要作用是什么？

单选题 · easy

  • A.标记待填充的要素位置← 正确答案
  • B.直接替换全部法律文本
  • C.用于生成合同唯一编号
  • D.创建一份空白合同文档

答案：A。占位符好比菜谱里的“口味待定”留白，不是用来替换全文或编号，而是标出下一步要由业务信息填充的位置，让同一模板能灵活适配不同当事人。

Q2. 冲突检测中最常用的文本相似度计算方法是？

单选题 · easy

  • A.编辑距离归一化
  • B.余弦相似度计算← 正确答案
  • C.关键词频率统计
  • D.长短时记忆网络

答案：B。正文冲突检测用的是向量化的余弦相似度，衡量的是两条条款在语义空间里的夹角。编辑距离更常用于版本差异度量，词频统计太粗糙，LSTM 是网络结构而非相似度算法。

Q3. 商务条款推荐的输入特征通常不包括下列哪项？

单选题 · hard

  • A.历史成交价格数据
  • B.谈判双方市场地位
  • C.合同模板字体样式← 正确答案
  • D.交易类型与行业惯例

答案：C。推荐商务条款像看人下菜：历史成交、双方地位、交易类型都是决定“口味”的关键输入；字体样式只影响阅读观感，和商业权益分配无关，属于明显干扰项。

Q4. 下列哪些属于合同中的必备条款？

多选题 · easy

  • A.当事人基本信息← 正确答案
  • B.争议解决方式← 正确答案
  • C.合同封面设计
  • D.违约责任约定← 正确答案

答案：ABD。必备条款是合同骨架：当事人、标的、价款、履行、违约、争议解决。封面设计属于排版美化，不是法律意义上的条款，因此不选。

Q5. 版本管理中“快照”的含义是？

单选题 · mid

  • A.某一时刻的合同全文拷贝← 正确答案
  • B.每次修改的差异片段
  • C.数据库表的系统备份
  • D.加密后的合同文书

答案：A。快照是某一时刻合同的完整状态，像菜谱在某年春节的完整抄本，随时可以回滚；差异片段是 diff，备份与加密是安全手段，都不是快照的本质。

Q6. 两个条款向量余弦相似度为 0，说明？

单选题 · mid

  • A.两个向量方向完全相同
  • B.两个向量完全垂直正交← 正确答案
  • C.两个向量长度完全相等
  • D.两个向量方向完全相反

答案：B。余弦值=1 表示方向相同，=-1 表示方向相反，=0 表示正交，即语义上几乎不相关。像两个完全搭不上边的食材，谈不上相克，也就不需要重点复查。

Q7. 部署 AI 合同起草系统后，哪些指标适合做效果评估？

多选题 · mid

  • A.平均起草时间缩短率← 正确答案
  • B.条款完整度提升比例← 正确答案
  • C.法务抽检通过率← 正确答案
  • D.服务器风扇噪声分贝

答案：ABC。评估看效率（时间缩短）、质量（完整度提升）、合规（抽检通过率）。服务器噪声属于运维物理环境，与合同生成质量没有直接关系，不适合作为效果指标。

Q8. 为什么 AI 生成条款后仍需法务人工确认？

单选题 · mid

  • A.模型输出并非百分百可靠← 正确答案
  • B.法务岗位需要工作量
  • C.合同要求纸质归档
  • D.客户要求线下面谈

答案：A。像帮厨做的菜总厨要把关一样，大模型可能引用过期法条或生成有歧义的表述，人工确认是风险兜底，而不是为了制造岗位。法律工作最终要有人对合同后果负责。

Q9. F1 分数在数学上是精确率 P 和召回率 R 的什么？

单选题 · hard

  • A.两者的算术平均值
  • B.两者的调和平均值← 正确答案
  • C.两者的加权求和值
  • D.两者的几何平均值

答案：B。F1 = 2PR/(P+R) 是调和平均。调和平均对“偏科”惩罚更重，如果 P 和 R 差距大，F1 会明显低于算术平均，从而引导模型追求精确与召回之间的均衡。

Q10. 条款冲突检测引擎通常可组合使用哪些技术手段？

多选题 · extreme

  • A.规则引擎维护显式冲突规则← 正确答案
  • B.向量模型计算语义相似度← 正确答案
  • C.人工逐条阅读条款文本
  • D.仅依赖词频统计分类文本

答案：AB。规则引擎覆盖已知的“相克组合”，向量相似度覆盖语义层面的隐性冲突，二者组合是主流方案。人工逐条阅读是复核流程而非引擎手段；仅靠词频统计无法理解逻辑矛盾，故 D 不选。