法律人DeepSeek使用指南：提示词、API与RAG工作流

简介：DeepSeek法律人使用指南.pdf 是一份面向法律从业人员、法学研究者及关注法律智能化工具读者的实操型资料，聚焦DeepSeek推理模型在法学领域的落地方法。内容从使用前景写到核心与进阶技巧，涵盖法律信息检索、立法条文修订对比、案例比对分析、文献核心观点提炼与论文润色翻译等典型场景，并按“主体—行为—目标”三要素给出指令优化示范，帮助读者把模糊需求拆解为精准提问。资源共1个文件，为PDF格式，压缩包大小1.52MB，轻量便携，适合移动端随时查阅。已有205人学习浏览。除检索策略外，文中还演示了基于请求权基础分析法的要件解构、漏洞识别，以及通过本地部署DeepSeek构建私人知识库的思路；对于跨国法律合规等复杂场景，也强调AI仅为辅助工具，最终判断仍需专业责任把关，可作为提升文献检索与案例分析效率的案头参考。

1. 法律人为什么要单独有一份 DeepSeek 使用指南

深夜改合同、早上开庭、下午还要出一份法律意见书，这是很多律师和法务的常态。真正耗时间的不是“读”，而是“检索、比对、起草引用”。DeepSeek 这类大模型能帮上大忙，但直接把它当搜索引擎用，得到的结果往往是你不敢写进文书里的。市面上流传的《DeepSeek法律人使用指南.pdf》，核心不是教你怎么“问问题”，而是把模型接进法律工作流的一套范式：检索式提问、条款级审查、结果回填、私域知识库召回。这篇文章适合独立律师、企业法务和法学院做案例研究的人——你需要的不只是一个能聊天的模型，而是一套能对结果负责的干活流程。

2. 让 DeepSeek 听懂法律诉求：三段式检索指令与参数设置

2.1 为什么普通提问在法务场景会失效

直接对 DeepSeek 说“帮我审一下这份合同”，它给你的是泛泛而谈的“注意违约责任、注意知识产权”这类教科书式建议，不是你能直接用在工作成果里的内容。原因是法律文本对引用、条文序号、责任边界极其敏感，模型需要先知道三件事：你在什么角色、要完成什么任务、输出要符合什么格式。

我一般把提示词拆成三段：

system_prompt = "你是执业十年的公司法律师，擅长合同审查与法律风险识别。" user_prompt = """ 任务：审查《软件采购合同》中第 3 条至第 7 条。 输出要求： 1. 逐条列出风险点，标注条款序号； 2. 每条风险给出修改建议； 3. 对应《民法典》相关条文号； 4. 没有把握的内容写"未检索到依据"，不许编造。 """

这种三段式的结构，核心是给模型划定了“边界”：角色决定语气和知识侧重，任务决定处理范围，输出要求决定回复形态。DeepSeek 对结构化指令的遵循度不错，但前提是你把约束写得足够明确。很多法律人第一次用的时候翻车，就是因为只给了任务、没给输出约束，模型一股脑输出大段论述，反而没法直接用。

2.2 法律场景的参数取值：温度、top_p 与 max_tokens

API 调用 DeepSeek 时，几个关键参数直接影响出活质量。在法律场景里，创造性不是第一诉求，准确性和一致性才是。我通常把 temperature 设到 0.1 或 0.2，top_p 保持 0.9 左右，max_tokens 根据任务调整。

把 max_tokens 调低是常见误区。合同审查动辄几千字，输出太短说明模型只挑了几条明显的风险，漏掉了中后段条款里的坑。设置 2000 以上，让模型有足够的空间把每一条都说透。

2.3 让模型输出结构化 JSON，而不是一段散文

如果你想批量处理多份合同，最省力的做法是让 DeepSeek 直接输出 JSON，然后由脚本解析成表格。法律人不需要上一整天提示词工程课，但下面这个 response_format 参数值得会，它能让你的工作成果从“一段文字”变成“一张表”。

