企业官网建设流程全解析

简介：这份PDF文档面向法律从业者、法律科技研究者及希望借助大模型提升文书效率的团队，系统讲解如何用提示词工程驱动DeepSeek完成法律文书自动化。内容围绕合同审查、起诉状起草、答辩状生成、法律意见书等12大核心场景展开，覆盖风险条款识别、条款合规校验、当事人信息结构化提取、诉讼请求规范化、证据清单关联匹配、反驳逻辑构建、法规检索关联等100余个高频模板，并配套法律术语库交互设计与语义、逻辑、规范三层适配原理。资源共1个PDF文件，约13.33MB，460页、60个大章节，支持目录跳转与左侧书签大纲快速定位，图表、目录等元素显示完整。已有109人学习。读者可据此掌握从架构设计到模板落地的完整方法，直接复用15+合同类型、20+案由及10+典型纠纷的提示词实例，快速搭建可迁移的法律文书自动化流程。

1. 法律文书自动化：从460页模板到可复现的提示词工程

一份460页的PDF，12大核心场景，100+高频模板——这个体量放在任何一家律所或法务部门，都意味着一件事：日常文书工作里存在大量高度重复、结构固定、但措辞要求精确的内容。合同审查意见、律师函、起诉状、答辩状、尽职调查报告、合规备忘录，这些文书的骨架大同小异，真正消耗时间的往往是措辞的反复推敲和格式的来回调整。DeepSeek法律文书自动化方案的核心思路，就是用提示词工程把这100+模板变成可调用、可组合、可迭代的生成规则，让模型承担初稿输出和格式填充，人只负责关键判断和最终把关。这套方案适合两类人：一是手头有大量文书模板但不知道怎么让AI稳定输出的法务从业者，二是想用DeepSeek API搭建内部文书工具的技术人员。接下来我会把提示词工程怎么设计、模板怎么组织、API怎么调、坑在哪里，一层层拆开讲清楚。

2. 提示词工程在法律文书场景的落地逻辑

2.1 为什么法律文书不能直接丢给模型自由发挥

法律文书的特殊性在于：格式必须合规，措辞必须精确，逻辑链条必须完整，而且不同场景对语气、立场、引用规范的要求差异极大。一份律师函和一份内部合规备忘录，虽然都是法律文书，但结构、语气、引用方式完全不同。如果直接给DeepSeek一句“帮我写一份律师函”，输出结果大概率是结构松散、措辞随意、缺少必要法律要素的泛泛之谈。

提示词工程在这里的作用，不是让模型“更聪明”，而是把法律文书的隐性规则显性化。具体来说，需要把以下要素固化到提示词里：文书类型对应的标准结构（比如起诉状必须包含当事人信息、诉讼请求、事实与理由、证据清单）、必须出现的法律要素（比如律师函中的委托人授权声明、合规备忘录中的法规依据）、语气和立场约束（比如代理词需要偏向己方当事人，审查意见需要中立客观）、以及输出格式要求（比如是否需要Markdown表格、是否需要编号、是否需要留空待填项）。

我一般会把一个场景的提示词拆成四层：角色定义层、任务描述层、约束条件层、输出格式层。角色定义层告诉模型“你是一名有十年经验的商事诉讼律师”；任务描述层说明“根据以下案件事实生成一份起诉状初稿”；约束条件层列出“诉讼请求必须分项编号、事实部分按时间线组织、引用法条必须写明全称和条款号”；输出格式层规定“用Markdown输出，当事人信息用表格，诉讼请求用有序列表”。这四层缺一不可，少了任何一层，输出稳定性都会明显下降。

2.2 12大场景的提示词模板怎么拆

460页的模板库不可能一次性全部塞进提示词，必须按场景拆分。常见的12大场景大致可以归为几类：诉讼类（起诉状、答辩状、代理词、证据清单）、非诉类（合同审查意见、律师函、尽职调查报告、合规备忘录）、内部类（法律意见书、风险提示函、制度审查报告、培训材料）。每个场景对应一套独立的提示词模板，模板之间共享一些通用组件，比如法条引用格式、当事人信息占位符、日期格式规范。

