简介面向法律从业者、法务与法律科技产品经理的DeepSeek落地实战手册聚焦提示词工程在法律文书自动化中的应用覆盖合同审查、起诉状起草、答辩状生成、法律意见书等12大核心场景并配有100余套高频模板帮助读者理解从法律术语库构建、风险条款识别到法规检索与结论推导的完整提示词设计链路。资料为PDF电子档共1个文件约13.33MB总页数460页、60个章节支持目录跳转与书签大纲快速定位可按需直达具体模板。全文含15合同类型、20案由专项、10典型纠纷答辩等实例图表与目录显示正常便于系统研读或随时查阅。目前已有108人学习下载适合希望借助DeepSeek提升法律文书撰写效率的实务人员与研究者。1. 这份460页的DeepSeek提示词工程方案解决的是法律文书的三重矛盾法律文书自动化喊了多年市面上多数工具停留在固定模板套用层面——能填变量不能理解语义。而这份基于提示词工程的460页方案把DeepSeek大模型的能力真正落到了法律实务里合同审查、起诉状起草、答辩状生成、律师函、法律意见书、尽调报告等12大核心场景配了100可直接复用的高频模板。它不是讲大模型原理的科普册子而是围绕提示词怎么设计、参数怎么调、场景怎么切的工程手册。适合三类人被重复文书工作淹没的律师和法务、给法律团队做自动化工具的开发者、以及想用DeepSeek API落地垂直场景的提示词工程师。全篇按架构原理 → 场景拆解 → 模板实例 → 避坑优化层层递进每个模板都给了结构设计和优化方法照着改就能投入生产。2. 提示词工程接棒模板工具法律文书自动化的技术拐点在哪2.1 传统模板工具的三个死穴法律文书有刚性格式要求起诉状必须有当事人信息、诉讼请求、事实与理由判决书必须区分首部、事实、理由、裁判主文。传统模板工具能保证格式但处理不了三个问题一是场景适配买卖合同纠纷和劳动合同纠纷的事实侧重点完全不同模板无法感知二是术语歧义应当承担连带责任和可以承担连带责任在法律后果上差之毫厘谬以千里关键词匹配完全识别不了三是隐含逻辑视为同意这类推定条款要结合上下文判断规则引擎覆盖不了。提示词工程恰好补上了这几个缺口。它的核心不是让模型自由发挥而是通过结构化指令把法律场景的格式规范、术语定义、逻辑约束注入生成过程。简单说模板工具是填空提示词工程是按图施工——图纸画得越细模型输出的专业度越可控。2.2 结构化提示词的五个要素我在拆这份方案时发现所有法律场景的提示词模板底层都跑不出五个要素角色设定让模型进入法律专业角色如你是一名有十年实务经验的合同审查律师任务描述说清楚要做什么如审查以下买卖合同的交付条款识别风险并给出修改建议输入数据待处理的合同文本、案件事实、证据清单等输出约束格式、结构、详略程度、是否引用法条校验指令要求模型自查如检查诉讼请求是否明确、证据是否支撑事实主张这五个要素对应到实际模板里就是一个结构化的JSON定义。2.3 一个可落地的合同审查提示词骨架以合同审查场景为例我在实践中通常会先把提示词模板定义成JSON Schema方便版本管理和动态变量注入{ template_id: contract_review_base_v1, role: 你是一名有十年实务经验的合同审查律师, task: 审查以下合同输出风险条款清单和修改建议, input_variables: [contract_text, contract_type, industry], output_schema: { risk_items: [ { clause_location: 原合同第几条/第几款, risk_type: 付款风险|违约责任|知识产权|保密义务|其他, risk_level: 高|中|低, risk_description: 具体风险描述, modification_suggestion: 修改后表述 } ], overall_conclusion: 整体审查结论不超过200字 }, rules: [ 仅引用中国现行有效法律法规不确定的法条不得引用, 风险等级为高的条款必须给出可直接替换的修改文本, 不得遗漏合同中的免责条款和争议解决条款 ] }这段结构的关键在于rules字段。法律提示词工程和通用场景最大的区别就在这里——模型天然有胡编法条的倾向必须在提示词层面加硬约束。output_schema定义了输出结构让后续程序化处理成为可能input_variables留了变量接口同一套骨架可以套到租赁合同、劳动合同、股权转让协议上。参数要说明白了template_id用于版本管理和A/B测试改动模板后建议递增版本号risk_level三级分类对应正文中的风险等级量化逻辑output_schema里的字段名尽量用英文或拼音固定避免中文键在不同编码环境下出问题。这套骨架配合DeepSeek API调用时温度参数建议设0.3以下法律场景对创造性要求极低温度越高越容易跑偏。3. 合同审查场景从基础模板到风险识别再到合规校验的完整链路3.1 基础审查模板要素表与输出项的设计合同审查是整个方案里场景拆分最细的部分光合同类型就列了15种。拆完这份资源后我的判断是不同合同类型的审查重点差异极大基础模板必须设计成可插拔结构——公共审查项主体资格、合同效力、送达条款 类型专属审查项。以买卖合同为例交付验收条款是重心租赁合同要看押金返还条件和维修责任划分劳动合同绕不开解除条件和赔偿金计算。方案里的做法是给每种合同类型配一份专属要素表提示词里明确列出必查项。我常用的方式是在提示词中加一段请按以下清单逐项审查 1. 双方主体资格与签约权限 2. 标的物描述是否明确含数量、质量标准、验收方式 3. 付款条件与付款节点是否对等 4. 违约责任是否双向对等 5. 争议解决条款是否有效 6. 送达地址条款是否完备这份清单直接决定审查覆盖率。少了第6条合同纠纷时对方玩失踪你就只能公告送达多耗半年时间——这类实务细节模型自己想不到必须靠清单提示。3.2 风险条款识别显性风险之外还要挖隐蔽条款方案里把风险识别分了三个层次这个分层值得直接落地第一层是显性风险违约金比例畸高超过实际损失30%、单方免责条款、无限责任条款。这类模型一眼就能识别提示词里给两个示例就够。第二层是隐蔽性风险比如最终解释权归甲方所有格式条款无效情形、乙方逾期付款超30日的甲方有权解除合同并没收全部已付款项惩罚性条款、本合同未尽事宜双方协商解决等于没约定。这些表述表面合规实质有坑。挖掘这类风险提示词里要加一个专门指令注意识别以下类型的隐蔽性条款 - 格式条款中免除己方责任、加重对方责任的表述 - 以补充协议、附件、备注等形式规避主合同约束的条款 - 引用惯例行业标准但未明确具体内容的条款第三层是风险等级量化。方案里的逻辑是风险等级 影响程度 × 发生概率。高 直接影响合同核心目的/极可能触发中 可能导致损失/特定条件下触发低 表述瑕疵/极端情况触发。输出时要求模型给每个风险项打等级人工复核时优先看高。3.3 合规性校验法条关联与强制条款识别合规校验这块提示词设计的关键是法条关联映射。方案的做法是让模型先提取合同条款再关联对应法律条文最后判断是否合规。比如对外担保条款必须提示模型关联《公司法》第16条——担保是否经过股东会或董事会决议格式条款要关联《民法典》第497条。实操中我一般不建议让模型直接引用法条内容更稳妥的做法是只让模型输出该条款可能违反XX法关于XX的规定具体条文请人工复核避免模型伪造法条细节。强制条款识别是另一个重点。有些条款是法律强制规定合同里写不写都有效比如《民法典》第506条规定的造成对方人身损害的免责条款无效有些条款不写就有风险比如买卖合同中质量检验期间。提示词里用强制识别 缺失补全两个动作请完成两项工作 1. 识别并标出合同中的无效条款仅限法律明确规定无效的情形需输出对应法律依据 2. 检查是否存在法律规定应当具备但合同缺失的条款缺失的请补全建议文本3.4 多轮对话审查与错误修正机制一次审查搞不定所有问题方案里设计了多轮对话模式。第一轮出初稿第二轮针对风险条款追细节第三轮整体复核。多轮对话的提示词设计与单轮差别很大关键在于上下文状态管理——第二轮时模型要知道第一轮已经识别了哪些条款避免重复审查或漏审。我通常在提示词里增加前一轮已经识别出的风险条款{list} 请勿重复审查以上条款。 本轮聚焦{focused_question} 如有与前一轮结论冲突的判断请明确说明。错误修正机制在方案里占了独立一节核心是反馈-重生成-校验闭环。模型输出的修改建议如果不被律师认可把律师意见作为新指令喂回去让模型重新生成。这个设计很务实——AI出初稿、人类定终稿比让模型一步到位可靠得多。4. 起诉状与答辩状信息结构化提取和逻辑构建的提示词设计4.1 当事人信息提取用JSON Schema锁死输出格式起草起诉状第一步是把当事人信息从非结构化材料里抽出来。自然人有姓名、性别、出生年月日、民族、职业、住址、联系方式七要素法人有名称、住所地、法定代表人姓名职务、统一社会信用代码四要素。材料可能是聊天记录、合同扫描件、身份证照片转文字什么格式都有。方案里的思路是提示词定义字段模型负责抽取填充。这个场景的关键是字段必须封闭——让模型自由发挥就会抽出一堆没用的信息。我落地时用的是严格JSON输出约束extraction_prompt 请从以下材料中提取当事人信息严格按JSON格式输出不要添加任何额外文字 材料原文 {raw_material} 输出要求 1. 自然人字段name(姓名), gender(性别), birth_date(出生日期,格式YYYY-MM-DD), ethnicity(民族), occupation(职业), address(住址), contact(联系方式) 2. 法人字段org_name(名称), registered_address(住所地), legal_rep_name(法定代表人姓名), legal_rep_title(法定代表人职务), credit_code(统一社会信用代码) 3. 无法识别的字段填null不要推测 4. 如材料中出现多个主体按原告/被告/第三人分别输出 输出示例 {plaintiff: {name: 张三, gender: 男}, defendant: {org_name: 某科技有限公司}} 这里用了fill null和不要推测两条硬约束能显著降低模型编造信息的概率。逻辑说明一下按原告/被告/第三人分别输出这个指令省掉了后续数据结构化的大力气输出示例是给模型一个格式锚点比单纯写请按JSON格式输出有效得多。参数上这个场景的温度可以压到0.2以下信息抽取是确定性任务温度太高会在边界字段上乱猜。4.2 诉讼请求规范化给付之诉、确认之诉、形成之诉的分类处理诉讼请求的规范化程度直接影响立案效率。方案里把请求类型分成三类分别设计提示词给付之诉请求判令被告支付XX元、确认之诉请求确认合同无效、形成之诉请求撤销XX决议/解除合同。每类的表述规范完全不同混淆了模型就会生成请求依法确认被告支付货款这种四不像。多请求组合场景方案里有明确的排序逻辑先确认之诉、再给付之诉、最后形成之诉。比如一个案件既要求确认合同无效又要求返还已付款项表述顺序是1. 确认双方签订的XX合同无效2. 判令被告返还原告已付货款人民币XX元。这个顺序不能反——返还货款的前提是合同被确认无效逻辑上有先后依赖。提示词里的表述规范指令我一般这样写请将以下诉讼请求按标准法律文书表述规范改写 1. 明确请求类型给付/确认/形成 2. 金额统一用人民币数字用大写还是小写按司法机关要求 3. 多个请求按前提性请求在前、结果性请求在后排序 4. 不使用依法如有异议等模糊表述4.3 事实与理由逻辑梳理时间线和法律关系要件事实部分最忌讳平铺直叙。方案里的核心方法是让模型先按时间线提取关键事件再按法律关系的构成要件重组。以买卖合同纠纷为例构成要件是合同成立-履行-违约-损失事实描述就按这条线组织何时签订合同、原告履行了哪些义务、被告何时违约、原告因此产生多少损失。提示词设计上要给模型一个骨架请按以下逻辑结构梳理案件事实 第1层双方合同关系建立的时间与方式 第2层原告已履行的合同义务附证据编号 第3层被告违约的具体行为与时间节点 第4层原告的损失计算依据 在描述事实时仅陈述客观事实不加入主观评价。加了不加入主观评价之后输出质量会有明显提升。模型默认倾向写成被告恶意拖欠货款这属于定性评价不是事实陈述。法律文书里事实部分应该是被告自2025年3月起未再支付货款截至起诉日累计拖欠金额为XX元结论留给法院做。理由部分则相反要有法律推理逻辑。方案里给了不同案由的差异化策略比如劳动争议要突出劳动关系的认定是否有劳动合同、工资支付记录、社保缴纳记录侵权纠纷要按侵权行为-损害结果-因果关系-过错四要件展开。4.4 答辩状反驳逻辑三层结构与递进式提示词答辩状的提示词设计比起诉状更考验功力因为被告的立场是驳得针对原告的主张逐层拆招。方案里把反驳逻辑分成三层事实性反驳否认或修正原告主张的事实。提示词设计要点是让模型逐条对照原告的事实主张找事实层面的破绽——时间对不上、金额对不上、主体对不上。法律适用反驳主张原告援引的法律条款不适用或应当适用其他条款。比如原告主张适用《民法典》第577条追究违约责任被告可辩称合同尚未生效不构成违约。证据抗辩对证据的三性提出异议——合法性证据取得方式违法、关联性证据与待证事实无关、真实性证据系伪造或已篡改。这三层的提示词要分开设计最后合成一份答辩状。我常用的递进式策略是第一轮分别输出三层反驳的要点清单 - 事实层列出原告事实主张与证据的矛盾点 - 法律层列出原告法律依据的可辩点 - 证据层列出证据三性瑕疵 第二轮仅针对事实层展开详细论述生成该部分的完整表述 第三轮合并三层内容按答辩状的文书结构整理输出5. 避坑指南提示词工程在法律场景的五个高频翻车点5.1 法条张冠李戴现象生成的文书中出现不存在的法条编号或法条内容与编号对应不上——《民法典》第577条写成了违约方应当承担侵权责任。原因提示词要求模型引用相关法律条文但没限定引用范围。大模型在不确定时倾向编造听起来合理的条文法律条文这种高结构化内容最容易出现幻觉。解决提示词里明确加硬约束仅引用你确定100%存在的法律条文不确定的不要引用用相关规定替代。建议后台做法是单独维护一个法条库用RAG把真实法条检索出来喂给模型让模型基于检索结果做判断而不是靠记忆生成。5.2 同一模板多次输出格式漂移现象同一份提示词调用十次输出结构各不相同——有时结论在前分析在后有时先列风险再给建议有时用表格有时用列表。原因提示词描述了输出要求但没有给结构锚点。模型对清晰、结构化的理解是概率性的每次解码路径不同结构就漂移。解决除了在提示词中定义严格的输出顺序先风险清单、后整体结论还要配一个few-shot示例——给一段真实的输入输出对让模型照着示例结构走。如果对格式要求极其严格可以让模型先输出JSON再用代码转成文书格式格式的事不交给模型。5.3 长合同审查漏检后段条款现象一份80页的合同模型审查前半部分很仔细到后半部分开始敷衍输出的风险条款数量明显减少。原因上下文长度限制。注意力机制对长文本的中后段关注度天然衰减加上提示词里的任务指令占用了前部注意力后半部分成了注意力盲区。解决把长合同按章节切块处理每块单独审查最后合并风险清单。方案里提到的上下文压缩技巧也可以配合使用——先让模型对每块输出300字内的压缩摘要再基于摘要做全局风险关联分析。5.4 多轮对话逻辑漂移现象第一轮审查发现A条款有风险第三轮模型给出的修改建议与第一轮矛盾甚至无理由地认为A条款没问题。原因对话历史的状态管理缺失。法律场景的复杂逻辑关系不能靠模型的隐式记忆模型可能在中途忘记了自己之前给出的判断。解决每轮对话的提示词固定带上前轮已确认结论列表。我的一般做法是设计一个简单的状态对象在每轮调用时把之前确认的条款和判断注入提示词模型只负责增量分析不做全局重判。5.5 术语近义替换导致法律后果偏差现象合同审查中模型把应当承担连带责任的建议改成了可要求其承担补充赔偿责任看起来是优化表述实际改变了法律后果的性质。原因模型对法律术语的精确适用条件不敏感。连带责任和补充赔偿责任在构成要件、追偿路径上完全不同模型仅凭语义相似度做了替换。解决在提示词里嵌入术语锁定声明——以下术语的含义以中华人民共和国法律规定的标准含义为准不得随意替换连带责任、补充赔偿责任、按份责任、不真正连带责任。涉及关键术语时要求模型输出原始条款 修改建议两栏对照人工重点看栏间差异。6. 让模板体系跑起来集成策略、调用优化与效果验证模板多到100怎么组织才能不变成一团乱麻方案里给了三个方向的思路。第一是模板关联机制场景之间是有依赖的。起诉状的证据清单模板和法律意见书的法规检索模板底层共享同一套证据分类体系和法条映射关系。设计模板时把这些公共模块抽出来做内嵌引用避免一个场景改了、另一个场景没跟着同步。第二是调用效率优化。高频模板合同审查、起诉状起草做预加载低频模板按需加载同一批合同的审查请求做批量处理配合异步调用。模板本身可以序列化缓存避免每次请求都重新解析JSON Schema。这部分方案的第六十章讲了多级缓存架构实操中先从高频模板预加载 变量预编译两个动作做起效果最明显。第三是效果验证。光有模板不行得上线后持续验证。我的习惯是抽5%~10%的文书做人工复核重点盯三条指标格式合规率法院或客户退件率、事实错误率当事人姓名、金额、日期错误、修改成本律师修改生成文本的耗时。方案里提到的实测错误率低于3%是一个合理目标但前提是提示词加了一层人工复核的兜底阀——AI生成初稿律师负责终审这个流程不能省。这套方案真正解决的是从0到1的问题提示词怎么设计、模板怎么组织、场景怎么拆。文件里的60个章节覆盖了从数据处理到模型微调再到模板优化的全链路但最值钱的还是12大核心场景的100模板本身——它们相当于一份法律提示词工程的种子库拿到手之后按自己的业务场景改改变量、调调法条库就能产出一套可用的系统。我自己的习惯是每接到一个法律自动化项目先跑一遍这100模板里的相关场景确认输出质量后再动模型微调——多数时候提示词层面的调整就够用了不必走到训练那一步。做提示词工程越久越明白一个道理模型的能力边界在那里能不能用起来取决于你对场景的理解和对指令的精修。希望这份模板库能帮你少走几步弯路。本文还有配套的精品资源点击获取
DeepSeek提示词工程实战：法律文书自动化的完整方案与模板
简介面向法律从业者、法务与法律科技产品经理的DeepSeek落地实战手册聚焦提示词工程在法律文书自动化中的应用覆盖合同审查、起诉状起草、答辩状生成、法律意见书等12大核心场景并配有100余套高频模板帮助读者理解从法律术语库构建、风险条款识别到法规检索与结论推导的完整提示词设计链路。资料为PDF电子档共1个文件约13.33MB总页数460页、60个章节支持目录跳转与书签大纲快速定位可按需直达具体模板。全文含15合同类型、20案由专项、10典型纠纷答辩等实例图表与目录显示正常便于系统研读或随时查阅。目前已有108人学习下载适合希望借助DeepSeek提升法律文书撰写效率的实务人员与研究者。1. 这份460页的DeepSeek提示词工程方案解决的是法律文书的三重矛盾法律文书自动化喊了多年市面上多数工具停留在固定模板套用层面——能填变量不能理解语义。而这份基于提示词工程的460页方案把DeepSeek大模型的能力真正落到了法律实务里合同审查、起诉状起草、答辩状生成、律师函、法律意见书、尽调报告等12大核心场景配了100可直接复用的高频模板。它不是讲大模型原理的科普册子而是围绕提示词怎么设计、参数怎么调、场景怎么切的工程手册。适合三类人被重复文书工作淹没的律师和法务、给法律团队做自动化工具的开发者、以及想用DeepSeek API落地垂直场景的提示词工程师。全篇按架构原理 → 场景拆解 → 模板实例 → 避坑优化层层递进每个模板都给了结构设计和优化方法照着改就能投入生产。2. 提示词工程接棒模板工具法律文书自动化的技术拐点在哪2.1 传统模板工具的三个死穴法律文书有刚性格式要求起诉状必须有当事人信息、诉讼请求、事实与理由判决书必须区分首部、事实、理由、裁判主文。传统模板工具能保证格式但处理不了三个问题一是场景适配买卖合同纠纷和劳动合同纠纷的事实侧重点完全不同模板无法感知二是术语歧义应当承担连带责任和可以承担连带责任在法律后果上差之毫厘谬以千里关键词匹配完全识别不了三是隐含逻辑视为同意这类推定条款要结合上下文判断规则引擎覆盖不了。提示词工程恰好补上了这几个缺口。它的核心不是让模型自由发挥而是通过结构化指令把法律场景的格式规范、术语定义、逻辑约束注入生成过程。简单说模板工具是填空提示词工程是按图施工——图纸画得越细模型输出的专业度越可控。2.2 结构化提示词的五个要素我在拆这份方案时发现所有法律场景的提示词模板底层都跑不出五个要素角色设定让模型进入法律专业角色如你是一名有十年实务经验的合同审查律师任务描述说清楚要做什么如审查以下买卖合同的交付条款识别风险并给出修改建议输入数据待处理的合同文本、案件事实、证据清单等输出约束格式、结构、详略程度、是否引用法条校验指令要求模型自查如检查诉讼请求是否明确、证据是否支撑事实主张这五个要素对应到实际模板里就是一个结构化的JSON定义。2.3 一个可落地的合同审查提示词骨架以合同审查场景为例我在实践中通常会先把提示词模板定义成JSON Schema方便版本管理和动态变量注入{ template_id: contract_review_base_v1, role: 你是一名有十年实务经验的合同审查律师, task: 审查以下合同输出风险条款清单和修改建议, input_variables: [contract_text, contract_type, industry], output_schema: { risk_items: [ { clause_location: 原合同第几条/第几款, risk_type: 付款风险|违约责任|知识产权|保密义务|其他, risk_level: 高|中|低, risk_description: 具体风险描述, modification_suggestion: 修改后表述 } ], overall_conclusion: 整体审查结论不超过200字 }, rules: [ 仅引用中国现行有效法律法规不确定的法条不得引用, 风险等级为高的条款必须给出可直接替换的修改文本, 不得遗漏合同中的免责条款和争议解决条款 ] }这段结构的关键在于rules字段。法律提示词工程和通用场景最大的区别就在这里——模型天然有胡编法条的倾向必须在提示词层面加硬约束。output_schema定义了输出结构让后续程序化处理成为可能input_variables留了变量接口同一套骨架可以套到租赁合同、劳动合同、股权转让协议上。参数要说明白了template_id用于版本管理和A/B测试改动模板后建议递增版本号risk_level三级分类对应正文中的风险等级量化逻辑output_schema里的字段名尽量用英文或拼音固定避免中文键在不同编码环境下出问题。这套骨架配合DeepSeek API调用时温度参数建议设0.3以下法律场景对创造性要求极低温度越高越容易跑偏。3. 合同审查场景从基础模板到风险识别再到合规校验的完整链路3.1 基础审查模板要素表与输出项的设计合同审查是整个方案里场景拆分最细的部分光合同类型就列了15种。拆完这份资源后我的判断是不同合同类型的审查重点差异极大基础模板必须设计成可插拔结构——公共审查项主体资格、合同效力、送达条款 类型专属审查项。以买卖合同为例交付验收条款是重心租赁合同要看押金返还条件和维修责任划分劳动合同绕不开解除条件和赔偿金计算。方案里的做法是给每种合同类型配一份专属要素表提示词里明确列出必查项。我常用的方式是在提示词中加一段请按以下清单逐项审查 1. 双方主体资格与签约权限 2. 标的物描述是否明确含数量、质量标准、验收方式 3. 付款条件与付款节点是否对等 4. 违约责任是否双向对等 5. 争议解决条款是否有效 6. 送达地址条款是否完备这份清单直接决定审查覆盖率。少了第6条合同纠纷时对方玩失踪你就只能公告送达多耗半年时间——这类实务细节模型自己想不到必须靠清单提示。3.2 风险条款识别显性风险之外还要挖隐蔽条款方案里把风险识别分了三个层次这个分层值得直接落地第一层是显性风险违约金比例畸高超过实际损失30%、单方免责条款、无限责任条款。这类模型一眼就能识别提示词里给两个示例就够。第二层是隐蔽性风险比如最终解释权归甲方所有格式条款无效情形、乙方逾期付款超30日的甲方有权解除合同并没收全部已付款项惩罚性条款、本合同未尽事宜双方协商解决等于没约定。这些表述表面合规实质有坑。挖掘这类风险提示词里要加一个专门指令注意识别以下类型的隐蔽性条款 - 格式条款中免除己方责任、加重对方责任的表述 - 以补充协议、附件、备注等形式规避主合同约束的条款 - 引用惯例行业标准但未明确具体内容的条款第三层是风险等级量化。方案里的逻辑是风险等级 影响程度 × 发生概率。高 直接影响合同核心目的/极可能触发中 可能导致损失/特定条件下触发低 表述瑕疵/极端情况触发。输出时要求模型给每个风险项打等级人工复核时优先看高。3.3 合规性校验法条关联与强制条款识别合规校验这块提示词设计的关键是法条关联映射。方案的做法是让模型先提取合同条款再关联对应法律条文最后判断是否合规。比如对外担保条款必须提示模型关联《公司法》第16条——担保是否经过股东会或董事会决议格式条款要关联《民法典》第497条。实操中我一般不建议让模型直接引用法条内容更稳妥的做法是只让模型输出该条款可能违反XX法关于XX的规定具体条文请人工复核避免模型伪造法条细节。强制条款识别是另一个重点。有些条款是法律强制规定合同里写不写都有效比如《民法典》第506条规定的造成对方人身损害的免责条款无效有些条款不写就有风险比如买卖合同中质量检验期间。提示词里用强制识别 缺失补全两个动作请完成两项工作 1. 识别并标出合同中的无效条款仅限法律明确规定无效的情形需输出对应法律依据 2. 检查是否存在法律规定应当具备但合同缺失的条款缺失的请补全建议文本3.4 多轮对话审查与错误修正机制一次审查搞不定所有问题方案里设计了多轮对话模式。第一轮出初稿第二轮针对风险条款追细节第三轮整体复核。多轮对话的提示词设计与单轮差别很大关键在于上下文状态管理——第二轮时模型要知道第一轮已经识别了哪些条款避免重复审查或漏审。我通常在提示词里增加前一轮已经识别出的风险条款{list} 请勿重复审查以上条款。 本轮聚焦{focused_question} 如有与前一轮结论冲突的判断请明确说明。错误修正机制在方案里占了独立一节核心是反馈-重生成-校验闭环。模型输出的修改建议如果不被律师认可把律师意见作为新指令喂回去让模型重新生成。这个设计很务实——AI出初稿、人类定终稿比让模型一步到位可靠得多。4. 起诉状与答辩状信息结构化提取和逻辑构建的提示词设计4.1 当事人信息提取用JSON Schema锁死输出格式起草起诉状第一步是把当事人信息从非结构化材料里抽出来。自然人有姓名、性别、出生年月日、民族、职业、住址、联系方式七要素法人有名称、住所地、法定代表人姓名职务、统一社会信用代码四要素。材料可能是聊天记录、合同扫描件、身份证照片转文字什么格式都有。方案里的思路是提示词定义字段模型负责抽取填充。这个场景的关键是字段必须封闭——让模型自由发挥就会抽出一堆没用的信息。我落地时用的是严格JSON输出约束extraction_prompt 请从以下材料中提取当事人信息严格按JSON格式输出不要添加任何额外文字 材料原文 {raw_material} 输出要求 1. 自然人字段name(姓名), gender(性别), birth_date(出生日期,格式YYYY-MM-DD), ethnicity(民族), occupation(职业), address(住址), contact(联系方式) 2. 法人字段org_name(名称), registered_address(住所地), legal_rep_name(法定代表人姓名), legal_rep_title(法定代表人职务), credit_code(统一社会信用代码) 3. 无法识别的字段填null不要推测 4. 如材料中出现多个主体按原告/被告/第三人分别输出 输出示例 {plaintiff: {name: 张三, gender: 男}, defendant: {org_name: 某科技有限公司}} 这里用了fill null和不要推测两条硬约束能显著降低模型编造信息的概率。逻辑说明一下按原告/被告/第三人分别输出这个指令省掉了后续数据结构化的大力气输出示例是给模型一个格式锚点比单纯写请按JSON格式输出有效得多。参数上这个场景的温度可以压到0.2以下信息抽取是确定性任务温度太高会在边界字段上乱猜。4.2 诉讼请求规范化给付之诉、确认之诉、形成之诉的分类处理诉讼请求的规范化程度直接影响立案效率。方案里把请求类型分成三类分别设计提示词给付之诉请求判令被告支付XX元、确认之诉请求确认合同无效、形成之诉请求撤销XX决议/解除合同。每类的表述规范完全不同混淆了模型就会生成请求依法确认被告支付货款这种四不像。多请求组合场景方案里有明确的排序逻辑先确认之诉、再给付之诉、最后形成之诉。比如一个案件既要求确认合同无效又要求返还已付款项表述顺序是1. 确认双方签订的XX合同无效2. 判令被告返还原告已付货款人民币XX元。这个顺序不能反——返还货款的前提是合同被确认无效逻辑上有先后依赖。提示词里的表述规范指令我一般这样写请将以下诉讼请求按标准法律文书表述规范改写 1. 明确请求类型给付/确认/形成 2. 金额统一用人民币数字用大写还是小写按司法机关要求 3. 多个请求按前提性请求在前、结果性请求在后排序 4. 不使用依法如有异议等模糊表述4.3 事实与理由逻辑梳理时间线和法律关系要件事实部分最忌讳平铺直叙。方案里的核心方法是让模型先按时间线提取关键事件再按法律关系的构成要件重组。以买卖合同纠纷为例构成要件是合同成立-履行-违约-损失事实描述就按这条线组织何时签订合同、原告履行了哪些义务、被告何时违约、原告因此产生多少损失。提示词设计上要给模型一个骨架请按以下逻辑结构梳理案件事实 第1层双方合同关系建立的时间与方式 第2层原告已履行的合同义务附证据编号 第3层被告违约的具体行为与时间节点 第4层原告的损失计算依据 在描述事实时仅陈述客观事实不加入主观评价。加了不加入主观评价之后输出质量会有明显提升。模型默认倾向写成被告恶意拖欠货款这属于定性评价不是事实陈述。法律文书里事实部分应该是被告自2025年3月起未再支付货款截至起诉日累计拖欠金额为XX元结论留给法院做。理由部分则相反要有法律推理逻辑。方案里给了不同案由的差异化策略比如劳动争议要突出劳动关系的认定是否有劳动合同、工资支付记录、社保缴纳记录侵权纠纷要按侵权行为-损害结果-因果关系-过错四要件展开。4.4 答辩状反驳逻辑三层结构与递进式提示词答辩状的提示词设计比起诉状更考验功力因为被告的立场是驳得针对原告的主张逐层拆招。方案里把反驳逻辑分成三层事实性反驳否认或修正原告主张的事实。提示词设计要点是让模型逐条对照原告的事实主张找事实层面的破绽——时间对不上、金额对不上、主体对不上。法律适用反驳主张原告援引的法律条款不适用或应当适用其他条款。比如原告主张适用《民法典》第577条追究违约责任被告可辩称合同尚未生效不构成违约。证据抗辩对证据的三性提出异议——合法性证据取得方式违法、关联性证据与待证事实无关、真实性证据系伪造或已篡改。这三层的提示词要分开设计最后合成一份答辩状。我常用的递进式策略是第一轮分别输出三层反驳的要点清单 - 事实层列出原告事实主张与证据的矛盾点 - 法律层列出原告法律依据的可辩点 - 证据层列出证据三性瑕疵 第二轮仅针对事实层展开详细论述生成该部分的完整表述 第三轮合并三层内容按答辩状的文书结构整理输出5. 避坑指南提示词工程在法律场景的五个高频翻车点5.1 法条张冠李戴现象生成的文书中出现不存在的法条编号或法条内容与编号对应不上——《民法典》第577条写成了违约方应当承担侵权责任。原因提示词要求模型引用相关法律条文但没限定引用范围。大模型在不确定时倾向编造听起来合理的条文法律条文这种高结构化内容最容易出现幻觉。解决提示词里明确加硬约束仅引用你确定100%存在的法律条文不确定的不要引用用相关规定替代。建议后台做法是单独维护一个法条库用RAG把真实法条检索出来喂给模型让模型基于检索结果做判断而不是靠记忆生成。5.2 同一模板多次输出格式漂移现象同一份提示词调用十次输出结构各不相同——有时结论在前分析在后有时先列风险再给建议有时用表格有时用列表。原因提示词描述了输出要求但没有给结构锚点。模型对清晰、结构化的理解是概率性的每次解码路径不同结构就漂移。解决除了在提示词中定义严格的输出顺序先风险清单、后整体结论还要配一个few-shot示例——给一段真实的输入输出对让模型照着示例结构走。如果对格式要求极其严格可以让模型先输出JSON再用代码转成文书格式格式的事不交给模型。5.3 长合同审查漏检后段条款现象一份80页的合同模型审查前半部分很仔细到后半部分开始敷衍输出的风险条款数量明显减少。原因上下文长度限制。注意力机制对长文本的中后段关注度天然衰减加上提示词里的任务指令占用了前部注意力后半部分成了注意力盲区。解决把长合同按章节切块处理每块单独审查最后合并风险清单。方案里提到的上下文压缩技巧也可以配合使用——先让模型对每块输出300字内的压缩摘要再基于摘要做全局风险关联分析。5.4 多轮对话逻辑漂移现象第一轮审查发现A条款有风险第三轮模型给出的修改建议与第一轮矛盾甚至无理由地认为A条款没问题。原因对话历史的状态管理缺失。法律场景的复杂逻辑关系不能靠模型的隐式记忆模型可能在中途忘记了自己之前给出的判断。解决每轮对话的提示词固定带上前轮已确认结论列表。我的一般做法是设计一个简单的状态对象在每轮调用时把之前确认的条款和判断注入提示词模型只负责增量分析不做全局重判。5.5 术语近义替换导致法律后果偏差现象合同审查中模型把应当承担连带责任的建议改成了可要求其承担补充赔偿责任看起来是优化表述实际改变了法律后果的性质。原因模型对法律术语的精确适用条件不敏感。连带责任和补充赔偿责任在构成要件、追偿路径上完全不同模型仅凭语义相似度做了替换。解决在提示词里嵌入术语锁定声明——以下术语的含义以中华人民共和国法律规定的标准含义为准不得随意替换连带责任、补充赔偿责任、按份责任、不真正连带责任。涉及关键术语时要求模型输出原始条款 修改建议两栏对照人工重点看栏间差异。6. 让模板体系跑起来集成策略、调用优化与效果验证模板多到100怎么组织才能不变成一团乱麻方案里给了三个方向的思路。第一是模板关联机制场景之间是有依赖的。起诉状的证据清单模板和法律意见书的法规检索模板底层共享同一套证据分类体系和法条映射关系。设计模板时把这些公共模块抽出来做内嵌引用避免一个场景改了、另一个场景没跟着同步。第二是调用效率优化。高频模板合同审查、起诉状起草做预加载低频模板按需加载同一批合同的审查请求做批量处理配合异步调用。模板本身可以序列化缓存避免每次请求都重新解析JSON Schema。这部分方案的第六十章讲了多级缓存架构实操中先从高频模板预加载 变量预编译两个动作做起效果最明显。第三是效果验证。光有模板不行得上线后持续验证。我的习惯是抽5%~10%的文书做人工复核重点盯三条指标格式合规率法院或客户退件率、事实错误率当事人姓名、金额、日期错误、修改成本律师修改生成文本的耗时。方案里提到的实测错误率低于3%是一个合理目标但前提是提示词加了一层人工复核的兜底阀——AI生成初稿律师负责终审这个流程不能省。这套方案真正解决的是从0到1的问题提示词怎么设计、模板怎么组织、场景怎么拆。文件里的60个章节覆盖了从数据处理到模型微调再到模板优化的全链路但最值钱的还是12大核心场景的100模板本身——它们相当于一份法律提示词工程的种子库拿到手之后按自己的业务场景改改变量、调调法条库就能产出一套可用的系统。我自己的习惯是每接到一个法律自动化项目先跑一遍这100模板里的相关场景确认输出质量后再动模型微调——多数时候提示词层面的调整就够用了不必走到训练那一步。做提示词工程越久越明白一个道理模型的能力边界在那里能不能用起来取决于你对场景的理解和对指令的精修。希望这份模板库能帮你少走几步弯路。本文还有配套的精品资源点击获取
![You Don‘t Know JS Yet（Objects Classes）：深入对象机制 —— 属性描述符、对象子类型与 `[[Prototype]]` 原型链](http://pic.xiahunao.cn/yaotu/You Don‘t Know JS Yet（Objects Classes）：深入对象机制 —— 属性描述符、对象子类型与 `[[Prototype]]` 原型链)