from openai import OpenAI client = OpenAI( api_key="your-api-key", base_url="https://api.deepseek.com/v1" ) resp = client.chat.completions.create( model="deepseek-chat", response_format={"type": "json_object"}, temperature=0.1, max_tokens=2000, messages=[ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt} ] ) print(resp.choices[0].message.content)

这段代码的作用是：固定输出为 JSON 对象，方便后续把审查结果写进 Excel 或 Word 表格。response_format 是个容易被忽略的参数，DeepSeek 支持 JSON 输出模式，开启后模型会尽量按 JSON 结构返回，脚本解析时不容易报错。你只需要在提示词里写清楚“输出 JSON 格式，包含条款序号、风险描述、修改建议、法律依据四个字段”，模型就会按这个结构走。

3. 把 DeepSeek 接进文书工作流：从合同解析到审查结果回填

3.1 为什么不用复制粘贴，而是用脚本解析 Word 合同

拿到一份几十页的合同，手动复制给模型再贴回结论，来回切换窗口非常低效。更稳的做法是用 python-docx 读取 Word 文件，按章节切分，再逐段调用 DeepSeek API 做条款级别审查。这套流程对判决书、合同、法律意见书都适用，核心是“让脚本替你搬运文本，让模型干分析，再让脚本把结果写回文档”。

from docx import Document doc = Document("软件采购合同.docx") paragraphs = [p.text.strip() for p in doc.paragraphs if p.text.strip()] # 按第几条拆分，这里用简单关键字切分 current_index = "前言" chunks = {} for para in paragraphs: if para.startswith("第") and "条" in para[:8]: current_index = para[:8] chunks[current_index] = [] chunks.setdefault(current_index, []).append(para) for clause_id, content in chunks.items(): print(clause_id, "->", "".join(content)[:50])

这段代码先把合同按“第 X 条”切成块，再交给后续的审查脚本。切分逻辑不用写得太复杂，法律文书章节结构相对规整，按条号匹配就够了。如果你处理的是判决书，可以按“本院认为”“判决如下”这类段落标志切。脚本的价值不只是省复制粘贴，更重要的是保留条款对应关系——审查结论能定位到原始条文序号，后续写回 Word 时不会错位。

3.2 批量审查：让 DeepSeek API 逐条给出风险结论

切好之后的下一步，是把每个条款块批量提交给 DeepSeek。这里的难点是控制请求频率和异常处理。我一般会写一个带重试的循环，避免网络抖动导致整批任务报废。

import time from openai import OpenAI client = OpenAI(api_key="your-api-key", base_url="https://api.deepseek.com/v1") def review_clause(clause_text, retries=3): for attempt in range(retries): try: resp = client.chat.completions.create( model="deepseek-chat", response_format={"type": "json_object"}, temperature=0.1, max_tokens=1500, messages=[ {"role": "system", "content": "你是合同审查律师，只输出JSON。"}, {"role": "user", "content": f"审查以下条款：{clause_text}"} ] ) return resp.choices[0].message.content except Exception as e: print(f"第{attempt+1}次重试: {e}") time.sleep(2 ** attempt) return None results = [] for clause_id, content in chunks.items(): result = review_clause("".join(content)) results.append({"clause": clause_id, "review": result}) time.sleep(1) # 避免请求过快触发限流

重试机制我一般用指数退避：第一次失败等 2 秒，第二次等 4 秒，第三次等 8 秒。限流是 API 调用的常见问题，不是模型的问题，是请求频率太高。等到第三四秒再重试，基本都能成功。对待大模型要有耐心，它是个黑匣子，你得在它周围套一层工程保护。

3.3 审查结果写回 Word：保持原始条款编号对应

审查结果拿到之后，直接打印在终端里没有意义。要把结论以批注或附表的形式写回 Word 原文，这样交给客户或团队时，别人能对照原文看。

from docx import Document doc = Document("软件采购合同.docx") review_map = {r["clause"]: r["review"] for r in results} # 在文档末尾追加审查意见表 doc.add_page_break() doc.add_heading("AI审查意见汇总", level=1) for clause_id, review in review_map.items(): p = doc.add_paragraph() p.add_run(f"{clause_id}").bold = True p.add_run(f"\n{review}") doc.save("软件采购合同_审查意见.docx")

