用 GLM-Legal 梳理合同条款时，模型最不可靠的地方通常不在于它读不懂合同，而在于它给出法条时的“顺手程度”：名称像、编号像、年份也像，但版本可能已经修订，甚至引用的根本不是现行文件。比较稳的做法，是先把模型输出降级为“候选引用”，再让每一条候选都过一遍编号、生效日期和修订记录的核对，最后只把核对通过的条目交给人工复核。下面按“拆条款—收候选—核版本—打标记—出清单”这条路走一遍，所有步骤都能通过输入、输出和日志验证，不依赖模型自述的权威性。

合同里凡是涉及效力、解除、违约、赔偿、管辖的条款，都应当单独拆出来核对法律依据。GLM-Legal 适合生成候选法条清单，不适合直接给结论；模型给出的名称、编号、版本必须逐条到权威法条库比对生效日期和修订记录。核对不通过或模型未给依据的条款，全部进入待人工确认清单，不能因为模型语气肯定就默认可用。

在合同文本里拆出需要法条支撑的条款

不要一上来就把整份合同丢给模型做“法律分析”，那样输出会混在一起，核对时很难追溯。建议先做一次机械拆分：把合同按条款编号切开，每条保留编号、原文和一句“这条要解决什么法律问题”。这一步可以用模型做，但要求它只做归类，不给法条。通常会拆出几类必须核对依据的条款：合同效力与成立条件、解除与终止、违约责任与赔偿范围、争议解决与管辖、保密与知识产权归属、不可抗力与情势变更。

拆完之后先形成一张中间表。条款编号和原文必须原样保留，法律问题一栏用短句写，方便后面把候选法条挂上来。像“第 8.2 条 违约金按合同总价的 30% 计”这类条款，法律问题就写“违约金比例是否受调整规则约束”，不要写成笼统的“违约责任”。

条款拆分输入样例（可替换为真实合同片段）：

请只做条款归类，不引用任何法条。
对下面每个条款，输出：
- clause_id：条款编号
- clause_text：条款原文（逐字保留，不改写）
- legal_question：这条需要哪一类法律规则支撑（一句话）
- need_check：high / medium / low

合同片段：
第 7.1 条 ……
第 8.2 条 ……

判断标准很直接：只要条款的执行结果会因法律规则不同而变化，就标 high；只是表述规范问题，标 low。拆分结果建议落表保存，后续每一步都在同一张表上追加列，避免来回复制导致条款原文被改动。

让 GLM-Legal 逐条给出可能适用的法条与版本

第二步把模型的角色限定住：逐条给“候选法条”，并且必须显式写出它声称的名称、编号和版本。关键是提示词里要说清楚“只输出候选、不判断是否适用、不确定就写不确定”，否则模型很容易用一句话把结论下死。输出结果单独存一列，永远不要覆盖条款原文和法律问题列。

候选法条提取提示词（按条款逐条调用，可替换字段名）：

针对下面这一条合同条款，列出可能适用的法律依据候选。
要求：
1. 只输出候选，不评价最终是否适用，不给结论性建议。
2. 每条候选给出：law_name（名称）、article_no（条号，精确到款/项）、
   claimed_version（你声称的版本或修订年份）、reason（一句话说明关联点）、
   confidence（high / medium / low / unknown）。
3. 如果你不确定条号或版本，confidence 填 unknown，不要凭印象补全。
4. 不要输出没有具体条号的笼统引用。

clause_id: 8.2
clause_text: ……
legal_question: ……

拿到输出后先做一次格式校验：条目里是否同时具备名称、条号和版本三要素。缺任何一项都不能进入下一步核对，直接归入后面要讲的“依据不完整”。同时要把模型的原始返回写进日志，保留调用时间、提示词版本和模型标识，后面出现争议时可以回看是提示词问题还是模型问题。confidence 这一列只作参考，不作为采纳依据；模型标 high 的条目照样要核版本。

到权威法条库核对编号、生效日期和修订记录

核验环节不依赖模型。做法是拿着候选条目，到权威法条库或官方公布渠道逐条查三件事：条号是否存在、当前有效版本的生效日期、以及有没有修订或废止记录。核对来源类型建议在表里单独记一列，便于复核时区分“官方公布渠道”和“商业法规数据库”等不同来源，来源类型不同，复核时的可信度判断也不同。

比对结果按三种情况落表：条号一致且条款内容对得上，标“编号匹配”；条号存在但内容明显不对应，标“编号存疑”；条号查不到，标“未找到”。生效日期同样单独比对：模型声称的版本与当前有效版本一致，标“版本一致”；模型给的是旧版本，标“版本落后”；模型没给版本，标“版本缺失”。

核验记录表字段建议：

clause_id | law_name | article_no | claimed_version
verify_source_type   # 官方公布渠道 / 法规数据库 / 其他
article_exists       # 匹配 / 存疑 / 未找到
effective_date       # 当前有效版本的生效日期
effective_match      # 一致 / 落后 / 缺失
revision_note        # 是否存在修订、废止或替代记录
verify_time          # 核对时间
verifier             # 核对人

这一步的边界要说清楚：核查只能证明“这条引用真实存在且版本对得上”，不能证明“这条法律依据适用于本合同争议”。适用性判断仍然要由人来完成。另外，如果同一法条在多个条款下被引用，建议合并核对一次再回填，避免重复劳动和结论不一致。

标记模型未给出依据或依据不完整的条款

核验之后，把条款重新分成可继续推进的和需要补依据的两堆。标记建议固定为三类，方便统计和交接：缺引用、引用模糊、引用过时。缺引用指模型对某条合同条款完全没有给候选法条；引用模糊指只给了法律名称没有条号，或者条号写到“相关条款”这种程度；引用过时指条号存在但对应的是已被修订或替代的旧版本。

• 缺引用：常见于条款本身是商业安排而非法律规则问题，也可能是模型判断不足。处理方式是人工判断该条款是否真的需要法条支撑，不需要就在清单里注明“无需法条依据”。
• 引用模糊：要求补全到条、款、项，补不出来的直接转人工，不要让模型二次猜。
• 引用过时：记录旧版本与新版本的差异点，交由人工判断按现行版本重新评估条款表述。

三类标记要写进同一张表，而不是散落在对话记录里。标记完成后可以做一个简单核对：高优先级条款里如果出现“缺引用”，必须有人工处理意见，不能留空进入下一环节。

整理可复核的条款审查清单

最终交付的不是一段分析文字，而是一张能让人逐行复核的清单。每一行对应一个合同条款，把条款原文、候选法条、核验结果和复核意见放在一起，复核人不需要再翻聊天记录就能判断这条能不能用。复核意见栏建议留空，由复核人填写“采纳、替换、删除、待补依据”等结论。

条款审查清单（示例结构，内容按实际填写）：

clause_id | clause_text        | legal_question | candidate_law | article_no
          | claimed_version    | article_exists | effective_match | revision_note
          | mark(缺引用/引用模糊/引用过时/可复核) | reviewer_comment

复核栏填写约定：
- 采纳：编号与版本均核对通过
- 替换：候选法条不适用，需换条
- 待补依据：缺引用或引用模糊，暂不进入结论
- 删除：该条款无需法条支撑

交付前做一次完整性检查：每条高优先级条款是否都有核验结果，每个“版本落后”的条目是否写明了修订情况，复核意见栏是否全部有值。这套流程的价值在于把模型的产出从“答案”降级成“待核对材料”，法条引用是否可靠由核对动作决定，而不是由模型表述决定。合同涉及重大权利义务时，清单仍应交由具备相应资质的法律专业人员审定。