拆模板的关键原则是：一个场景一个模板文件，模板内部用变量占位符标记需要动态填入的内容。比如合同审查意见模板里，{{contract_type}}、{{party_a}}、{{party_b}}、{{key_clauses}}、{{risk_points}}这些变量由调用方传入，模型只负责根据变量内容生成审查意见正文。这样做的好处是模板本身可以版本化管理，修改模板不影响调用逻辑，也方便后续做A/B测试对比不同模板版本的输出质量。

下面是一个合同审查意见的提示词模板示例，用Python字符串表示：

CONTRACT_REVIEW_PROMPT = """ 你是一名有十五年经验的商事合同律师，擅长买卖合同、服务合同、租赁合同的审查。 ## 任务 根据以下合同基本信息，生成一份合同审查意见初稿。 ## 合同信息 - 合同类型：{{contract_type}} - 甲方：{{party_a}} - 乙方：{{party_b}} - 合同金额：{{amount}} - 关键条款摘要：{{key_clauses}} ## 审查要求 1. 逐条审查关键条款，指出对甲方不利的条款并说明风险等级（高/中/低） 2. 对每个风险点给出修改建议，修改建议必须具体到条款措辞 3. 引用相关法条时必须写明法律全称和条款号 4. 最后给出总体结论：建议签署 / 建议修改后签署 / 不建议签署 ## 输出格式 用Markdown输出，风险点用表格呈现，表格列包括：条款位置、风险描述、风险等级、修改建议。 总体结论单独一段，加粗显示。 """

这段模板的逻辑是：先锁定角色和专业范围，再给出任务和输入变量，然后用审查要求约束输出内容的深度和精度，最后用输出格式约束可读性。参数说明方面，{{contract_type}}建议限定在模板支持的合同类型范围内，超出范围的类型模型可能给出不准确的审查意见；{{key_clauses}}建议传入原文摘录而非概括，概括会丢失关键措辞细节；风险等级的高/中/低定义需要在模板外部统一，否则不同调用之间没有可比性。

2.3 模板字符串与变量注入的工程实现

模板字符串的处理方式直接影响调用效率和可维护性。常见做法有两种：一种是用Python的string.Template或str.format()做简单替换，另一种是引入Jinja2这类模板引擎做条件渲染和循环。对于法律文书场景，我倾向于用Jinja2，因为很多模板需要根据条件决定是否包含某些段落。比如律师函模板里，如果委托人不是自然人而是公司，需要额外包含法定代表人信息段落；如果涉及金额超过某个阈值，需要包含特别提示段落。这些条件逻辑用Jinja2的{% if %}写起来很自然，用str.format()就很难处理。

from jinja2 import Template LAWYER_LETTER_TEMPLATE = Template(""" 你是一名执业律师，根据以下信息生成一份律师函。 委托人：{{ client_name }} {% if client_type == "company" %} 法定代表人：{{ legal_representative }} 统一社会信用代码：{{ credit_code }} {% endif %} 对方当事人：{{ opposing_party }} 事由：{{ matter }} 诉求：{{ demand }} {% if amount > 1000000 %} 特别提示：本案涉及金额较大，建议在函件中明确保留进一步采取法律措施的权利。 {% endif %} 要求： 1. 函件格式符合律师函规范 2. 语气正式、克制，避免情绪化表述 3. 诉求部分分项列明，每项独立成段 4. 结尾注明律师事务所名称和律师签名栏 """) # 调用示例 prompt = LAWYER_LETTER_TEMPLATE.render( client_name="某某科技有限公司", client_type="company", legal_representative="张三", credit_code="91110000XXXXXXXXXX", opposing_party="某某贸易有限公司", matter="买卖合同货款纠纷", demand="1. 支付拖欠货款人民币120万元；2. 支付逾期利息；3. 承担本案全部诉讼费用", amount=1200000 )

这段代码的关键点在于：条件渲染让模板可以覆盖同一场景下的不同子情况，避免为每种情况单独写一个模板。参数说明方面，amount用数值类型而非字符串，方便做数值比较；demand传入的是已经格式化好的诉求文本，模型只负责将其融入函件正文，不负责生成诉求内容本身——诉求内容必须由人工确认，这是法律文书自动化的底线。