这段脚本把每一条的审查结论追加到原合同末尾，生成一份带“AI 审查意见汇总”的新文档。别把结论直接塞进原条款中间，那样会污染原文，审阅者也没法快速对照。独立成表是最稳的交付形态。

如果业务里经常处理同类型合同，把审查模板固定下来，字段对齐后直接用 Pandas 导出 Excel 也行：

import pandas as pd df = pd.DataFrame(results) df.to_excel("审查结果汇总.xlsx", index=False)

表格化输出最大的好处是可检索、可筛选、可二次审批。法律人最终要把成果交给委托人或法务总监看，一张干净的表格远比对话截图有说服力。

4. 私域知识库与检索增强：把自有的法条库和案例库喂给模型

4.1 为什么只靠模型内置知识不够用

DeepSeek 的预训练语料里包含大量公开法律文本，但到了具体业务里，你手里往往有这些模型没见过的东西：公司内部合同模板库、历史判决书、专项法规汇编、合作方的定制条款。这些私有数据直接塞进提示词不现实，一是长度有限制，二是模型会被无关内容干扰。

正确做法是“先检索、再生成”。把私有文档切块、向量化，用户提问时先做相似度检索，把最相关的几个片段拼进提示词，让模型基于这些片段作答。这就是检索增强生成（RAG）的常规落地方式，也是法律行业把 DeepSeek 用出价值的必经之路。

4.2 最小可运行的 RAG 脚本骨架

不需要一上来就搭一套复杂的知识库平台。先用一个轻量向量库做原型验证，确认检索质量后再考虑规模化。以常见做法为例，你只需要三个环节：切块、向量化、相似度检索。

