简介这份PDF文档面向法律从业者、法律科技研究者及希望借助大模型提升文书效率的团队系统讲解如何用提示词工程驱动DeepSeek完成法律文书自动化。内容围绕合同审查、起诉状起草、答辩状生成、法律意见书等12大核心场景展开覆盖风险条款识别、条款合规校验、当事人信息结构化提取、诉讼请求规范化、证据清单关联匹配、反驳逻辑构建、法规检索关联等100余个高频模板并配有法律术语库交互设计与语义、逻辑、规范三层适配原理。资源为1个PDF文件共460页、60个大章节压缩包约13.33MB支持目录跳转与左侧书签大纲快速定位图表、目录等元素显示完整。已有109人学习。读者可据此掌握从架构设计到模板落地的完整方法直接复用高频提示词模板理解法律推理路径引导与输出标准化逻辑适合作为法律科技应用与提示词工程实践的案头参考。1. 法律文书自动化落地460 页 DeepSeek 提示词工程手册能解决什么上周帮一个做企业法务系统的朋友看合同审查模块他们团队用通用大模型跑了一版条款风险识别结果把应当承担连带责任识别成建议关注理由是语气不够强硬。这种翻车在通用提示词下几乎是必然的——法律文本的语义密度和术语精确度跟日常对话完全不是一个量级。这份 460 页的《DeepSeek 法律文书自动化方案》就是冲着这个断层来的它不讲大模型原理而是把提示词工程拆成 12 大核心场景、100 高频模板从合同审查、起诉状起草、答辩状生成到法律意见书、判决书摘要、调解书、律师函、证据目录、尽职调查、劳动仲裁、知识产权、婚姻家事、刑事、行政诉讼、执行文书再到提示词动态优化、数据标注、模型微调与蒸馏部署形成一条从写提示词到训模型的完整链路。适合两类人一是法务/律师团队里负责把 AI 接进业务流程的工程师二是做法律科技产品、需要快速搭出可用提示词库的开发者。它不承诺替代律师但能把重复劳动率从 70% 压下来前提是你得按它的结构去用而不是把模板复制粘贴就完事。2. 提示词工程在法律场景的适配原理为什么通用模板会翻车2.1 语义层适配法律术语的精确映射机制法律术语的坑在于同词不同义和同义不同效。比如不可抗力在合同场景下是免责条款的触发条件在侵权场景下可能涉及过错认定视为同意和默认同意在诉讼里的举证责任完全不同。通用提示词的做法是给模型一个角色设定然后让它根据合同内容识别风险模型只能靠预训练里的统计规律去猜猜错的概率极高。这份手册在语义层给出的方案是在提示词里显式嵌入术语定义和适用边界。不是让模型自己理解而是把术语库里的标准定义作为上下文注入。具体做法是维护一个术语映射表每个术语包含定义、同义词、反义词、使用场景、关联法条五个属性。提示词生成时根据当前场景从术语库拉取相关术语以结构化格式拼进指令。# 法律术语映射表结构示例简化版 legal_terms { 不可抗力: { definition: 不能预见、不能避免且不能克服的客观情况, synonyms: [ Force Majeure, 不可抗拒力], antonyms: [可抗力, 人为因素], scenarios: [合同免责, 侵权抗辩, 工期顺延], related_laws: [《民法典》第180条, 《民法典》第590条] }, 连带责任: { definition: 两个以上责任人对外不分份额地共同承担责任, synonyms: [连带赔偿责任, 共同连带责任], antonyms: [按份责任, 补充责任], scenarios: [担保, 合伙, 共同侵权], related_laws: [《民法典》第178条, 《民法典》第688条] } } def build_term_context(scenario, terms): 根据场景构建术语上下文注入提示词 matched [] for term, info in terms.items(): if scenario in info[scenarios]: matched.append(f{term}{info[definition]}关联法条{,.join(info[related_laws])}) return \n.join(matched) # 调用示例 context build_term_context(合同免责, legal_terms) print(context) # 输出不可抗力不能预见、不能避免且不能克服的客观情况关联法条《民法典》第180条,《民法典》第590条这段代码的逻辑是先定义术语的结构化属性再根据当前业务场景做匹配最后把匹配到的术语定义和法条拼成一段文本作为提示词的前置上下文。参数上scenarios字段决定了术语在哪些场景下被激活related_laws字段让模型在生成时能直接引用具体法条而不是泛泛地说根据相关法律规定。这一步做完模型对术语的理解就从统计关联变成了定义约束翻车概率会明显下降。2.2 逻辑层适配法律推理的路径引导设计法律推理不是自由发挥它有固定的路径大前提法条、小前提事实、结论裁判。通用提示词往往只给一个任务描述模型会跳过小前提直接给结论导致结论正确但论证缺失。手册里的做法是在提示词里显式写出推理路径要求模型按步骤输出。常见做法是设计三段式提示词结构第一段要求模型提取案件事实要素第二段要求匹配对应法条第三段才要求生成结论。每一段都设置校验点比如事实提取后要求模型标注已提取要素和缺失要素法条匹配后要求标注适用条款和排除条款。这样即使模型某一步出错也能在中间环节被发现而不是等到最后看结果才知道错了。2.3 规范层适配法律文书的格式与表述约束法律文书的格式是刚性的。起诉状必须有当事人信息、诉讼请求、事实与理由、证据清单判决书必须区分首部、事实、理由、裁判主文。通用提示词生成的文书经常形式合规但内容空泛比如诉讼请求写成请求法院依法判决这种表述在实务里会被直接退回。手册在规范层的方案是把格式要求拆成可校验的约束条件。以起诉状为例提示词里会明确列出当事人信息必须包含姓名/名称、住所地、联系方式、法定代表人法人诉讼请求必须包含请求事项、金额、依据事实与理由必须按时间线组织每个事实节点标注证据编号。这些约束不是写在提示词开头就完事而是作为输出格式的 schema 嵌入模型生成后还要过一遍校验器。# 起诉状输出格式校验 schema简化版 complaint_schema { type: object, required: [parties, claims, facts, evidence], properties: { parties: { type: array, items: { type: object, required: [name, address, contact], properties: { name: {type: string}, address: {type: string}, contact: {type: string}, legal_rep: {type: string} # 法人必填 } } }, claims: { type: array, items: { type: object, required: [item, amount, basis], properties: { item: {type: string}, amount: {type: number}, basis: {type: string} # 法律依据 } } }, facts: { type: array, items: { type: object, required: [date, event, evidence_id], properties: { date: {type: string, format: date}, event: {type: string}, evidence_id: {type: string} } } } } } def validate_complaint(output): 校验起诉状输出是否符合 schema errors [] for field in complaint_schema[required]: if field not in output: errors.append(f缺失必填字段{field}) # 进一步校验 claims 的 basis 是否为空 for claim in output.get(claims, []): if not claim.get(basis): errors.append(f诉讼请求「{claim.get(item)}」缺少法律依据) return errors # 调用示例 draft { parties: [{name: 张三, address: 某市某区, contact: 138xxxx}], claims: [{item: 支付货款, amount: 50000, basis: }], facts: [{date: 2025-01-01, event: 签订合同, evidence_id: E1}] } print(validate_complaint(draft)) # 输出[诉讼请求「支付货款」缺少法律依据]这段校验逻辑的作用是在模型生成之后、人工复核之前先跑一遍结构化校验把缺字段缺依据这类低级错误拦下来。参数上required定义了必填字段basis字段强制要求填写法律依据evidence_id强制要求事实与证据关联。这套 schema 可以直接用 JSON Schema 标准实现也可以手写校验函数关键是让格式约束变成可执行的检查而不是靠人眼去看。2.4 动态适配机制场景迁移与复杂度适配同一个合同审查任务买卖合同和股权转让合同的审查重点完全不同。买卖合同关注标的物、交付、验收、付款股权转让关注股权比例、转让价款、工商变更、债务承担。通用提示词做不到这种粒度手册的方案是建立场景特征提取器先判断当前输入属于哪个子场景再从模板库拉取对应的提示词模板。具体实现上场景特征提取可以用关键词匹配加语义相似度双路判断。关键词匹配负责快速筛选语义相似度负责兜底。比如输入里出现股权转让工商变更股东会决议就判定为股权转让场景如果关键词不明显就用 Sentence-BERT 算语义向量跟模板库里的场景描述做相似度比对取最高分。这一步的准确率直接决定后续提示词的质量手册里给的实测数据是场景识别准确率 92% 以上剩下的 8% 需要人工兜底。3. 合同审查场景落地从基础模板到 15 合同类型实例3.1 合同审查基础提示词模板的结构设计合同审查的提示词不能一上来就让模型找风险那样模型会漫无目的地扫一遍然后给一堆泛泛的建议。手册里的基础模板分四段第一段定义审查目标比如识别对甲方不利的条款第二段给出审查维度主体资格、标的物、价款、履行期限、违约责任、争议解决第三段注入相关法条和术语第四段规定输出格式风险等级、条款位置、风险描述、修改建议。# 合同审查基础提示词模板简化版 contract_review_template 你是一名合同审查专家请对以下合同进行审查。 审查目标{objective} 审查维度{dimensions} 相关法条{laws} 术语定义{terms} 合同内容 {contract_text} 请按以下格式输出审查结果 1. 风险等级高/中/低 2. 条款位置第X条 3. 风险描述具体说明风险点 4. 修改建议给出可操作的修改方案 # 参数填充示例 params { objective: 识别对甲方不利的条款, dimensions: 主体资格、标的物、价款、履行期限、违约责任、争议解决, laws: 《民法典》第509条、第577条、第584条, terms: 不可抗力不能预见、不能避免且不能克服的客观情况, contract_text: 此处填入合同全文 } prompt contract_review_template.format(**params) print(prompt[:200])这段模板的关键在于把审查这个模糊任务拆成了可执行的维度。objective决定了审查立场甲方还是乙方dimensions决定了审查覆盖面laws和terms提供了法律依据输出格式则强制模型给出可操作的建议而不是泛泛而谈。参数上objective必须明确立场否则模型会给出双方都有风险这种和稀泥的结论dimensions可以根据合同类型增减比如租赁合同要加租赁物状况租金支付。3.2 风险条款识别专项提示词设计基础模板跑通之后下一步是专项识别。手册里把风险条款分成三类显性风险直接违反强制性规定、隐性风险表述模糊导致解释空间、结构性风险条款之间冲突。显性风险最好识别提示词里直接列出禁止性条款清单即可隐性风险需要模型做语义分析比如合理期限这种表述提示词里要要求模型标注期限不明确建议量化结构性风险需要模型做跨条款比对提示词里要要求模型检查违约责任和争议解决是否一致。风险等级量化是另一个关键点。手册里的做法是给每个风险维度分配权重然后加权求和。比如主体资格权重 0.2价款权重 0.3违约责任权重 0.3争议解决权重 0.2。每个维度打分 1-5 分最后算总分映射到高/中/低三档。这套权重不是固定的可以根据客户类型调整——甲方强势的合同违约责任权重可以调高乙方弱势的合同价款权重可以调高。3.3 15 高频合同类型模板实例的复用方法手册里给了 15 种高频合同的审查模板买卖合同、借款合同、租赁合同、劳动合同、建设工程施工合同、股权转让合同、保密协议、服务合同、抵押合同、保证合同、软件开发合同、特许经营合同、知识产权许可合同、广告合同、物业管理合同。这些模板不是让你逐个复制而是让你理解场景特征如何映射到审查维度。以买卖合同和租赁合同为例买卖合同的审查重点是标的物描述、交付时间、验收标准、付款方式、违约责任租赁合同的审查重点是租赁物状况、租金支付、押金退还、维修责任、转租限制。两者的提示词结构一样但dimensions和laws不同。复用方法是先确定合同类型从模板库拉取对应的dimensions和laws再套用基础模板的结构。手册里每个模板都标注了必查项和选查项必查项是硬性要求选查项根据具体交易调整。提示合同类型判断不要依赖文件名很多合同文件名写的是合作协议实际内容是借款。判断依据应该是合同正文里的权利义务条款而不是标题。4. 起诉状与答辩状场景结构化提取与反驳逻辑的提示词实现4.1 当事人信息结构化提取的提示词模板起诉状的第一步是把当事人信息从非结构化输入里提取出来。输入可能是一段聊天记录、一份身份证照片的 OCR 结果、或者律师手写的笔记。手册里的做法是设计一个提取提示词要求模型输出 JSON 格式的当事人信息字段包括姓名/名称、住所地、联系方式、法定代表人法人、统一社会信用代码法人。# 当事人信息提取提示词 party_extraction_prompt 请从以下文本中提取当事人信息输出 JSON 格式。 文本 {input_text} 输出格式 { party_type: 自然人/法人/其他组织, name: 姓名或名称, address: 住所地, contact: 联系方式, legal_rep: 法定代表人法人必填, credit_code: 统一社会信用代码法人必填 } 注意 1. 如果文本中没有某项信息对应字段填 null 2. 自然人不需要填写 legal_rep 和 credit_code 3. 地址要精确到门牌号没有门牌号的填到区/县 # 调用示例 input_text 原告张三住某市某区某路123号电话138xxxx。被告某科技有限公司住所地某市某区某路456号法定代表人李四统一社会信用代码913xxxx。 prompt party_extraction_prompt.format(input_textinput_text) print(prompt)这段提示词的关键是输出格式的约束。party_type决定了后续字段的必填性legal_rep和credit_code只在法人场景下必填address的精度要求也写进了提示词。参数上input_text可以是任意长度的文本但建议先做一次清洗去掉无关的寒暄和重复内容否则模型可能把无关信息也提取进来。4.2 诉讼请求表述规范化提示词的核心模块诉讼请求的常见错误是表述模糊、金额不明确、依据缺失。手册里的规范化提示词分三个模块请求事项提取、金额校验、依据匹配。请求事项提取要求模型把要求对方还钱这种口语化表述转成请求判令被告支付货款人民币XX元金额校验要求模型检查金额是否与事实部分一致依据匹配要求模型标注每条请求对应的法条。# 诉讼请求规范化提示词 claim_normalization_prompt 请将以下诉讼请求规范化输出 JSON 格式。 原始请求 {raw_claims} 事实与理由 {facts} 输出格式 [ { item: 规范化后的请求事项, amount: 金额数字, basis: 法律依据, consistency: 与事实部分是否一致是/否 } ] 注意 1. 请求事项必须包含明确的动作和对象 2. 金额必须与事实部分一致不一致的标注出来 3. 法律依据必须引用具体法条 # 调用示例 raw_claims 1. 要求被告还钱 2. 要求被告承担诉讼费 facts 被告于2025年1月1日向原告借款50000元约定2025年6月1日还款到期未还。 prompt claim_normalization_prompt.format(raw_claimsraw_claims, factsfacts) print(prompt)这段提示词的作用是把口语化的请求转成法律文书的标准表述同时做一致性校验。consistency字段是关键的校验点如果模型标注否说明事实部分和请求部分有矛盾需要人工介入。参数上raw_claims可以是多条请求的列表facts是事实与理由部分的全文模型需要跨段落比对。4.3 答辩状反驳逻辑构建的提示词设计答辩状的核心是反驳反驳分三层事实性反驳对方说的事实不对、法律适用反驳对方引用的法条不对、证据抗辩对方的证据不足以支撑主张。手册里的提示词要求模型按这三层分别输出每层都要标注反驳依据。事实性反驳的提示词要求模型逐条比对起诉状里的事实和答辩人提供的事实找出矛盾点法律适用反驳要求模型检查起诉状引用的法条是否适用于本案案由证据抗辩要求模型检查对方的证据是否满足真实性、合法性、关联性三性要求。这三层不是孤立的提示词里要要求模型做交叉校验比如事实性反驳成立的话法律适用反驳可以简化。4.4 10 典型纠纷答辩模板的差异化策略手册里给了 11 种典型纠纷的答辩模板买卖合同纠纷、民间借贷纠纷、劳动争议纠纷、租赁合同纠纷、交通事故责任纠纷、物业服务合同纠纷、知识产权侵权纠纷、医疗损害责任纠纷、产品责任纠纷、离婚纠纷、建设工程施工合同纠纷。这些模板的差异主要体现在反驳重点上。以民间借贷纠纷和劳动争议纠纷为例民间借贷的反驳重点是借贷关系是否成立利息是否超过法定上限是否已过诉讼时效劳动争议的反驳重点是劳动关系是否成立仲裁时效是否已过解除程序是否合法。提示词的结构一样但rebuttal_dimensions不同。复用方法是先确定纠纷类型从模板库拉取对应的反驳维度再套用三层反驳结构。注意答辩状的反驳逻辑不要写成对方说的都不对那样在法庭上没有说服力。每一层反驳都要有具体依据事实性反驳要有证据法律适用反驳要有法条证据抗辩要有三性分析。5. 法律意见书与判决书摘要问题拆解与类案比对的提示词工程5.1 法律问题拆解提示词的核心目标与设计原则法律意见书的第一步是把客户的问题拆成可分析的法律问题。客户的问题往往是复合型的比如我们公司想跟另一家公司合作开发一个软件但担心知识产权归属问题另外如果合作方中途退出怎么办。这个问题里包含两个子问题知识产权归属、合作方退出机制。手册里的拆解提示词要求模型先识别问题类型合同、侵权、劳动、知识产权等再拆解成子问题最后按优先级排序。# 法律问题拆解提示词 issue_decomposition_prompt 请将以下法律问题拆解为子问题输出 JSON 格式。 原始问题 {raw_question} 输出格式 { issue_type: 问题类型, sub_issues: [ { id: 子问题编号, description: 子问题描述, priority: 高/中/低, related_laws: [相关法条] } ] } 注意 1. 子问题必须是可以独立分析的法律问题 2. 优先级根据对客户利益的影响程度判断 3. 相关法条要具体到条款 # 调用示例 raw_question 我们公司想跟另一家公司合作开发一个软件但担心知识产权归属问题另外如果合作方中途退出怎么办 prompt issue_decomposition_prompt.format(raw_questionraw_question) print(prompt)这段提示词的关键是可独立分析这个约束。很多模型会把一个问题拆成一堆互相重叠的子问题导致后续分析重复。priority字段帮助客户聚焦最重要的问题related_laws字段为后续的法条检索提供入口。参数上raw_question可以是任意长度的自然语言描述但建议先做一次口语化转书面语的预处理。5.2 法规检索关联提示词的多层级设计法律意见书的结论必须有法条支撑但法条检索不是简单的关键词匹配。同一个问题可能涉及法律、行政法规、司法解释、地方性法规多个层级效力级别不同适用顺序也不同。手册里的检索提示词要求模型按法律→行政法规→司法解释→地方性法规的顺序检索并标注每一条的效力级别和适用范围。多层级法规关联的提示词设计要点是先确定问题涉及的法律部门民法、刑法、行政法等再在该部门下检索具体法条最后检查是否有特别法优于一般法的情况。比如合同纠纷优先适用《民法典》合同编但如果涉及消费者权益还要看《消费者权益保护法》是否有特别规定。5.3 判决书摘要与类案比对的提示词模板判决书摘要的核心是提取裁判要旨类案比对的核心是找相似案例。手册里的做法是先用提示词提取判决书的核心要素案由、当事人、裁判结果、裁判理由、法律依据再用这些要素去案例库做相似度检索最后用提示词做类案比对分析。类案比对的提示词要求模型从五个维度做比对案件事实相似度、争议焦点相似度、法律适用相似度、裁判结果相似度、裁判逻辑相似度。每个维度打分 1-5 分最后算加权总分。相似度高的案例可以作为参考但提示词里要明确要求模型标注参考案例的裁判结果不构成对本案的法律意见。# 类案比对提示词 case_comparison_prompt 请对以下两个案件进行比对分析输出 JSON 格式。 本案 {current_case} 参考案例 {reference_case} 输出格式 { dimensions: { fact_similarity: 1-5, issue_similarity: 1-5, law_similarity: 1-5, result_similarity: 1-5, logic_similarity: 1-5 }, total_score: 加权总分, analysis: 比对分析说明, disclaimer: 参考案例的裁判结果不构成对本案的法律意见 } 注意 1. 每个维度的评分要有具体依据 2. 总分低于3分的案例不建议作为主要参考 3. 必须输出免责声明 # 调用示例 current_case 本案判决书摘要 reference_case 参考案例判决书摘要 prompt case_comparison_prompt.format(current_casecurrent_case, reference_casereference_case) print(prompt)这段提示词的作用是把类案比对从感觉像变成可量化。dimensions字段强制模型从五个维度分别打分避免笼统地说这个案例很像。disclaimer字段是合规要求法律意见书里引用参考案例必须声明不构成法律意见。参数上current_case和reference_case都应该是结构化的判决书摘要而不是全文否则提示词会超长。6. 避坑与排查提示词工程在法律场景的 5 个血泪教训6.1 现象模型把应当识别成建议原因通用提示词没有注入法律术语的强制性等级应当必须可以建议在模型眼里都是情态动词没有效力差异。解决在提示词里显式定义情态动词的效力等级。应当和必须标记为强制性可以标记为授权性建议标记为倡导性。输出时要求模型标注每个条款的效力等级强制性和授权性条款要重点审查。6.2 现象合同审查结果里出现根据相关法律规定这种空话原因提示词没有要求模型引用具体法条模型就用了最安全的表述。解决在输出格式里强制要求basis字段并且校验该字段是否包含第X条这种具体引用。如果模型输出根据相关法律规定校验器直接报错要求重新生成。6.3 现象多轮对话到第 5 轮之后模型开始忘记前面的约束原因上下文窗口有限前面的提示词被截断了。解决手册里的上下文管理模块会在对话长度接近上限时自动压缩把前面的核心约束提炼成短句重新注入。具体做法是维护一个约束清单每轮对话都把清单拼在提示词末尾而不是依赖模型自己记住。6.4 现象起诉状里的金额和事实部分的金额对不上原因模型在生成诉讼请求时没有回查事实部分或者事实部分本身有多个金额模型选错了。解决在提示词里要求模型做一致性校验输出consistency字段。校验逻辑是提取事实部分的所有金额跟诉讼请求的金额做比对不一致的标注出来。这一步不能靠模型自觉必须写成校验规则。6.5 现象类案比对结果里引用了不存在的案例原因模型在生成时幻觉了一个案例或者把案例编号记错了。解决类案比对必须基于真实的案例库检索结果不能靠模型生成。提示词里要求模型只比对检索到的案例并且输出案例编号供人工复核。如果模型输出了案例库里没有的编号校验器直接拦截。提示法律场景的提示词工程校验环节比生成环节更重要。生成错了可以改校验漏了就是事故。7. 提示词模板集成与调用效率优化从单模板到模板库的进阶单模板跑通之后下一步是把 100 模板集成到一个可调用的模板库里。手册里给的集成架构分三层模板存储层、模板调度层、模板执行层。存储层用 JSON Schema 定义模板结构调度层根据场景特征选择模板执行层负责变量填充和输出校验。模板调用的效率瓶颈通常在两个方面一是模板加载慢二是多模板并发调用时资源竞争。手册里的优化方案是预加载加热加载高频模板在服务启动时预加载到内存低频模板按需加载热加载机制支持不重启服务更新模板。缓存架构分三级本地缓存进程内、分布式缓存Redis、持久化存储数据库。本地缓存存最高频的模板分布式缓存存中频模板数据库存全量模板。# 模板调度器简化实现 import json from functools import lru_cache class TemplateScheduler: def __init__(self, template_dir): self.template_dir template_dir self.local_cache {} lru_cache(maxsize128) def load_template(self, template_id): 加载模板带 LRU 缓存 path f{self.template_dir}/{template_id}.json with open(path, r, encodingutf-8) as f: return json.load(f) def select_template(self, scenario_features): 根据场景特征选择模板 # 关键词匹配 语义相似度双路判断 template_id self._match_by_keywords(scenario_features) if not template_id: template_id self._match_by_semantic(scenario_features) return self.load_template(template_id) def _match_by_keywords(self, features): 关键词匹配 keyword_map { 买卖合同: contract_review_sales, 租赁合同: contract_review_lease, 股权转让: contract_review_equity, 起诉状: complaint_draft, 答辩状: defense_draft } for keyword, template_id in keyword_map.items(): if keyword in features: return template_id return None def _match_by_semantic(self, features): 语义相似度匹配简化示意 # 实际实现需要加载 Sentence-BERT 模型 # 这里返回默认模板 return contract_review_base # 调用示例 scheduler TemplateScheduler(./templates) template scheduler.select_template(买卖合同审查) print(template.get(template_id, unknown))这段调度器的逻辑是先用关键词匹配快速筛选匹配不到再用语义相似度兜底。lru_cache装饰器实现了本地缓存高频模板只加载一次。参数上template_dir是模板存储目录scenario_features是场景特征字符串可以是用户输入的关键词也可以是上游模块提取的特征。实际部署时_match_by_semantic需要接入向量数据库把场景特征转成向量后做相似度检索。模板压缩是另一个优化点。手册里提到提示词压缩率可达 30%做法是去掉冗余表述、合并重复约束、用缩写替代长术语。但压缩不能牺牲语义完整性压缩后的提示词要过一遍校验器确保关键约束没有丢失。我一般会保留两个版本完整版用于调试压缩版用于生产。异步调用和批量处理是应对高并发的关键。合同审查这种任务单份合同的处理时间可能在 10-30 秒如果同步调用并发量上不去。手册里的方案是用消息队列做异步处理前端提交任务后立即返回任务 ID后端处理完成后回调通知。批量处理则是一次提交多份合同后端并行处理最后合并结果。从那以后我每次集成新模板都强制走一遍关键词匹配→语义兜底→输出校验→人工抽检的流程宁可多花十分钟也不让一个未校验的模板进生产。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek法律文书自动化：460页提示词工程手册与100+模板实战
简介这份PDF文档面向法律从业者、法律科技研究者及希望借助大模型提升文书效率的团队系统讲解如何用提示词工程驱动DeepSeek完成法律文书自动化。内容围绕合同审查、起诉状起草、答辩状生成、法律意见书等12大核心场景展开覆盖风险条款识别、条款合规校验、当事人信息结构化提取、诉讼请求规范化、证据清单关联匹配、反驳逻辑构建、法规检索关联等100余个高频模板并配有法律术语库交互设计与语义、逻辑、规范三层适配原理。资源为1个PDF文件共460页、60个大章节压缩包约13.33MB支持目录跳转与左侧书签大纲快速定位图表、目录等元素显示完整。已有109人学习。读者可据此掌握从架构设计到模板落地的完整方法直接复用高频提示词模板理解法律推理路径引导与输出标准化逻辑适合作为法律科技应用与提示词工程实践的案头参考。1. 法律文书自动化落地460 页 DeepSeek 提示词工程手册能解决什么上周帮一个做企业法务系统的朋友看合同审查模块他们团队用通用大模型跑了一版条款风险识别结果把应当承担连带责任识别成建议关注理由是语气不够强硬。这种翻车在通用提示词下几乎是必然的——法律文本的语义密度和术语精确度跟日常对话完全不是一个量级。这份 460 页的《DeepSeek 法律文书自动化方案》就是冲着这个断层来的它不讲大模型原理而是把提示词工程拆成 12 大核心场景、100 高频模板从合同审查、起诉状起草、答辩状生成到法律意见书、判决书摘要、调解书、律师函、证据目录、尽职调查、劳动仲裁、知识产权、婚姻家事、刑事、行政诉讼、执行文书再到提示词动态优化、数据标注、模型微调与蒸馏部署形成一条从写提示词到训模型的完整链路。适合两类人一是法务/律师团队里负责把 AI 接进业务流程的工程师二是做法律科技产品、需要快速搭出可用提示词库的开发者。它不承诺替代律师但能把重复劳动率从 70% 压下来前提是你得按它的结构去用而不是把模板复制粘贴就完事。2. 提示词工程在法律场景的适配原理为什么通用模板会翻车2.1 语义层适配法律术语的精确映射机制法律术语的坑在于同词不同义和同义不同效。比如不可抗力在合同场景下是免责条款的触发条件在侵权场景下可能涉及过错认定视为同意和默认同意在诉讼里的举证责任完全不同。通用提示词的做法是给模型一个角色设定然后让它根据合同内容识别风险模型只能靠预训练里的统计规律去猜猜错的概率极高。这份手册在语义层给出的方案是在提示词里显式嵌入术语定义和适用边界。不是让模型自己理解而是把术语库里的标准定义作为上下文注入。具体做法是维护一个术语映射表每个术语包含定义、同义词、反义词、使用场景、关联法条五个属性。提示词生成时根据当前场景从术语库拉取相关术语以结构化格式拼进指令。# 法律术语映射表结构示例简化版 legal_terms { 不可抗力: { definition: 不能预见、不能避免且不能克服的客观情况, synonyms: [ Force Majeure, 不可抗拒力], antonyms: [可抗力, 人为因素], scenarios: [合同免责, 侵权抗辩, 工期顺延], related_laws: [《民法典》第180条, 《民法典》第590条] }, 连带责任: { definition: 两个以上责任人对外不分份额地共同承担责任, synonyms: [连带赔偿责任, 共同连带责任], antonyms: [按份责任, 补充责任], scenarios: [担保, 合伙, 共同侵权], related_laws: [《民法典》第178条, 《民法典》第688条] } } def build_term_context(scenario, terms): 根据场景构建术语上下文注入提示词 matched [] for term, info in terms.items(): if scenario in info[scenarios]: matched.append(f{term}{info[definition]}关联法条{,.join(info[related_laws])}) return \n.join(matched) # 调用示例 context build_term_context(合同免责, legal_terms) print(context) # 输出不可抗力不能预见、不能避免且不能克服的客观情况关联法条《民法典》第180条,《民法典》第590条这段代码的逻辑是先定义术语的结构化属性再根据当前业务场景做匹配最后把匹配到的术语定义和法条拼成一段文本作为提示词的前置上下文。参数上scenarios字段决定了术语在哪些场景下被激活related_laws字段让模型在生成时能直接引用具体法条而不是泛泛地说根据相关法律规定。这一步做完模型对术语的理解就从统计关联变成了定义约束翻车概率会明显下降。2.2 逻辑层适配法律推理的路径引导设计法律推理不是自由发挥它有固定的路径大前提法条、小前提事实、结论裁判。通用提示词往往只给一个任务描述模型会跳过小前提直接给结论导致结论正确但论证缺失。手册里的做法是在提示词里显式写出推理路径要求模型按步骤输出。常见做法是设计三段式提示词结构第一段要求模型提取案件事实要素第二段要求匹配对应法条第三段才要求生成结论。每一段都设置校验点比如事实提取后要求模型标注已提取要素和缺失要素法条匹配后要求标注适用条款和排除条款。这样即使模型某一步出错也能在中间环节被发现而不是等到最后看结果才知道错了。2.3 规范层适配法律文书的格式与表述约束法律文书的格式是刚性的。起诉状必须有当事人信息、诉讼请求、事实与理由、证据清单判决书必须区分首部、事实、理由、裁判主文。通用提示词生成的文书经常形式合规但内容空泛比如诉讼请求写成请求法院依法判决这种表述在实务里会被直接退回。手册在规范层的方案是把格式要求拆成可校验的约束条件。以起诉状为例提示词里会明确列出当事人信息必须包含姓名/名称、住所地、联系方式、法定代表人法人诉讼请求必须包含请求事项、金额、依据事实与理由必须按时间线组织每个事实节点标注证据编号。这些约束不是写在提示词开头就完事而是作为输出格式的 schema 嵌入模型生成后还要过一遍校验器。# 起诉状输出格式校验 schema简化版 complaint_schema { type: object, required: [parties, claims, facts, evidence], properties: { parties: { type: array, items: { type: object, required: [name, address, contact], properties: { name: {type: string}, address: {type: string}, contact: {type: string}, legal_rep: {type: string} # 法人必填 } } }, claims: { type: array, items: { type: object, required: [item, amount, basis], properties: { item: {type: string}, amount: {type: number}, basis: {type: string} # 法律依据 } } }, facts: { type: array, items: { type: object, required: [date, event, evidence_id], properties: { date: {type: string, format: date}, event: {type: string}, evidence_id: {type: string} } } } } } def validate_complaint(output): 校验起诉状输出是否符合 schema errors [] for field in complaint_schema[required]: if field not in output: errors.append(f缺失必填字段{field}) # 进一步校验 claims 的 basis 是否为空 for claim in output.get(claims, []): if not claim.get(basis): errors.append(f诉讼请求「{claim.get(item)}」缺少法律依据) return errors # 调用示例 draft { parties: [{name: 张三, address: 某市某区, contact: 138xxxx}], claims: [{item: 支付货款, amount: 50000, basis: }], facts: [{date: 2025-01-01, event: 签订合同, evidence_id: E1}] } print(validate_complaint(draft)) # 输出[诉讼请求「支付货款」缺少法律依据]这段校验逻辑的作用是在模型生成之后、人工复核之前先跑一遍结构化校验把缺字段缺依据这类低级错误拦下来。参数上required定义了必填字段basis字段强制要求填写法律依据evidence_id强制要求事实与证据关联。这套 schema 可以直接用 JSON Schema 标准实现也可以手写校验函数关键是让格式约束变成可执行的检查而不是靠人眼去看。2.4 动态适配机制场景迁移与复杂度适配同一个合同审查任务买卖合同和股权转让合同的审查重点完全不同。买卖合同关注标的物、交付、验收、付款股权转让关注股权比例、转让价款、工商变更、债务承担。通用提示词做不到这种粒度手册的方案是建立场景特征提取器先判断当前输入属于哪个子场景再从模板库拉取对应的提示词模板。具体实现上场景特征提取可以用关键词匹配加语义相似度双路判断。关键词匹配负责快速筛选语义相似度负责兜底。比如输入里出现股权转让工商变更股东会决议就判定为股权转让场景如果关键词不明显就用 Sentence-BERT 算语义向量跟模板库里的场景描述做相似度比对取最高分。这一步的准确率直接决定后续提示词的质量手册里给的实测数据是场景识别准确率 92% 以上剩下的 8% 需要人工兜底。3. 合同审查场景落地从基础模板到 15 合同类型实例3.1 合同审查基础提示词模板的结构设计合同审查的提示词不能一上来就让模型找风险那样模型会漫无目的地扫一遍然后给一堆泛泛的建议。手册里的基础模板分四段第一段定义审查目标比如识别对甲方不利的条款第二段给出审查维度主体资格、标的物、价款、履行期限、违约责任、争议解决第三段注入相关法条和术语第四段规定输出格式风险等级、条款位置、风险描述、修改建议。# 合同审查基础提示词模板简化版 contract_review_template 你是一名合同审查专家请对以下合同进行审查。 审查目标{objective} 审查维度{dimensions} 相关法条{laws} 术语定义{terms} 合同内容 {contract_text} 请按以下格式输出审查结果 1. 风险等级高/中/低 2. 条款位置第X条 3. 风险描述具体说明风险点 4. 修改建议给出可操作的修改方案 # 参数填充示例 params { objective: 识别对甲方不利的条款, dimensions: 主体资格、标的物、价款、履行期限、违约责任、争议解决, laws: 《民法典》第509条、第577条、第584条, terms: 不可抗力不能预见、不能避免且不能克服的客观情况, contract_text: 此处填入合同全文 } prompt contract_review_template.format(**params) print(prompt[:200])这段模板的关键在于把审查这个模糊任务拆成了可执行的维度。objective决定了审查立场甲方还是乙方dimensions决定了审查覆盖面laws和terms提供了法律依据输出格式则强制模型给出可操作的建议而不是泛泛而谈。参数上objective必须明确立场否则模型会给出双方都有风险这种和稀泥的结论dimensions可以根据合同类型增减比如租赁合同要加租赁物状况租金支付。3.2 风险条款识别专项提示词设计基础模板跑通之后下一步是专项识别。手册里把风险条款分成三类显性风险直接违反强制性规定、隐性风险表述模糊导致解释空间、结构性风险条款之间冲突。显性风险最好识别提示词里直接列出禁止性条款清单即可隐性风险需要模型做语义分析比如合理期限这种表述提示词里要要求模型标注期限不明确建议量化结构性风险需要模型做跨条款比对提示词里要要求模型检查违约责任和争议解决是否一致。风险等级量化是另一个关键点。手册里的做法是给每个风险维度分配权重然后加权求和。比如主体资格权重 0.2价款权重 0.3违约责任权重 0.3争议解决权重 0.2。每个维度打分 1-5 分最后算总分映射到高/中/低三档。这套权重不是固定的可以根据客户类型调整——甲方强势的合同违约责任权重可以调高乙方弱势的合同价款权重可以调高。3.3 15 高频合同类型模板实例的复用方法手册里给了 15 种高频合同的审查模板买卖合同、借款合同、租赁合同、劳动合同、建设工程施工合同、股权转让合同、保密协议、服务合同、抵押合同、保证合同、软件开发合同、特许经营合同、知识产权许可合同、广告合同、物业管理合同。这些模板不是让你逐个复制而是让你理解场景特征如何映射到审查维度。以买卖合同和租赁合同为例买卖合同的审查重点是标的物描述、交付时间、验收标准、付款方式、违约责任租赁合同的审查重点是租赁物状况、租金支付、押金退还、维修责任、转租限制。两者的提示词结构一样但dimensions和laws不同。复用方法是先确定合同类型从模板库拉取对应的dimensions和laws再套用基础模板的结构。手册里每个模板都标注了必查项和选查项必查项是硬性要求选查项根据具体交易调整。提示合同类型判断不要依赖文件名很多合同文件名写的是合作协议实际内容是借款。判断依据应该是合同正文里的权利义务条款而不是标题。4. 起诉状与答辩状场景结构化提取与反驳逻辑的提示词实现4.1 当事人信息结构化提取的提示词模板起诉状的第一步是把当事人信息从非结构化输入里提取出来。输入可能是一段聊天记录、一份身份证照片的 OCR 结果、或者律师手写的笔记。手册里的做法是设计一个提取提示词要求模型输出 JSON 格式的当事人信息字段包括姓名/名称、住所地、联系方式、法定代表人法人、统一社会信用代码法人。# 当事人信息提取提示词 party_extraction_prompt 请从以下文本中提取当事人信息输出 JSON 格式。 文本 {input_text} 输出格式 { party_type: 自然人/法人/其他组织, name: 姓名或名称, address: 住所地, contact: 联系方式, legal_rep: 法定代表人法人必填, credit_code: 统一社会信用代码法人必填 } 注意 1. 如果文本中没有某项信息对应字段填 null 2. 自然人不需要填写 legal_rep 和 credit_code 3. 地址要精确到门牌号没有门牌号的填到区/县 # 调用示例 input_text 原告张三住某市某区某路123号电话138xxxx。被告某科技有限公司住所地某市某区某路456号法定代表人李四统一社会信用代码913xxxx。 prompt party_extraction_prompt.format(input_textinput_text) print(prompt)这段提示词的关键是输出格式的约束。party_type决定了后续字段的必填性legal_rep和credit_code只在法人场景下必填address的精度要求也写进了提示词。参数上input_text可以是任意长度的文本但建议先做一次清洗去掉无关的寒暄和重复内容否则模型可能把无关信息也提取进来。4.2 诉讼请求表述规范化提示词的核心模块诉讼请求的常见错误是表述模糊、金额不明确、依据缺失。手册里的规范化提示词分三个模块请求事项提取、金额校验、依据匹配。请求事项提取要求模型把要求对方还钱这种口语化表述转成请求判令被告支付货款人民币XX元金额校验要求模型检查金额是否与事实部分一致依据匹配要求模型标注每条请求对应的法条。# 诉讼请求规范化提示词 claim_normalization_prompt 请将以下诉讼请求规范化输出 JSON 格式。 原始请求 {raw_claims} 事实与理由 {facts} 输出格式 [ { item: 规范化后的请求事项, amount: 金额数字, basis: 法律依据, consistency: 与事实部分是否一致是/否 } ] 注意 1. 请求事项必须包含明确的动作和对象 2. 金额必须与事实部分一致不一致的标注出来 3. 法律依据必须引用具体法条 # 调用示例 raw_claims 1. 要求被告还钱 2. 要求被告承担诉讼费 facts 被告于2025年1月1日向原告借款50000元约定2025年6月1日还款到期未还。 prompt claim_normalization_prompt.format(raw_claimsraw_claims, factsfacts) print(prompt)这段提示词的作用是把口语化的请求转成法律文书的标准表述同时做一致性校验。consistency字段是关键的校验点如果模型标注否说明事实部分和请求部分有矛盾需要人工介入。参数上raw_claims可以是多条请求的列表facts是事实与理由部分的全文模型需要跨段落比对。4.3 答辩状反驳逻辑构建的提示词设计答辩状的核心是反驳反驳分三层事实性反驳对方说的事实不对、法律适用反驳对方引用的法条不对、证据抗辩对方的证据不足以支撑主张。手册里的提示词要求模型按这三层分别输出每层都要标注反驳依据。事实性反驳的提示词要求模型逐条比对起诉状里的事实和答辩人提供的事实找出矛盾点法律适用反驳要求模型检查起诉状引用的法条是否适用于本案案由证据抗辩要求模型检查对方的证据是否满足真实性、合法性、关联性三性要求。这三层不是孤立的提示词里要要求模型做交叉校验比如事实性反驳成立的话法律适用反驳可以简化。4.4 10 典型纠纷答辩模板的差异化策略手册里给了 11 种典型纠纷的答辩模板买卖合同纠纷、民间借贷纠纷、劳动争议纠纷、租赁合同纠纷、交通事故责任纠纷、物业服务合同纠纷、知识产权侵权纠纷、医疗损害责任纠纷、产品责任纠纷、离婚纠纷、建设工程施工合同纠纷。这些模板的差异主要体现在反驳重点上。以民间借贷纠纷和劳动争议纠纷为例民间借贷的反驳重点是借贷关系是否成立利息是否超过法定上限是否已过诉讼时效劳动争议的反驳重点是劳动关系是否成立仲裁时效是否已过解除程序是否合法。提示词的结构一样但rebuttal_dimensions不同。复用方法是先确定纠纷类型从模板库拉取对应的反驳维度再套用三层反驳结构。注意答辩状的反驳逻辑不要写成对方说的都不对那样在法庭上没有说服力。每一层反驳都要有具体依据事实性反驳要有证据法律适用反驳要有法条证据抗辩要有三性分析。5. 法律意见书与判决书摘要问题拆解与类案比对的提示词工程5.1 法律问题拆解提示词的核心目标与设计原则法律意见书的第一步是把客户的问题拆成可分析的法律问题。客户的问题往往是复合型的比如我们公司想跟另一家公司合作开发一个软件但担心知识产权归属问题另外如果合作方中途退出怎么办。这个问题里包含两个子问题知识产权归属、合作方退出机制。手册里的拆解提示词要求模型先识别问题类型合同、侵权、劳动、知识产权等再拆解成子问题最后按优先级排序。# 法律问题拆解提示词 issue_decomposition_prompt 请将以下法律问题拆解为子问题输出 JSON 格式。 原始问题 {raw_question} 输出格式 { issue_type: 问题类型, sub_issues: [ { id: 子问题编号, description: 子问题描述, priority: 高/中/低, related_laws: [相关法条] } ] } 注意 1. 子问题必须是可以独立分析的法律问题 2. 优先级根据对客户利益的影响程度判断 3. 相关法条要具体到条款 # 调用示例 raw_question 我们公司想跟另一家公司合作开发一个软件但担心知识产权归属问题另外如果合作方中途退出怎么办 prompt issue_decomposition_prompt.format(raw_questionraw_question) print(prompt)这段提示词的关键是可独立分析这个约束。很多模型会把一个问题拆成一堆互相重叠的子问题导致后续分析重复。priority字段帮助客户聚焦最重要的问题related_laws字段为后续的法条检索提供入口。参数上raw_question可以是任意长度的自然语言描述但建议先做一次口语化转书面语的预处理。5.2 法规检索关联提示词的多层级设计法律意见书的结论必须有法条支撑但法条检索不是简单的关键词匹配。同一个问题可能涉及法律、行政法规、司法解释、地方性法规多个层级效力级别不同适用顺序也不同。手册里的检索提示词要求模型按法律→行政法规→司法解释→地方性法规的顺序检索并标注每一条的效力级别和适用范围。多层级法规关联的提示词设计要点是先确定问题涉及的法律部门民法、刑法、行政法等再在该部门下检索具体法条最后检查是否有特别法优于一般法的情况。比如合同纠纷优先适用《民法典》合同编但如果涉及消费者权益还要看《消费者权益保护法》是否有特别规定。5.3 判决书摘要与类案比对的提示词模板判决书摘要的核心是提取裁判要旨类案比对的核心是找相似案例。手册里的做法是先用提示词提取判决书的核心要素案由、当事人、裁判结果、裁判理由、法律依据再用这些要素去案例库做相似度检索最后用提示词做类案比对分析。类案比对的提示词要求模型从五个维度做比对案件事实相似度、争议焦点相似度、法律适用相似度、裁判结果相似度、裁判逻辑相似度。每个维度打分 1-5 分最后算加权总分。相似度高的案例可以作为参考但提示词里要明确要求模型标注参考案例的裁判结果不构成对本案的法律意见。# 类案比对提示词 case_comparison_prompt 请对以下两个案件进行比对分析输出 JSON 格式。 本案 {current_case} 参考案例 {reference_case} 输出格式 { dimensions: { fact_similarity: 1-5, issue_similarity: 1-5, law_similarity: 1-5, result_similarity: 1-5, logic_similarity: 1-5 }, total_score: 加权总分, analysis: 比对分析说明, disclaimer: 参考案例的裁判结果不构成对本案的法律意见 } 注意 1. 每个维度的评分要有具体依据 2. 总分低于3分的案例不建议作为主要参考 3. 必须输出免责声明 # 调用示例 current_case 本案判决书摘要 reference_case 参考案例判决书摘要 prompt case_comparison_prompt.format(current_casecurrent_case, reference_casereference_case) print(prompt)这段提示词的作用是把类案比对从感觉像变成可量化。dimensions字段强制模型从五个维度分别打分避免笼统地说这个案例很像。disclaimer字段是合规要求法律意见书里引用参考案例必须声明不构成法律意见。参数上current_case和reference_case都应该是结构化的判决书摘要而不是全文否则提示词会超长。6. 避坑与排查提示词工程在法律场景的 5 个血泪教训6.1 现象模型把应当识别成建议原因通用提示词没有注入法律术语的强制性等级应当必须可以建议在模型眼里都是情态动词没有效力差异。解决在提示词里显式定义情态动词的效力等级。应当和必须标记为强制性可以标记为授权性建议标记为倡导性。输出时要求模型标注每个条款的效力等级强制性和授权性条款要重点审查。6.2 现象合同审查结果里出现根据相关法律规定这种空话原因提示词没有要求模型引用具体法条模型就用了最安全的表述。解决在输出格式里强制要求basis字段并且校验该字段是否包含第X条这种具体引用。如果模型输出根据相关法律规定校验器直接报错要求重新生成。6.3 现象多轮对话到第 5 轮之后模型开始忘记前面的约束原因上下文窗口有限前面的提示词被截断了。解决手册里的上下文管理模块会在对话长度接近上限时自动压缩把前面的核心约束提炼成短句重新注入。具体做法是维护一个约束清单每轮对话都把清单拼在提示词末尾而不是依赖模型自己记住。6.4 现象起诉状里的金额和事实部分的金额对不上原因模型在生成诉讼请求时没有回查事实部分或者事实部分本身有多个金额模型选错了。解决在提示词里要求模型做一致性校验输出consistency字段。校验逻辑是提取事实部分的所有金额跟诉讼请求的金额做比对不一致的标注出来。这一步不能靠模型自觉必须写成校验规则。6.5 现象类案比对结果里引用了不存在的案例原因模型在生成时幻觉了一个案例或者把案例编号记错了。解决类案比对必须基于真实的案例库检索结果不能靠模型生成。提示词里要求模型只比对检索到的案例并且输出案例编号供人工复核。如果模型输出了案例库里没有的编号校验器直接拦截。提示法律场景的提示词工程校验环节比生成环节更重要。生成错了可以改校验漏了就是事故。7. 提示词模板集成与调用效率优化从单模板到模板库的进阶单模板跑通之后下一步是把 100 模板集成到一个可调用的模板库里。手册里给的集成架构分三层模板存储层、模板调度层、模板执行层。存储层用 JSON Schema 定义模板结构调度层根据场景特征选择模板执行层负责变量填充和输出校验。模板调用的效率瓶颈通常在两个方面一是模板加载慢二是多模板并发调用时资源竞争。手册里的优化方案是预加载加热加载高频模板在服务启动时预加载到内存低频模板按需加载热加载机制支持不重启服务更新模板。缓存架构分三级本地缓存进程内、分布式缓存Redis、持久化存储数据库。本地缓存存最高频的模板分布式缓存存中频模板数据库存全量模板。# 模板调度器简化实现 import json from functools import lru_cache class TemplateScheduler: def __init__(self, template_dir): self.template_dir template_dir self.local_cache {} lru_cache(maxsize128) def load_template(self, template_id): 加载模板带 LRU 缓存 path f{self.template_dir}/{template_id}.json with open(path, r, encodingutf-8) as f: return json.load(f) def select_template(self, scenario_features): 根据场景特征选择模板 # 关键词匹配 语义相似度双路判断 template_id self._match_by_keywords(scenario_features) if not template_id: template_id self._match_by_semantic(scenario_features) return self.load_template(template_id) def _match_by_keywords(self, features): 关键词匹配 keyword_map { 买卖合同: contract_review_sales, 租赁合同: contract_review_lease, 股权转让: contract_review_equity, 起诉状: complaint_draft, 答辩状: defense_draft } for keyword, template_id in keyword_map.items(): if keyword in features: return template_id return None def _match_by_semantic(self, features): 语义相似度匹配简化示意 # 实际实现需要加载 Sentence-BERT 模型 # 这里返回默认模板 return contract_review_base # 调用示例 scheduler TemplateScheduler(./templates) template scheduler.select_template(买卖合同审查) print(template.get(template_id, unknown))这段调度器的逻辑是先用关键词匹配快速筛选匹配不到再用语义相似度兜底。lru_cache装饰器实现了本地缓存高频模板只加载一次。参数上template_dir是模板存储目录scenario_features是场景特征字符串可以是用户输入的关键词也可以是上游模块提取的特征。实际部署时_match_by_semantic需要接入向量数据库把场景特征转成向量后做相似度检索。模板压缩是另一个优化点。手册里提到提示词压缩率可达 30%做法是去掉冗余表述、合并重复约束、用缩写替代长术语。但压缩不能牺牲语义完整性压缩后的提示词要过一遍校验器确保关键约束没有丢失。我一般会保留两个版本完整版用于调试压缩版用于生产。异步调用和批量处理是应对高并发的关键。合同审查这种任务单份合同的处理时间可能在 10-30 秒如果同步调用并发量上不去。手册里的方案是用消息队列做异步处理前端提交任务后立即返回任务 ID后端处理完成后回调通知。批量处理则是一次提交多份合同后端并行处理最后合并结果。从那以后我每次集成新模板都强制走一遍关键词匹配→语义兜底→输出校验→人工抽检的流程宁可多花十分钟也不让一个未校验的模板进生产。希望帮到你。本文还有配套的精品资源点击获取