简介面向致力于用大模型工具提升法律文书效率的律师、法务、法律研究员与提示词工程师DeepSeek法律文书自动化方案全书60章、共460页围绕合同审查、起诉状起草、答辩状生成、法律意见书等12大核心场景给出100余个可复用的提示词模板。资源为13.33MB的单个PDF支持目录章节跳转和阅读器书签大纲快速定位内容完整、图表清晰目前已有107人学习/下载。内容从法律术语库与提示词交互设计入手逐层拆解风险条款识别、条款合规性校验、当事人信息结构化提取、诉讼请求规范化、事实与理由逻辑梳理、反驳逻辑构建、证据抗辩、法律问题拆解与法规检索关联等方法并重点呈现具体场景下的提示词设计思路与调优逻辑。同时附有15高频合同类型模板、20案由专项模板、10典型纠纷答辩模板可直接套用并迁移至实际业务能显著提升法律文书起草、审查与合规判断效率适合作为团队内部提示词模板库的起步参考。1. 法律文书自动化卡点在“语义适配”而不是“格式套用”一线律师日均处理5到8份文书合同审查、起诉状起草这类高频任务占六成以上重复劳动率接近七成。传统模板工具能解决格式合规却解决不了“同一套格式下内容如何适配具体案情”的问题——买卖合同纠纷和劳动争议的起诉状事实侧重点、证据组织逻辑完全不同死模板套出来的东西往往“形式对、内容空”。这份460页的DeepSeek法律文书自动化方案核心思路是用提示词工程把大模型的语义能力约束到法律场景中12大核心场景、100高频模板从合同审查、起诉状起草到判决书摘要每类文书都有对应的提示词结构、术语约束和输出校验逻辑。适合律所合伙人评估效率边界也适合法务或技术负责人做本地部署与API集成前的方案选型。2. 提示词工程适配法律语义术语库交互与三层约束2.1 法律术语歧义关键词匹配之外的第二层语义法律术语是“高密度语义载体”同一个词在不同场景下的适用规则完全不同。以“不可抗力”为例合同审查场景要判断免责条款是否覆盖疫情、政策变动等情形侵权责任场景讨论的却是不可抗力能否阻断因果关系。“视为同意”这类推定表述背后有明确的法定条件关键词匹配根本覆盖不了这也正是法律文书自动化区别于普通文本生成的底层难点。因此方案在提示词工程层之下专门设计了法律术语库。这个术语库不是简单词表而是带属性的知识结构每条术语包含定义、同义词、反义词、适用场景、效力级别等十余个属性术语间还有层级和关联关系形成可检索的知识图谱。数据侧给出的基线是8万术语覆盖民法、刑法、行政法等主要领域。实际落地时不必一上来就建全量库优先把合同审查、劳动争议、知识产权这三类高频场景的术语收干净比追求数量更有效。属性字段示例作用术语名称连带责任关键词匹配入口定义两个以上债务人就同一债务各负全部清偿责任提示词中的解释依据使用场景担保合同、侵权责任场景消歧效力级别法定条款、约定条款合规校验依据关联术语按份责任、保证责任逻辑推演扩展2.2 术语库驱动的提示词动态生成提示词模板的定义规范方案采用的基线是JSON Schema。模板不是死文本而是带占位符、条件逻辑和变量绑定的结构。下面这个例子是合同审查场景的简化模板{ template_id: contract_review_base_v1, scene: 合同审查, variables: { contract_type: {type: string, description: 合同类型如买卖合同、借款合同}, focus_clause: {type: array, items: {type: string}} }, conditional_rules: [ { when: contract_type 保证合同, inject: 重点审查保证方式是一般保证还是连带责任保证并关联《民法典》第六百八十六条 } ], output_schema: { risk_items: array, risk_level: enum(1-5), legal_basis: string } }这段结构的逻辑在于模板引擎先解析variables完成变量替换再检查conditional_rules根据合同类型动态注入对应的审查要点和法条指向最后用output_schema约束模型输出格式。实际生成提示词时会把JSON Schema渲染成自然语言指令例如“依据《民法典》第六百八十六条判断保证方式属于一般保证还是连带责任保证”。这里要特别注意条件规则不能写死术语库更新后应当能反向驱动模板内容否则提示词模板就失去了动态适配能力。2.3 语义层、逻辑层、规范层的三层适配机制方案把提示词在法律场景的适配拆成三层这个拆法对日常写提示词很有参考价值。语义层解决“词不准”。要求在提示词里显式给出法律术语的精确定义和边界条件把“可能影响守约方权益的条款”这种模糊描述改写成“审查违约金是否超过实际损失的30%且是否明显过高”。逻辑层解决“推不顺”通过引导模型按“构成要件→事实匹配→法律后果”的顺序输出避免跳跃式结论。规范层解决“格式不对”在提示词末尾附加文书格式约束如起诉状必须按当事人信息、诉讼请求、事实与理由、证据清单的顺序组织。三个层级要写进同一条提示词而不是分成三次调用。常见做法是先给背景设定再给术语定义再给逻辑步骤最后给输出格式。缺了任何一层输出就会变成“结构对但内容空”或“内容实但格式乱”。这份方案里后续所有场景模板本质上都是这三层适配的具体化。3. 合同审查场景从基础模板到风险量化与合规校验3.1 基础提示词模板的四个要素合同审查是这套方案里模板数量最多的场景15高频类型覆盖买卖、借款、租赁、劳动合同等。拆开看基础模板都在围绕四个要素组织合同类型决定审查侧重点审查对象决定范围审查基准决定法条和合规依据输出格式决定结果如何复用。{ task: 合同审查, contract_type: 房屋租赁合同, review_dimensions: [ 租赁物的权属与现状描述, 租金支付条款的确定性, 违约责任的对等性, 解除条件是否触发, 争议解决条款的效力 ], legal_basis: [民法典第七百零三条, 民法典第七百一十六条], output: { risk_points: 按条款位置列出, risk_level: 1-5整数, modification_suggestion: 给出可替换的条款文本 } }审查维度不能只给名词要给出具体判断标准。比如“违约责任的对等性”要展开为“出租方和承租方的违约金计算方式是否对称逾期支付租金与提前解约的赔偿标准是否明显失衡”。legal_basis字段的作用是给模型划定检索范围而不是让它自由联想。输出里要求给出可替换的条款文本这一步能把“指出问题”升级成“直接修改”减少律师二次返工。3.2 风险条款识别与等级量化方案里风险条款识别单独成章核心是两条设计思路等级量化与隐蔽条款挖掘。等级量化是给每个风险点打1到5分评分标准必须写进提示词否则模型给的“高风险”没有可操作性风险等级描述处理要求1表述瑕疵不影响权利义务提示修改即可2可能存在歧义给出两种解读3权利义务不对等建议重新协商4可能被认定无效提供替换方案5直接违反强制性规定明确法条并停止使用隐蔽条款的挖掘更考验提示词设计。常见手段包括要求模型识别模糊限定词如“合理”“及时”“相关费用”这类没有量化标准的表述要求检查交叉引用陷阱比如主合同引用了附件但附件对甲方的义务做了扩大化约定要求比对通用条款与特别约定识别用特别约定变相豁免责任的情况。多轮对话设计也值得借鉴。第一轮让模型输出全部风险点第二轮针对标记为3级以上的风险追问“如果对方提出该条款是为了平衡双方风险如何反驳”第三轮让模型检查修改后的条款文本是否引入了新风险。三轮下来比一次性投喂超长提示词的命中率高很多而且每一轮输出都可以留痕审计。3.3 法条映射与动态合规校验合规校验的提示词逻辑比风险识别更深一层需要建立“条款→法条→强制性规定”的映射链路。典型设计是让模型先定位合同条款再检索相关法律条文然后判断该条文是否属于强制性效力性规定最后输出校验结论。请对以下合同条款做合规性校验 条款原文【甲方逾期付款的按日万分之五支付违约金违约金总额不限】 校验步骤 1. 提取条款中的义务主体、违约情形、违约责任类型 2. 对应检索《民法典》合同编及相关司法解释 3. 判断违约金计算标准是否超过法定保护上限 4. 输出条款风险等级、涉及法条、修改建议这段提示词把校验拆成四个可追踪的动作模型每一步的输出都可以被复核。很多人写合规校验只给“请检查是否合规”模型会泛泛而谈。给定步骤后模型才会输出“按日万分之五折合年化18.25%参照相关司法解释超过法定保护上限的利息部分可能不被支持”这类具体结论。法条映射要特别注意时效性。方案里提到法规库24小时内同步更新落到提示词层面就是在模板中用法条编号占位符定期从法规库刷新法条版本否则会出现“引用已废止司法解释”的情况。动态合规校验还要支持跨场景迁移同一笔交易今天按买卖合同审查明天如果补充了担保关系提示词要能自动追加担保合同的合规审查维度。4. 起诉状与答辩状生成结构化提取与反驳逻辑构建4.1 当事人信息结构化提取起诉状起草的第一步是当事人信息的结构化提取。材料可能是聊天记录截图、借条照片、银行转账记录全是非结构化输入。方案的思路是先定义信息提取schema再让模型在限定范围内抽取而不是直接生成整段起诉状。import json extract_prompt 你是法律文书助理。请从以下材料中提取当事人信息只输出JSON。 材料{raw_material} 要求 1. name、id_no、address等字段缺失时填null不要猜测 2. role只能是原告或被告 3. contact可包含phone和wechat两个子字段 response deepseek_client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: extract_prompt}], temperature0.1, response_format{type: json_object} ) party_info json.loads(response[choices][0][message][content])这里把temperature压低到0.1是为了让抽取行为尽量确定化避免模型在当事人姓名、金额这类关键信息上自由发挥。response_format强制输出JSON省去后续解析报错的麻烦。字段缺失填null而不是让模型自己补是为了保留真实性——当事人信息一旦被模型“合理推断”后面整份文书的法律效力都会受牵连。上面代码基于OpenAI兼容接口的常见调用写法实际接入时换成自己的API endpoint即可。对法人当事人模板还要额外抽取统一社会信用代码、法定代表人、住所地以及可能影响管辖权的经常居住地字段。这些字段在提示词中显式列出比让模型自己决定“需要哪些信息”要稳定得多。信息提取完成后建议加一步“与原始材料比对”的校验提示词防止提取结果张冠李戴。4.2 诉讼请求表述规范化与多请求排序诉讼请求是起诉状里最容易被挑毛病的部分。“要求对方赔偿损失及利息”这类表述在立案阶段就可能被退回。方案给出了可操作的规范化标准请求事项必须具备可执行性金额计算式必须完整涉及履行义务的要写明期限。多请求组合的排序逻辑遵循“先确认之诉再给付之诉最后形成之诉”的原则。例如合同纠纷的诉讼请求顺序应当是确认合同解除确认之诉→返还已付货款给付之诉→赔偿资金占用损失给付之诉。提示词里需要明确这个排序规则否则模型输出的请求顺序会很随机。{ guide_rules: [ 每项请求以判令开头, 金额请求写清计算公式, 先确认后给付再形成, 多项请求之间不能逻辑冲突 ] }这些规则以数组形式放进提示词模型会逐条执行。“判令”开头是为了强制诉讼请求具备明确的命令语气金额请求写清计算式比如“以120万元为基数按LPR的1.5倍自2024年1月1日起计算至实际清偿日止”执行阶段才能算出确切数额。方案里还专门列出了常见错误表例如“请求返还财产但未写明财产特征”“请求继续履行但未说明履行标准”这些都可以做成提示词里的反例约束。4.3 证据清单与诉讼请求的关联匹配证据清单不能是证据的罗列每一项都要回答“证明了什么、支撑了哪个主张”。关联匹配提示词设计了三层映射证据到事实的映射、事实到诉讼请求的映射、证据之间的相互印证。提示词模板的组织方式是先列出所有诉讼请求编号再列出证据清单然后要求模型为每条诉讼请求分配对应证据并指出证据链中缺失的环节。这一步的输出可以直接作为举证目录草稿同时能反向暴露案件准备的薄弱点。案由不同关联逻辑也不同。合同纠纷侧重付款凭证、对账单、往来函件劳动争议侧重劳动合同、考勤记录、解除通知。提示词里必须预设证据类型优先级比如合同纠纷场景中书面合同的证据价值高于聊天记录这个优先级不显式声明模型给出的结果就会非常泛。证据与证据之间的印证关系也值得单独设计提示词哪份证据佐证了另一份证据的真实性哪两份证据之间存在矛盾这个分析结果可以直接转成质证意见的素材。4.4 答辩状的三层反驳逻辑答辩状的核心不是“否认”而是“构建反驳结构”。方案给出的三层结构可以直接抄进提示词反驳层级目标提示词指令示例事实性反驳质疑对方主张的事实基础列出原告陈述中的时间线矛盾点法律适用反驳质疑法律依据的适用范围判断原告引用的法条是否适用本案情形证据抗辩质疑证据能力与证明力检查证据是否原件、是否超期举证设计提示词时三层要分别成段输出不能混在一起。很多AI生成的答辩状通篇都是“我方认为原告证据不足”既没有指出具体哪份证据不足也没有说明为什么不足。通过限定“逐项针对原告证据编号给出抗辩意见”输出质量会立刻不一样。递进式设计也很关键第一轮先让模型输出所有反驳点第二轮把对应法条补进去最后一轮检查反驳逻辑是否自洽防止“一边承认收到货物一边否认合同关系成立”这类前后矛盾。5. 高阶落地法律意见书拆解、模板集成与模型微调边界5.1 法律问题层级拆解与结论确定性分级法律意见书的价值在于把复杂问题拆成可验证的子问题最后才给结论。方案里法律问题拆解的提示词设计核心是把大任务分解为“事实认定→法律适用→结论推导”三阶段。结论不能只有“是或否”要分级输出确定性结论、附带条件的结论、待补充材料的结论。在提示词末尾加上“结论确定性分级”字段模型会自然输出“基于现有材料…”“若补充…则…”这类带限定条件的表述更符合律所对意见书的审慎要求。5.2 模板集成与上下文工程100高频模板需要调度机制。常见做法是把模板按场景分类建立路由表通过API接口的参数匹配模板ID调用链上加一层缓存同一模板、同一批参数的结果可以复用实测能省掉不少重复计算。多轮对话场景真正要处理的是上下文工程对话接近模型上下文窗口上限时把早期信息压缩成摘要再注入核心约束放在用户消息末尾比放在中间更容易被模型遵循。方案里提到10轮对话记忆和50%的上下文压缩率落地时按自己的会话场景调这两项参数即可。5.3 法律语义模型微调的提示词参数配合如果要在DeepSeek基座之上做领域微调几条参数建议值得记录学习率从1e-5起步batch size在显存允许时取16到32用早停策略监控验证集损失连续3轮不降就停。提示词工程和微调是配合关系提示词约束输出格式微调负责提升术语准确性——先用一小批高质量术语标注数据验证再决定是否扩大规模比一上来就全量训练稳妥。最后补充一条模板迭代技巧所有线上失败案例都回写进模板校验器作为负例约束模板库才会越用越准。本文还有配套的精品资源点击获取 提示词工程驱动法律文书自动化：语义适配与合同审查实战
简介面向致力于用大模型工具提升法律文书效率的律师、法务、法律研究员与提示词工程师DeepSeek法律文书自动化方案全书60章、共460页围绕合同审查、起诉状起草、答辩状生成、法律意见书等12大核心场景给出100余个可复用的提示词模板。资源为13.33MB的单个PDF支持目录章节跳转和阅读器书签大纲快速定位内容完整、图表清晰目前已有107人学习/下载。内容从法律术语库与提示词交互设计入手逐层拆解风险条款识别、条款合规性校验、当事人信息结构化提取、诉讼请求规范化、事实与理由逻辑梳理、反驳逻辑构建、证据抗辩、法律问题拆解与法规检索关联等方法并重点呈现具体场景下的提示词设计思路与调优逻辑。同时附有15高频合同类型模板、20案由专项模板、10典型纠纷答辩模板可直接套用并迁移至实际业务能显著提升法律文书起草、审查与合规判断效率适合作为团队内部提示词模板库的起步参考。1. 法律文书自动化卡点在“语义适配”而不是“格式套用”一线律师日均处理5到8份文书合同审查、起诉状起草这类高频任务占六成以上重复劳动率接近七成。传统模板工具能解决格式合规却解决不了“同一套格式下内容如何适配具体案情”的问题——买卖合同纠纷和劳动争议的起诉状事实侧重点、证据组织逻辑完全不同死模板套出来的东西往往“形式对、内容空”。这份460页的DeepSeek法律文书自动化方案核心思路是用提示词工程把大模型的语义能力约束到法律场景中12大核心场景、100高频模板从合同审查、起诉状起草到判决书摘要每类文书都有对应的提示词结构、术语约束和输出校验逻辑。适合律所合伙人评估效率边界也适合法务或技术负责人做本地部署与API集成前的方案选型。2. 提示词工程适配法律语义术语库交互与三层约束2.1 法律术语歧义关键词匹配之外的第二层语义法律术语是“高密度语义载体”同一个词在不同场景下的适用规则完全不同。以“不可抗力”为例合同审查场景要判断免责条款是否覆盖疫情、政策变动等情形侵权责任场景讨论的却是不可抗力能否阻断因果关系。“视为同意”这类推定表述背后有明确的法定条件关键词匹配根本覆盖不了这也正是法律文书自动化区别于普通文本生成的底层难点。因此方案在提示词工程层之下专门设计了法律术语库。这个术语库不是简单词表而是带属性的知识结构每条术语包含定义、同义词、反义词、适用场景、效力级别等十余个属性术语间还有层级和关联关系形成可检索的知识图谱。数据侧给出的基线是8万术语覆盖民法、刑法、行政法等主要领域。实际落地时不必一上来就建全量库优先把合同审查、劳动争议、知识产权这三类高频场景的术语收干净比追求数量更有效。属性字段示例作用术语名称连带责任关键词匹配入口定义两个以上债务人就同一债务各负全部清偿责任提示词中的解释依据使用场景担保合同、侵权责任场景消歧效力级别法定条款、约定条款合规校验依据关联术语按份责任、保证责任逻辑推演扩展2.2 术语库驱动的提示词动态生成提示词模板的定义规范方案采用的基线是JSON Schema。模板不是死文本而是带占位符、条件逻辑和变量绑定的结构。下面这个例子是合同审查场景的简化模板{ template_id: contract_review_base_v1, scene: 合同审查, variables: { contract_type: {type: string, description: 合同类型如买卖合同、借款合同}, focus_clause: {type: array, items: {type: string}} }, conditional_rules: [ { when: contract_type 保证合同, inject: 重点审查保证方式是一般保证还是连带责任保证并关联《民法典》第六百八十六条 } ], output_schema: { risk_items: array, risk_level: enum(1-5), legal_basis: string } }这段结构的逻辑在于模板引擎先解析variables完成变量替换再检查conditional_rules根据合同类型动态注入对应的审查要点和法条指向最后用output_schema约束模型输出格式。实际生成提示词时会把JSON Schema渲染成自然语言指令例如“依据《民法典》第六百八十六条判断保证方式属于一般保证还是连带责任保证”。这里要特别注意条件规则不能写死术语库更新后应当能反向驱动模板内容否则提示词模板就失去了动态适配能力。2.3 语义层、逻辑层、规范层的三层适配机制方案把提示词在法律场景的适配拆成三层这个拆法对日常写提示词很有参考价值。语义层解决“词不准”。要求在提示词里显式给出法律术语的精确定义和边界条件把“可能影响守约方权益的条款”这种模糊描述改写成“审查违约金是否超过实际损失的30%且是否明显过高”。逻辑层解决“推不顺”通过引导模型按“构成要件→事实匹配→法律后果”的顺序输出避免跳跃式结论。规范层解决“格式不对”在提示词末尾附加文书格式约束如起诉状必须按当事人信息、诉讼请求、事实与理由、证据清单的顺序组织。三个层级要写进同一条提示词而不是分成三次调用。常见做法是先给背景设定再给术语定义再给逻辑步骤最后给输出格式。缺了任何一层输出就会变成“结构对但内容空”或“内容实但格式乱”。这份方案里后续所有场景模板本质上都是这三层适配的具体化。3. 合同审查场景从基础模板到风险量化与合规校验3.1 基础提示词模板的四个要素合同审查是这套方案里模板数量最多的场景15高频类型覆盖买卖、借款、租赁、劳动合同等。拆开看基础模板都在围绕四个要素组织合同类型决定审查侧重点审查对象决定范围审查基准决定法条和合规依据输出格式决定结果如何复用。{ task: 合同审查, contract_type: 房屋租赁合同, review_dimensions: [ 租赁物的权属与现状描述, 租金支付条款的确定性, 违约责任的对等性, 解除条件是否触发, 争议解决条款的效力 ], legal_basis: [民法典第七百零三条, 民法典第七百一十六条], output: { risk_points: 按条款位置列出, risk_level: 1-5整数, modification_suggestion: 给出可替换的条款文本 } }审查维度不能只给名词要给出具体判断标准。比如“违约责任的对等性”要展开为“出租方和承租方的违约金计算方式是否对称逾期支付租金与提前解约的赔偿标准是否明显失衡”。legal_basis字段的作用是给模型划定检索范围而不是让它自由联想。输出里要求给出可替换的条款文本这一步能把“指出问题”升级成“直接修改”减少律师二次返工。3.2 风险条款识别与等级量化方案里风险条款识别单独成章核心是两条设计思路等级量化与隐蔽条款挖掘。等级量化是给每个风险点打1到5分评分标准必须写进提示词否则模型给的“高风险”没有可操作性风险等级描述处理要求1表述瑕疵不影响权利义务提示修改即可2可能存在歧义给出两种解读3权利义务不对等建议重新协商4可能被认定无效提供替换方案5直接违反强制性规定明确法条并停止使用隐蔽条款的挖掘更考验提示词设计。常见手段包括要求模型识别模糊限定词如“合理”“及时”“相关费用”这类没有量化标准的表述要求检查交叉引用陷阱比如主合同引用了附件但附件对甲方的义务做了扩大化约定要求比对通用条款与特别约定识别用特别约定变相豁免责任的情况。多轮对话设计也值得借鉴。第一轮让模型输出全部风险点第二轮针对标记为3级以上的风险追问“如果对方提出该条款是为了平衡双方风险如何反驳”第三轮让模型检查修改后的条款文本是否引入了新风险。三轮下来比一次性投喂超长提示词的命中率高很多而且每一轮输出都可以留痕审计。3.3 法条映射与动态合规校验合规校验的提示词逻辑比风险识别更深一层需要建立“条款→法条→强制性规定”的映射链路。典型设计是让模型先定位合同条款再检索相关法律条文然后判断该条文是否属于强制性效力性规定最后输出校验结论。请对以下合同条款做合规性校验 条款原文【甲方逾期付款的按日万分之五支付违约金违约金总额不限】 校验步骤 1. 提取条款中的义务主体、违约情形、违约责任类型 2. 对应检索《民法典》合同编及相关司法解释 3. 判断违约金计算标准是否超过法定保护上限 4. 输出条款风险等级、涉及法条、修改建议这段提示词把校验拆成四个可追踪的动作模型每一步的输出都可以被复核。很多人写合规校验只给“请检查是否合规”模型会泛泛而谈。给定步骤后模型才会输出“按日万分之五折合年化18.25%参照相关司法解释超过法定保护上限的利息部分可能不被支持”这类具体结论。法条映射要特别注意时效性。方案里提到法规库24小时内同步更新落到提示词层面就是在模板中用法条编号占位符定期从法规库刷新法条版本否则会出现“引用已废止司法解释”的情况。动态合规校验还要支持跨场景迁移同一笔交易今天按买卖合同审查明天如果补充了担保关系提示词要能自动追加担保合同的合规审查维度。4. 起诉状与答辩状生成结构化提取与反驳逻辑构建4.1 当事人信息结构化提取起诉状起草的第一步是当事人信息的结构化提取。材料可能是聊天记录截图、借条照片、银行转账记录全是非结构化输入。方案的思路是先定义信息提取schema再让模型在限定范围内抽取而不是直接生成整段起诉状。import json extract_prompt 你是法律文书助理。请从以下材料中提取当事人信息只输出JSON。 材料{raw_material} 要求 1. name、id_no、address等字段缺失时填null不要猜测 2. role只能是原告或被告 3. contact可包含phone和wechat两个子字段 response deepseek_client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: extract_prompt}], temperature0.1, response_format{type: json_object} ) party_info json.loads(response[choices][0][message][content])这里把temperature压低到0.1是为了让抽取行为尽量确定化避免模型在当事人姓名、金额这类关键信息上自由发挥。response_format强制输出JSON省去后续解析报错的麻烦。字段缺失填null而不是让模型自己补是为了保留真实性——当事人信息一旦被模型“合理推断”后面整份文书的法律效力都会受牵连。上面代码基于OpenAI兼容接口的常见调用写法实际接入时换成自己的API endpoint即可。对法人当事人模板还要额外抽取统一社会信用代码、法定代表人、住所地以及可能影响管辖权的经常居住地字段。这些字段在提示词中显式列出比让模型自己决定“需要哪些信息”要稳定得多。信息提取完成后建议加一步“与原始材料比对”的校验提示词防止提取结果张冠李戴。4.2 诉讼请求表述规范化与多请求排序诉讼请求是起诉状里最容易被挑毛病的部分。“要求对方赔偿损失及利息”这类表述在立案阶段就可能被退回。方案给出了可操作的规范化标准请求事项必须具备可执行性金额计算式必须完整涉及履行义务的要写明期限。多请求组合的排序逻辑遵循“先确认之诉再给付之诉最后形成之诉”的原则。例如合同纠纷的诉讼请求顺序应当是确认合同解除确认之诉→返还已付货款给付之诉→赔偿资金占用损失给付之诉。提示词里需要明确这个排序规则否则模型输出的请求顺序会很随机。{ guide_rules: [ 每项请求以判令开头, 金额请求写清计算公式, 先确认后给付再形成, 多项请求之间不能逻辑冲突 ] }这些规则以数组形式放进提示词模型会逐条执行。“判令”开头是为了强制诉讼请求具备明确的命令语气金额请求写清计算式比如“以120万元为基数按LPR的1.5倍自2024年1月1日起计算至实际清偿日止”执行阶段才能算出确切数额。方案里还专门列出了常见错误表例如“请求返还财产但未写明财产特征”“请求继续履行但未说明履行标准”这些都可以做成提示词里的反例约束。4.3 证据清单与诉讼请求的关联匹配证据清单不能是证据的罗列每一项都要回答“证明了什么、支撑了哪个主张”。关联匹配提示词设计了三层映射证据到事实的映射、事实到诉讼请求的映射、证据之间的相互印证。提示词模板的组织方式是先列出所有诉讼请求编号再列出证据清单然后要求模型为每条诉讼请求分配对应证据并指出证据链中缺失的环节。这一步的输出可以直接作为举证目录草稿同时能反向暴露案件准备的薄弱点。案由不同关联逻辑也不同。合同纠纷侧重付款凭证、对账单、往来函件劳动争议侧重劳动合同、考勤记录、解除通知。提示词里必须预设证据类型优先级比如合同纠纷场景中书面合同的证据价值高于聊天记录这个优先级不显式声明模型给出的结果就会非常泛。证据与证据之间的印证关系也值得单独设计提示词哪份证据佐证了另一份证据的真实性哪两份证据之间存在矛盾这个分析结果可以直接转成质证意见的素材。4.4 答辩状的三层反驳逻辑答辩状的核心不是“否认”而是“构建反驳结构”。方案给出的三层结构可以直接抄进提示词反驳层级目标提示词指令示例事实性反驳质疑对方主张的事实基础列出原告陈述中的时间线矛盾点法律适用反驳质疑法律依据的适用范围判断原告引用的法条是否适用本案情形证据抗辩质疑证据能力与证明力检查证据是否原件、是否超期举证设计提示词时三层要分别成段输出不能混在一起。很多AI生成的答辩状通篇都是“我方认为原告证据不足”既没有指出具体哪份证据不足也没有说明为什么不足。通过限定“逐项针对原告证据编号给出抗辩意见”输出质量会立刻不一样。递进式设计也很关键第一轮先让模型输出所有反驳点第二轮把对应法条补进去最后一轮检查反驳逻辑是否自洽防止“一边承认收到货物一边否认合同关系成立”这类前后矛盾。5. 高阶落地法律意见书拆解、模板集成与模型微调边界5.1 法律问题层级拆解与结论确定性分级法律意见书的价值在于把复杂问题拆成可验证的子问题最后才给结论。方案里法律问题拆解的提示词设计核心是把大任务分解为“事实认定→法律适用→结论推导”三阶段。结论不能只有“是或否”要分级输出确定性结论、附带条件的结论、待补充材料的结论。在提示词末尾加上“结论确定性分级”字段模型会自然输出“基于现有材料…”“若补充…则…”这类带限定条件的表述更符合律所对意见书的审慎要求。5.2 模板集成与上下文工程100高频模板需要调度机制。常见做法是把模板按场景分类建立路由表通过API接口的参数匹配模板ID调用链上加一层缓存同一模板、同一批参数的结果可以复用实测能省掉不少重复计算。多轮对话场景真正要处理的是上下文工程对话接近模型上下文窗口上限时把早期信息压缩成摘要再注入核心约束放在用户消息末尾比放在中间更容易被模型遵循。方案里提到10轮对话记忆和50%的上下文压缩率落地时按自己的会话场景调这两项参数即可。5.3 法律语义模型微调的提示词参数配合如果要在DeepSeek基座之上做领域微调几条参数建议值得记录学习率从1e-5起步batch size在显存允许时取16到32用早停策略监控验证集损失连续3轮不降就停。提示词工程和微调是配合关系提示词约束输出格式微调负责提升术语准确性——先用一小批高质量术语标注数据验证再决定是否扩大规模比一上来就全量训练稳妥。最后补充一条模板迭代技巧所有线上失败案例都回写进模板校验器作为负例约束模板库才会越用越准。本文还有配套的精品资源点击获取