GLM-Legal 读合同的边界，通常不在它能读多长，而在它给出的每个风险点能不能追溯。建议把模型定位成风险线索生成器：按段扫出可疑表述、给出理由、列出待确认问题；法条是否现行有效、合同有没有特别约定、这个风险点到底成不成立，留给人工核验。这样定位之后，模型的输出是可以验收的——有段落定位、有理由、有依据缺口标注；它不能验收的部分，正好由人工交接单兜住。如果反过来让模型直接给结论，你既没法判断它对不对，也没法在复核时快速定位到原文。

适用场景是内部合同初筛和条款梳理，不是出具法律意见。操作上先分段再逐段提问，要求模型输出风险点、理由、待确认事项三段式，并强制标注依据状态；人工按依据状态排复核顺序，有依据的先核时效，依据不足和无依据的直接列入待确认。验证方式是回查条号是否存在、是否现行有效、是否被合同特别约定覆盖。边界很明确：模型输出只作线索，不构成结论，不替代律师判断，也不覆盖它没读到的附件和往来函件。

把合同按主体、义务、违约责任、解除条件分段

整份合同一次性丢给模型，输出往往笼统，人工也没法定位风险点出在哪一条。建议先切段，切分依据是法律关系而不是页数或字数：主体与资格、权利义务、违约责任、解除条件、争议解决各成一段，跨段关联用字段标出来。这一步可以人工做，也可以先按条款编号正则切一遍再人工纠正。

seg_id,clause_type,source_range,legal_relation,depends_on
S01,主体与资格,第1条至第2条,交易双方的缔约主体资格,
S02,付款义务,第3条,买方的金钱给付义务,
S03,交付与验收义务,第4条,卖方的交付与验收配合义务,S02
S04,违约责任,第5条至第6条,违约救济关系,S02;S03
S05,解除条件,第7条,合同解除权的行使条件,S04
S06,争议解决,第8条,争议管辖与准据法,

clause_type 用固定枚举，别让模型自由命名，否则后面按类型筛风险点会很乱。depends_on 用来记录依赖关系：比如违约金上限要看付款义务和违约责任两段才能判断，标出来之后人工复核时就知道不能只看单段。这张分段表建议和合同原件一起存档，验证方式是逐条对照原文，确认没有漏段、没有把两个法律关系硬并成一段。合同附件、补充协议、往来确认函需要单独建段，不要混进正文段落。

让 GLM-Legal 按段输出风险点和待确认问题

逐段提问时，提示词里要把“提线索”和“下结论”分开。下面是一个通用骨架，模型名、合同类型、字段名都可以替换，放在调用模型时的请求体里执行。

角色：合同风险线索提取助手
输入：合同类型、单个合同段落原文、seg_id、依赖段落原文
任务：
1. 只提出风险线索，不做最终法律判断，不使用“必然无效”“肯定违约”这类定性表述；
2. 每条线索输出字段：risk_id、seg_id、风险描述、判断理由、待确认事项、把握程度（高/中/低）；
3. 条款表述不完整或依赖上下文时，写进待确认事项，不要自行补全；
4. 不写具体法条条号，法条由人工核验后再补入；
5. 没有发现风险就返回空数组，不要为凑数编造风险。
输出：JSON 数组，不要输出解释性文字。

判断理由这一栏是关键：它逼模型说清是根据哪句表述、哪个缺失要素提出线索，人工复核时可以快速判断理由站不站得住。待确认事项则用来接住模型自己不确定的地方，比如“验收标准未量化”“解除权行使期限未约定”。把握程度只作参考，不建议当成风险等级用，模型的自评和实际风险经常不一致。验证方式是同一段连续问两次，看风险点是否稳定出现；差异大的条目优先人工看。输出为 JSON 便于后续脚本汇总，如果模型返回多余文字，需要在调用侧做一次解析校验。

对每个风险点标注是否已有法条或判例支撑

模型很容易把常见表述说成风险，但说不清依据。建议拿到风险点后，再单独加一轮标注，把每条风险分成三类，别混在一起：

• 有依据：能对应到具体条文或司法解释条号，或者模型给出可检索的裁判观点方向，人工只需要核对时效和适用性。
• 依据不足：只给了原则性说法、条款名称或行业惯例，没有条号，也没有可追溯的出处，需要人工补依据。
• 无依据：只有结论没有理由，或者给的条号和内容明显对不上，直接降级为待确认事项，不作为风险点进入清单。

这一轮的作用不是让模型自己证明自己，而是把依据缺口摆出来。可以让模型按 risk_id 输出依据状态和它认为对应的条号，再由人工回查：条号是否存在、是否现行有效、是否适用于当前合同类型和准据法。验证方式建议抽样回查，重点看标为“有依据”的条目，因为这类最容易被人直接采信。如果模型给的条号查不到，把该条改判为无依据，并在交接单里写明原因，这个记录本身对下次提问有用。

人工核对法条时效和合同特别约定

模型通常不知道你手上的法条版本，也不清楚这份合同有没有排除默认规则。这一步必须人工做，建议用固定字段的核对单，一条风险点对应一行：

risk_id | 引用条文 | 施行日期（人工从官方渠道确认） | 是否修订/被替代 | 合同特别约定 | 比对结论
R003    | 待填     | 待填                          | 待填             | 第6条第2款约定违约金上限 | 约定优先于默认规则，风险点降级
R007    | 待填     | 待填                          | 待填             | 无                     | 需确认条款是否适用

施行日期和修订情况不要凭记忆填，也不要用模型给的日期，从官方法规库核对后再写入。比对时重点看三类特别约定：一是合同明确写“双方另有约定除外”的条款，二是违约金、责任上限、赔偿范围的自行约定，三是争议解决和准据法条款——后者会直接改变前方法条的适用范围。合同里没有特别约定，不等于默认规则一定适用，还要看合同性质和交易结构，这部分需要结合具体环境确认。

整理成可交给律师复核的风险清单

最后一步是把模型线索、依据状态、人工核对结果合成一张表，边界写清楚，律师拿到后不用再回头看模型原始输出。建议字段如下：

risk_id | seg_id | 风险点 | 依据状态 | 待确认问题 | 复核优先级
R003    | S04    | 违约金上限约定与损失范围不匹配 | 依据不足 | 上限是否覆盖间接损失 | 高
R007    | S05    | 解除权行使期限未约定 | 有依据（待核时效） | 是否适用默认期限 | 高
R011    | S03    | 验收标准表述模糊 | 无依据 | 行业惯例是否可作为补充 | 中

优先级按影响面排，不建议按模型给的把握程度排：影响付款、责任上限、解除权、争议解决的列高；履行期限、通知方式、验收流程列中；表述和格式问题列低。每行都要保留 seg_id，方便律师直接翻到原文对应条款。清单末尾附一段说明，写明哪些内容模型没有覆盖，例如附件、补充协议、双方往来邮件，避免复核时误以为清单是完整的。整个流程跑完后，建议把这条提示词、分段表和核对单一起归档，下次同类合同可以直接复用，也能对照出模型这次漏了什么。