提示：模板中的条件判断逻辑建议保持简单，超过三层嵌套的条件逻辑会让模板难以维护，也容易让模型困惑。复杂条件应该在调用方处理，模板只接收处理好的变量。

3. 用DeepSeek API跑通文书生成的最小链路

3.1 API调用参数怎么设才稳定

DeepSeek API的调用方式和OpenAI兼容，核心参数包括model、messages、temperature、max_tokens、top_p。法律文书场景对稳定性的要求高于创意性，所以temperature建议设在0.1到0.3之间，top_p设在0.8到0.9之间。temperature越低，输出越确定，但过低会导致措辞僵硬；0.2左右是一个比较平衡的值，既能保证结构稳定，又能让措辞有一定自然度。

max_tokens需要根据文书类型设置。律师函一般800到1200字，起诉状可能到2000字以上，合同审查意见取决于合同条款数量，建议设在4000以上留足空间。如果输出被截断，模型会在末尾突然中断，这时候需要检查max_tokens是否够用，或者把长文书拆成多个段落分别生成再拼接。

import openai client = openai.OpenAI( api_key="your-deepseek-api-key", base_url="https://api.deepseek.com" ) def generate_legal_doc(prompt: str, max_tokens: int = 4000) -> str: response = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是一名严谨的法律文书助手，输出内容必须准确、格式规范。"}, {"role": "user", "content": prompt} ], temperature=0.2, top_p=0.85, max_tokens=max_tokens ) return response.choices[0].message.content

这段代码的逻辑是：用system message锁定模型的输出风格，用user message传入具体的提示词模板渲染结果。参数说明方面，base_url指向DeepSeek的API端点；model用deepseek-chat即可，如果需要更强的推理能力可以换deepseek-reasoner，但推理模型的响应时间更长、成本更高，法律文书生成场景一般不需要。temperature=0.2和top_p=0.85是经过多次测试后比较稳定的组合，如果发现输出格式经常跑偏，可以进一步降低temperature到0.1。

3.2 批量生成时的并发与限流处理

100+模板如果逐个串行调用，效率很低。实际使用中通常需要批量生成，比如一次性为多个案件生成律师函，或者为多份合同生成审查意见。DeepSeek API有速率限制，具体限制取决于账户等级，常见做法是用concurrent.futures做并发控制，同时加一个简单的重试机制。

import time from concurrent.futures import ThreadPoolExecutor, as_completed def generate_with_retry(prompt: str, max_retries: int = 3) -> str: for attempt in range(max_retries): try: return generate_legal_doc(prompt) except Exception as e: if attempt == max_retries - 1: raise wait = 2 ** attempt # 指数退避 time.sleep(wait) return "" def batch_generate(prompts: list, max_workers: int = 3) -> list: results = [None] * len(prompts) with ThreadPoolExecutor(max_workers=max_workers) as executor: future_map = { executor.submit(generate_with_retry, p): i for i, p in enumerate(prompts) } for future in as_completed(future_map): idx = future_map[future] results[idx] = future.result() return results

这段代码的关键设计是：max_workers=3控制并发数，避免触发API限流；指数退避重试在遇到临时错误时自动等待后重试，避免立即重试导致连续失败。参数说明方面，max_workers建议从3开始测试，如果API响应稳定再逐步提高，但一般不建议超过5，法律文书生成不是高并发场景，稳定性优先于吞吐量。max_retries=3意味着最多重试3次，如果3次都失败，说明可能是提示词本身有问题或者API账户异常，需要人工介入排查。

3.3 输出后处理：从模型输出到可交付文档

模型输出的Markdown文本不能直接交付，需要做几步后处理：检查必填字段是否完整、检查法条引用格式是否规范、检查是否有明显的占位符残留、把Markdown转换成Word或PDF格式。这些步骤可以用脚本自动化，但关键检查项建议保留人工确认环节。