from sentence_transformers import SentenceTransformer import numpy as np embedder = SentenceTransformer("paraphrase-multilingual-MiniLM-L12-v2") documents = [ "劳动者提前三十日书面通知用人单位，可以解除劳动合同。", "用人单位自用工之日起即与劳动者建立劳动关系。", # 这里放你的私有法条、判决书摘要、合同条款等 ] doc_vectors = np.array([embedder.encode(d) for d in documents]) def search(query, top_k=3): q_vec = embedder.encode(query) scores = np.dot(doc_vectors, q_vec) / ( np.linalg.norm(doc_vectors, axis=1) * np.linalg.norm(q_vec) + 1e-8 ) top_indices = np.argsort(scores)[::-1][:top_k] return [(documents[i], float(scores[i])) for i in top_indices] query = "员工主动离职需要提前多久通知公司？" for doc, score in search(query): print(f"{score:.3f} -> {doc}")

这段代码把法条向量化存在内存里，查询时计算余弦相似度取 top_k。原型验证阶段这个方案足够跑通。切块大小直接影响检索质量，法律条文一般一条切一块，不要把一个条款拆成两半，否则检索时语义会被破坏。向量化模型也决定了召回效果，中文法律文本用多语言嵌入模型作为基线即可，后续有精力再换更大的法律领域微调模型。

4.3 参数边界：top_k、chunk_size 与“没召回比召错误更安全”

RAG 系统在工程上不难搭，难的是参数让人纠结。法律场景和客服问答不同：客服回答错了道个歉就行，法律检索召回了一条不相关的“依据”，被写进文书是要出事的。

我常见的做法是：chunk_size 控制在 300 到 800 字之间，太长会稀释语义，太短会切断上下文；top_k 取 3 到 5，先看召回质量再决定上限。检索阈值建议设置一个拒绝回答的边界——当最高相似度低于 0.65 时，直接返回“未检索到相关资料”，而不是硬给一个答案。

这套机制把 DeepSeek 从“什么都能聊”变成了“只聊你给它的资料”。你在内网服务器上部署好之后，企业微信机器人、飞书机器人、vscode 插件、甚至 Claude Code 这类第三方工具接入，本质上都是把问题转发给这个检索加生成的接口。

5. API 接入、本地部署与常见问题排查

5.1 用一套环境变量，让 DeepSeek 接入各种第三方工具

API 调用 DeepSeek 的接入方式和 OpenAI 兼容格式保持一致，这意味着大量现存工具不需要改动核心代码，改改环境变量就能切换模型。你可以在命令行里设置两个变量，之后所有兼容 OpenAI 接口的工具都会自动走 DeepSeek。

export OPENAI_API_KEY="your-deepseek-api-key" export OPENAI_BASE_URL="https://api.deepseek.com/v1"

设置完这两个变量后，vscode 里的编码助手、企业微信机器人、Claude Code、Codex 这些工具在读取 OpenAI 配置时，就会把请求发往 DeepSeek 的接口。这就是“全生态接入”的本质——不是每个工具都原生支持 DeepSeek，而是它们都兼容 OpenAI 协议，DeepSeek 提供了兼容端点。你在内网服务器里做同样的事，把 BASE_URL 指向本地服务的地址就行。

5.2 私有化部署：vLLM 加载 DeepSeek 的最小启动方式

如果合同文件敏感、不能出内网，本地部署是绕不开的一步。常见做法是用 vLLM 把模型跑起来，暴露一个本地 OpenAI 兼容服务。

vllm serve deepseek-ai/deepseek-chat \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192

启动之后，客户端把 base_url 改成 http://内网IP:8000/v1，api_key 随便填一个占位符，就能复用前面所有代码。本地部署的关键是显存：模型参数量越大，需要的显存越多。如果显存不够，可以降量化精度，但要接受输出质量会略有下降。

5.3 三条血泪排坑记录

现象一：调用 API 时提示超时，重试三次都失败。 原因：请求并发太高，被限流；或单次请求的 max_tokens 设得太大，响应太慢。 解决：降低并发，代码里加 time.sleep；max_tokens 按需设置，不要一口气设到 8000。

现象二：模型输出的 JSON 字符串解析失败。 原因：response_format 只约束模型“尽量输出 JSON”，但模型仍可能在 JSON 前后加json 代码块标记。 解决：解析前先做清洗，把json 和 ``` 去掉，再用 json.loads；如果解析失败，让模型重新生成一次。

现象三：本地部署 vLLM 时显存不足，启动就报 OOM。 原因：tensor-parallel-size 设置不合理，或模型量化位数不适合当前 GPU。 解决：先用 4bit 量化加载较小模型验证流程，再用主力 GPU 跑完整版本。不要一上来就把 max-model-len 顶满。

这些坑的共性在于：大模型的不可预测性需要用工程手段来兜底。重试、降级、清洗、加超时，每一层保护都对应一个曾经翻车的场景。模型是黑匣子，但围绕它的工程链路必须是白盒。

6. 用回放法沉淀提示词模板：验证回答质量的可操作技巧

完成前端接入和参数调优之后，还剩一项容易被忽略的事：谁来验证这版提问模板真的有效。我习惯的做法是“回放法”——把每次请求的提示词和模型输出都记录到本地文件，定期回头做对比。

import json from datetime import datetime log_entry = { "time": datetime.now().isoformat(), "prompt": user_prompt, "model": "deepseek-chat", "temperature": 0.1, "response": resp.choices[0].message.content } with open("prompt_log.jsonl", "a", encoding="utf-8") as f: f.write(json.dumps(log_entry, ensure_ascii=False) + "\n")

积累了日志之后，你可以拿同一条指令的不同版本做 A/B 对比：哪个写法的输出更贴需求，哪个字段更容易被漏掉。我还会固定抽三五条已知判决结论的法律问题做“基准测试”——每版提示词跑一遍，看模型是否会编造不存在的“依据”。这个基准不追求覆盖率，只盯两点：引用是否真实、结论是否稳定。这套方法不依赖任何插件，一个日志文件加一个基准题目集就够了，算是我用过最值当的验证手段。

提示词模板沉淀下来之后，整个工作流才算闭环：同样的合同，换一个人来操作，得到的结果依然稳定。DeepSeek 的价值从来不是帮你写一份漂亮的文案，而是把重复性高、规则明确的检索比对工作标准化。希望帮到你。

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