import re def validate_output(text: str, required_sections: list) -> dict: """检查模型输出是否包含必要段落""" missing = [] for section in required_sections: if section not in text: missing.append(section) # 检查是否有未替换的占位符 placeholders = re.findall(r'\{\{.*?\}\}', text) # 检查法条引用格式（示例：匹配《XX法》第X条） law_refs = re.findall(r'《[^》]+》第[一二三四五六七八九十百千\d]+条', text) return { "missing_sections": missing, "unresolved_placeholders": placeholders, "law_reference_count": len(law_refs), "is_valid": len(missing) == 0 and len(placeholders) == 0 }

这段代码做的是基础校验：required_sections传入该文书类型必须包含的段落标题列表，比如律师函必须包含“委托人信息”“事由”“诉求”“结尾”四个段落；unresolved_placeholders检查是否有变量没被替换，这通常意味着调用方传参有遗漏；law_reference_count统计法条引用数量，数量为0可能意味着模型没有引用法条，需要人工复核。参数说明方面，required_sections需要根据文书类型动态传入，不同场景的必填段落不同；校验结果中的is_valid为False时，建议把输出退回人工处理，不要直接交付。

注意：法条引用格式检查只能验证格式，不能验证引用内容是否正确。模型可能会引用不存在的法条或引用错误条款，这一步必须由人工复核。我一般会把法条引用单独提取出来，让法务人员逐条核对。

4. 100+模板的组织、检索与版本管理

4.1 模板文件目录结构怎么设计

100+模板如果全部放在一个目录里，查找和维护都会很痛苦。我一般按“场景大类/文书类型/版本”三级目录组织。场景大类分为诉讼、非诉、内部三类；文书类型是具体的文书名称，比如起诉状、答辩状、律师函；版本用日期或语义化版本号标记，比如v1.0、v1.1。每个模板文件包含两部分：提示词模板正文和元数据（适用场景、必填变量、输出格式要求、最后修改日期）。

templates/ ├── litigation/ │ ├── complaint/ │ │ ├── v1.0.jinja2 │ │ └── meta.yaml │ ├── defense/ │ │ ├── v1.0.jinja2 │ │ └── meta.yaml │ └── evidence_list/ │ ├── v1.0.jinja2 │ └── meta.yaml ├── non_litigation/ │ ├── contract_review/ │ │ ├── v1.0.jinja2 │ │ └── meta.yaml │ └── lawyer_letter/ │ ├── v1.0.jinja2 │ └── meta.yaml └── internal/ ├── legal_opinion/ │ ├── v1.0.jinja2 │ └── meta.yaml └── risk_memo/ ├── v1.0.jinja2 └── meta.yaml

这种结构的优势是：场景和文书类型一目了然，版本管理清晰，新增模板不会影响已有模板。meta.yaml里记录模板的元信息，比如：

name: 合同审查意见 scene: non_litigation required_variables: - contract_type - party_a - party_b - key_clauses output_format: markdown last_modified: 2025-01-15 version: v1.0

元数据的作用是让调用方知道这个模板需要哪些变量、输出是什么格式，避免传参遗漏。同时，元数据也可以用来做模板检索——比如根据scene字段筛选出所有非诉类模板。

4.2 模板检索与动态加载

当模板数量到100+时，调用方不可能记住每个模板的文件路径。常见做法是写一个模板加载器，根据场景和文书类型自动定位模板文件，并返回渲染后的提示词。

import os import yaml from jinja2 import Template class TemplateLoader: def __init__(self, base_dir: str): self.base_dir = base_dir self.index = self._build_index() def _build_index(self) -> dict: """扫描目录，建立 scene/doc_type -> 最新版本路径 的索引""" index = {} for root, dirs, files in os.walk(self.base_dir): for f in files: if f.endswith(".jinja2"): rel_path = os.path.relpath(os.path.join(root, f), self.base_dir) parts = rel_path.split(os.sep) if len(parts) >= 3: scene, doc_type, version_file = parts[0], parts[1], parts[2] version = version_file.replace(".jinja2", "") key = f"{scene}/{doc_type}" if key not in index or version > index[key]["version"]: index[key] = { "path": os.path.join(root, f), "version": version } return index def render(self, scene: str, doc_type: str, variables: dict) -> str: key = f"{scene}/{doc_type}" if key not in self.index: raise ValueError(f"模板不存在: {key}") with open(self.index[key]["path"], "r", encoding="utf-8") as f: template = Template(f.read()) return template.render(**variables)

这段代码的逻辑是：初始化时扫描模板目录，建立scene/doc_type到最新版本模板路径的索引；调用时根据场景和文书类型查找模板，渲染后返回提示词。参数说明方面，base_dir是模板根目录；variables是模板变量字典，键名必须和模板中的占位符一致；版本比较用的是字符串比较，所以版本号命名要保证字典序和实际版本顺序一致，比如v1.0、v1.1、v2.0。

4.3 模板版本迭代与A/B测试

模板不是写完就固定不变的。实际使用中会发现某些模板输出质量不稳定，或者某些场景需要调整措辞风格。这时候需要做版本迭代，同时保留旧版本以便回滚。A/B测试的做法是：同一批输入分别用两个版本的模板生成输出，由法务人员盲评打分，选择得分更高的版本作为主版本。

def ab_test_template(scene: str, doc_type: str, variables_list: list, version_a: str, version_b: str) -> dict: """对同一批输入用两个版本模板生成，返回对比结果""" loader = TemplateLoader("templates") results = {"a": [], "b": []} for variables in variables_list: # 临时切换版本（实际实现中需要更精细的版本控制） prompt_a = loader.render(scene, doc_type, variables) prompt_b = loader.render(scene, doc_type, variables) results["a"].append(generate_legal_doc(prompt_a)) results["b"].append(generate_legal_doc(prompt_b)) return results

这段代码是一个简化示例，实际做A/B测试时需要更精细的版本控制机制，比如在模板路径中显式指定版本号，而不是自动选择最新版本。参数说明方面，variables_list是测试用例列表，建议覆盖典型场景和边界场景；version_a和version_b指定要对比的两个版本。测试结果需要人工评分，评分维度包括：结构完整性、措辞准确性、法条引用规范性、格式合规性。

提示：模板版本迭代建议保留变更日志，记录每次修改的原因和影响范围。法律文书模板的修改可能影响大量输出，没有变更日志的话，出问题很难追溯。

5. 避坑与排查：法律文书自动化最容易翻车的五个地方

5.1 模型输出格式不稳定，Markdown表格时有时无

现象：同一个模板，有时候输出Markdown表格，有时候输出纯文本列表，有时候表格列数不对。

原因：提示词中对输出格式的描述不够具体，模型在不同温度参数下对格式的理解有波动。另外，如果模板中变量内容本身包含Markdown符号，也可能干扰模型对格式的判断。

解决：在提示词中把输出格式要求写死，比如“必须用Markdown表格输出，表格必须包含以下四列：条款位置、风险描述、风险等级、修改建议”。同时把temperature降到0.1，减少随机性。如果变量内容包含Markdown符号，在传入前做转义处理。

5.2 法条引用张冠李戴，引用了不存在的条款

现象：模型输出的法条引用看起来格式正确，但条款号或法律名称有误，比如把《民法典》第577条写成第578条，或者引用了已经废止的法律。

原因：模型的知识截止日期之后的法律修订它不知道，而且模型可能会“编造”看起来合理的法条引用。这是法律文书自动化中最危险的坑。

解决：在提示词中明确要求“只引用你确定存在的法条，如果不确定，写‘需人工确认法条引用’”。同时在后处理阶段用法条库做校验，把模型引用的法条和权威法条库比对，不匹配的标记出来人工复核。我一般会把法条引用单独提取成列表，让法务人员逐条核对，这一步不能省。

5.3 长文书生成到一半被截断

现象：起诉状或尽职调查报告生成到一半突然中断，末尾缺少结论段落或签名栏。

原因：max_tokens设置不够，或者模型在生成长文本时提前终止。DeepSeek API的max_tokens上限取决于模型版本，如果文书预计超过3000字，需要留足余量。

解决：把max_tokens设到8000以上，如果还是截断，把长文书拆成多个段落分别生成。比如起诉状可以拆成“当事人信息”“诉讼请求”“事实与理由”“证据清单”四段，每段单独调用API生成，最后拼接。拆分生成的好处是每段的质量更可控，缺点是段落之间的衔接需要人工检查。

5.4 模板变量传参遗漏，输出中出现未替换的占位符

现象：生成的文书中出现{{party_a}}或{{amount}}这样的占位符，说明调用方传参时遗漏了某些变量。

原因：模板变量和调用方传参的键名不一致，或者调用方没有检查模板的required_variables元数据。

解决：在模板加载器中加一道校验，渲染前检查required_variables是否都在传入的变量字典中。如果缺失，直接抛出异常并列出缺失的变量名，而不是让模型生成带占位符的输出。后处理阶段的validate_output函数也会检查未替换的占位符，双重保险。

5.5 不同场景的提示词互相污染

现象：生成律师函时出现了合同审查意见的段落结构，或者生成合规备忘录时语气偏向诉讼代理词。

原因：多个场景的提示词模板共享了部分组件，但组件之间的边界不清晰，导致模型混淆了不同场景的要求。另外，如果system message设置得太泛化，也可能导致模型在不同场景之间“串味”。

解决：每个场景的提示词模板保持独立，不共享段落结构相关的组件。共享的只应该是法条引用格式、日期格式这类纯格式规范。system message建议按场景定制，比如律师函场景的system message强调“正式、克制”，合同审查场景的system message强调“中立、客观”。如果发现串味，检查模板之间是否有不该共享的内容。

6. 把460页模板变成可迭代资产的关键技巧

这套方案真正有价值的地方，不是一次性生成多少份文书，而是把460页静态模板变成可迭代、可度量、可积累的资产。我自己的习惯是：每生成一批文书，就把人工修改的地方记录下来，分析哪些是模型反复出错的地方，然后针对性调整提示词。比如发现模型总是在“诉讼请求”部分把金额写错，就在提示词里加一条“金额必须与输入变量中的amount字段完全一致，不得自行修改”。这种迭代看起来慢，但积累下来，模板的命中率会越来越高。

另一个技巧是建立“场景-模板-输出”的三级评估体系。每个场景下的每个模板，定期用一批标准测试用例跑一遍，记录输出质量评分。评分维度包括：结构完整性（是否包含所有必填段落）、措辞准确性（是否有语法错误或不当表述）、法条引用规范性（引用格式是否正确、是否有编造）、格式合规性（是否符合输出格式要求）。评分低于阈值的模板，触发人工复核和版本迭代。

def evaluate_template_output(output: str, expected_sections: list, law_ref_pattern: str) -> dict: """评估单次输出的质量""" score = 0 max_score = 4 # 结构完整性 sections_found = sum(1 for s in expected_sections if s in output) if sections_found == len(expected_sections): score += 1 # 措辞准确性（简单检查：是否有明显语法错误标记） if "。。" not in output and "，，" not in output: score += 1 # 法条引用规范性 law_refs = re.findall(law_ref_pattern, output) if len(law_refs) > 0: score += 1 # 格式合规性（检查是否有Markdown表格） if "|" in output and "---" in output: score += 1 return { "score": score, "max_score": max_score, "sections_found": sections_found, "law_ref_count": len(law_refs) }

这段代码做的是自动化质量评估，expected_sections是该文书类型的必填段落列表，law_ref_pattern是法条引用的正则表达式。评分结果可以用来做模板版本的横向对比，也可以用来监控模板质量的变化趋势。参数说明方面，expected_sections需要根据文书类型动态传入；law_ref_pattern建议用比较宽松的正则，先匹配到候选引用，再人工复核准确性。

最后一个技巧是关于提示词工程的“后悔药”：每次修改模板前，先把当前版本备份，修改后用同一批测试用例跑对比。如果新版本评分下降，立即回滚。法律文书自动化的容错空间很小，一个措辞不当可能导致法律风险，所以宁可保守迭代，不要激进修改。我一般会在模板目录下建一个changelog.md，记录每次修改的日期、修改内容、修改原因、测试评分变化。这个习惯帮我避免了好几次“改完发现还不如不改”的翻车。

希望帮到你。

本文还有配套的精品资源，点击获取