30分钟搭一个“法律文书自动生成器”：用 n8n + Deepseek V3，把需求一句话变成可下载 Word

你只要输入一句：

“帮我生成一份劳动仲裁申请书，情况是公司拖欠我 3 个月工资，还没签劳动合同。”

几分钟后，就能拿到一份结构完整、格式规整、可直接下载的 Word 文档。

这件事听起来像“AI 魔法”，但真正卡住大多数人的，不是 AI 不会写，而是最后那一步——怎么把零散的描述，变成标准化文书，并且自动导出成能交付的文件。

这也是为什么“法律文书自动生成”是 AI 自动化里非常值得做的场景：它足够刚需，足够标准化，也足够能体现自动化的价值。今天这篇文章，我们不讲空概念，直接带你在 30 分钟内搭出一个能跑、能用、能扩展的工作流：

• 用户输入需求
• n8n 触发流程
• Deepseek V3 理解并生成文书内容
• 输出结构化 JSON
• 自动填入 Word 模板
• 导出下载链接

更重要的是，这套方法不只适用于法律文书。你学会这一篇，下一步就能迁移到合同草拟、制度模板、客服回复、申诉材料等高频场景。

---

为什么这个流程值得做：法律文书自动生成，正是 AI 自动化的高价值场景

很多人以为“写法律文书”最难的是专业知识，其实对多数普通用户来说，更常见的难点是这几个：

• 不会标准化表达：脑子里知道发生了什么，但写出来像流水账
• 不会搭结构：事实、诉求、法律依据、落款，经常漏项
• 来回改格式很耗时：搜模板、复制粘贴、调标题字号、补字段，20 分钟起步
• 结果不好交付：AI 给你一段文字，但你真正需要的是一个 Word 文件

这时候，n8n + Deepseek V3 的组合就很顺手：

• n8n 负责串流程，像装配线一样把“输入—处理—输出”连起来
• Deepseek V3 负责理解自然语言、补全文书结构、生成严谨内容
• Word 模板负责把结果变成可交付文档

一个直观对比：

人工写文书 vs 自动化输出

• 人工方式

2. 找类似案例

3. 复制后手动改内容

4. 检查格式和缺项

5. 导出发送

通常耗时 20-40 分钟

• 自动化方式

2. 点击执行

3. 下载 Word

通常耗时 2-5 分钟

这不是说 AI 能替代专业律师，而是它特别适合做草拟、整理、结构化输出这类“高重复、强格式”的工作。

边界一定要说清楚：AI 可以辅助草拟法律文书，但不能替代专业律师审核。尤其涉及诉讼、仲裁、重大合同与复杂事实争议时，最终版本务必由专业人士把关。

---

30分钟开工前准备：账号、工具、节点、模板一次配齐

先别被“自动化”三个字吓住。今天这个教程不是教你编程，而是教你照着连节点、改几个参数、替换一下提示词，把流程跑起来。

你需要准备的 4 样东西

#### 1. 一个 n8n 环境

你可以用本地部署，也可以用云端实例。只要能正常创建工作流、添加节点就行。

如果你之前没接触过 n8n，也不用担心，今天这套流程只会用到几个基础节点：

• Manual Trigger 或 Form Trigger
• Set
• HTTP Request
• Code 或 Edit Fields
• 文档生成/文件输出节点

#### 2. 一个可用的大模型接口

这一环是新手最容易卡住的地方：接口地址、鉴权、请求格式、模型兼容性，只要错一个就报错。

如果你想少走弯路，可以直接通过 api.884819.xyz 来接入模型。它比较适合教程场景，原因很简单：

• 用户名+密码即可注册，不需要邮箱验证
• 注册即送5元体验额度
• 国产模型完全免费，像 Deepseek R1/V3、通义千问 Qwen3、Kimi K2.5、GLM-5 都能直接用
• 没有月租、没有订阅，按量付费
• 平台内置 AI 对话功能，注册后直接能用

对刚开始搭流程的人来说，这种“先把接口跑通”的体验，比一上来折腾复杂配置友好得多。

#### 3. 一个 Word 模板

这一步特别关键。很多人以为“导出 Word”很复杂，其实本质就是模板占位符替换。

一个最小可运行模板，可以长这样：

文书标题：{{title}}

申请人/甲方：{{party_a}}
被申请人/乙方：{{party_b}}

事实与理由：
{{facts}}

请求事项：
{{claims}}

法律依据：
{{legal_basis}}

落款：
{{closing}}

你只要提前把模板里的占位符定义好，后面就能让 AI 直接往里填。

#### 4. 一组测试场景

建议先用 3 类高频且结构清晰的场景测试：

• 借款催款函
• 劳动仲裁申请书
• 租赁合同补充协议

因为这三类文书既常见，又能看出 AI 在“事实整理 + 标准结构输出”上的能力。

---

手把手搭建主流程：从自然语言需求到结构化法律文书

这一部分是全文核心。你可以把这个工作流理解成一条流水线：先收集需求，再让 AI 生成结构化内容，最后填进 Word 模板。

总流程图

下面是一张适合直接照着搭的总流程图：

flowchart LR
A[用户输入需求] --> B[n8n触发]
B --> C[Deepseek V3解析与生成]
C --> D[输出JSON结构化字段]
D --> E[Word模板填充]
E --> F[导出文档/发送下载链接]

如果你要写成博客发布版，这里建议插入一张头图或流程图截图，效果会非常直观。

第一步：创建输入节点

最简单的方式是用 Manual Trigger 先跑通流程；如果想更像产品一点，可以换成 Form Trigger。

用户输入建议至少包含这些字段：

• doc_type：文书类型
• user_input：用户自然语言描述
• party_a：申请人/甲方
• party_b：被申请人/乙方
• extra_notes：补充说明

比如测试输入可以写成：

文书类型：劳动仲裁申请书
申请人：张三
被申请人：某科技公司
情况说明：2024年3月至2024年5月，公司拖欠我三个月工资，共计24000元，且未签订书面劳动合同。我多次催要无果，希望申请劳动仲裁，要求支付拖欠工资并主张未签合同的双倍工资。

第二步：调用 Deepseek V3 解析需求并生成正文

在 n8n 里添加 HTTP Request 节点，把用户输入发给模型。

这里建议把模型任务拆成两层：

• 第一层：理解用户输入
• 第二层：输出固定结构的 JSON

这么做的好处是：后面填模板时不容易乱。

基础版 Prompt

你是一名法律文书起草助手。请根据用户提供的信息，生成一份规范、正式、结构完整的法律文书草稿。

要求：
1. 文书类型：{{文书类型}}
2. 语言风格：正式、严谨、适合法律场景
3. 必须包含：当事人信息、事实经过、诉求/主张、法律依据、落款
4. 如果用户信息缺失，请用“【待补充】”标记
5. 输出格式为 JSON：
{
"title": "",
"party_a": "",
"party_b": "",
"facts": "",
"claims": "",
"legal_basis": "",
"closing": ""
}

进阶版 Prompt

你是一名严谨的法律文书起草助手，请根据用户提供的案件信息，输出可用于模板填充的结构化JSON。

规则：
1. 只能输出合法JSON，不要输出解释、前缀、Markdown代码块。
2. 根据“文书类型”自动采用对应结构化表达，措辞正式、克制、专业。
3. 对缺失事实不要编造，统一标记为“【待补充】”。
4. 如果用户描述中存在时间、金额、地点、违约行为等关键信息，请优先提取并写入 facts。
5. claims 必须使用分点式表达，便于直接写入正式文书。
6. legal_basis 只做常规性表述，不构成正式法律意见。
7. closing 末尾自动补充：“仅供参考，请结合具体案件事实并由专业人士审核。”

输出JSON字段如下：
{
"title": "",
"doc_type": "",
"party_a": "",
"party_b": "",
"facts": "",
"claims": "",
"legal_basis": "",
"closing": ""
}

HTTP Request 请求配置示例

下面这个片段，是最关键的部分。你不一定需要完整工作流，但至少这一段能直接帮你理解“模型调用长什么样”。

{
"model": "Deepseek V3",
"messages": [
{
"role": "system",
"content": "你是一名法律文书起草助手，请输出结构化JSON。"
},
{
"role": "user",
"content": "{{ $json.user_input }}"
}
],
"temperature": 0.2
}

这里我建议把 temperature 设低一点，比如 0.2。原因很简单：法律文书重视稳定、完整、规范，不追求天马行空的表达。

一个经验值：文书类任务，温度越低，结构越稳；营销类文案，温度可以适当高一点。

第三步：把模型输出变成可填模板的字段

正常情况下，模型会返回一个 JSON 字符串。接下来你要做的是把它解析成字段。

比如在 Code 节点里做简单处理：

const raw = $json.output || $json.content || '{}';
const data = JSON.parse(raw);

return [
{
json: {
title: data.title || '',
party_a: data.party_a || '',
party_b: data.party_b || '',
facts: data.facts || '',
claims: data.claims || '',
legal_basis: data.legal_basis || '',
closing: data.closing || ''
}
}
];

这一步看似普通，实际上决定了后面模板是否能顺利填充。

最常见的坑有两个：

• 字段名和模板占位符不一致
• 模型输出夹带解释文字，导致 JSON 解析失败

所以在 Prompt 里要求“只输出合法 JSON”，非常有必要。

第四步：写入 Word 模板

接下来，把这些结构化字段写进你的 Word 模板。

如果你使用支持模板替换的文档节点，映射关系通常是这样：

• {{title}} → title
• {{party_a}} → party_a
• {{party_b}} → party_b
• {{facts}} → facts
• {{claims}} → claims
• {{legal_basis}} → legal_basis
• {{closing}} → closing

这一步建议你准备一个 .docx 模板文件，并且先手动测试一遍占位符格式，确保没有多空格、没有拼写错误。

第五步：导出下载链接

最后一步，把生成好的 Word 文件保存并返回下载地址。

如果你做给自己用，保存到本地或云盘都可以；如果是做成团队工具，通常会接：

• 企业微信
• 邮件
• 对象存储下载链接
• 内部工单系统

到这里，一条最小可运行的“法律文书自动生成”流程就已经完成了。

---

让流程更像“可用产品”：校验、重试、版本控制与风险提示

很多教程只教你“跑通”，但真正有价值的是从 demo 走向可用产品。

1. 输入字段校验

如果用户只写一句“帮我写仲裁申请书”，模型往往会输出一堆 【待补充】。这虽然没错，但体验不好。

更好的做法是先校验这几个关键字段：

• 文书类型
• 当事人名称
• 核心事实
• 时间
• 金额（如适用）
• 主要诉求

缺少关键字段时，直接提示用户补充，而不是立刻生成。

2. 敏感信息脱敏

法律场景经常涉及身份证号、手机号、银行卡号、住址等个人信息。

强烈建议你在发送给模型前，先做一层脱敏：

• 身份证号只保留前 6 位和后 4 位
• 手机号只保留前三后四
• 银行卡号不直接上传
• 住址可只保留到区县级

不建议直接把完整身份证号、银行卡号等敏感信息输入模型。

3. 增加二次确认节点

尤其在文书正式导出前，建议加一步“人工确认”：

• AI 生成草稿
• 用户预览
• 用户点击“确认导出”
• 再生成正式 Word

这一步会大幅降低“文书看起来像对了，但细节有误”的风险。

4. 模板版本控制

同一个文书类型，往往不止一个模板版本。

比如“劳动仲裁申请书”可能区分：

• 拖欠工资版
• 未签劳动合同版
• 违法解除劳动关系版

你可以在流程里按 doc_type + scene_type 自动切换模板。这样同一条工作流就能复用到多个具体场景。

5. 失败自动重试

法律文书生成有时会遇到这些问题：

• 接口超时
• 返回格式错误
• 某个字段为空
• 模板生成失败

建议给模型调用和文档导出都加上自动重试，至少 1-2 次。很多“偶发报错”其实重试就能恢复。

6. 自动添加风险提示

这一条非常重要，也最容易被忽略。

建议在 closing 字段或文档尾部自动附加这句话：

仅供参考，请结合具体案件事实并由专业人士审核。

别小看这一句，它既是风险提示，也是一个专业系统应有的边界感。

---

3个真实可落地场景：一个流程，多种模板复用

到了这里，你会发现最值钱的不是“生成一份文书”，而是同一条工作流，可以复用到很多结构化文档场景。

场景一：借款催款函

#### 输入需求示例

帮我生成一份借款催款函。借款人李某于2024年1月10日向我借款50000元，约定3个月内归还，至今未还。我希望正式催告其在7日内还款。

#### Deepseek V3 输出逻辑

模型会自动提取：

• 借款关系成立时间
• 借款金额
• 约定还款期限
• 当前违约状态
• 催告期限

#### 最终 Word 效果

输出结果一般会形成：

• 标题：借款催款函
• 当事人信息
• 借款事实
• 违约情况
• 催告请求
• 落款

#### 适合哪些人

• 个体出借人
• 小微企业财务
• 需要留痕催款的商务人员

---

场景二：劳动仲裁申请书

#### 输入需求示例

帮我生成一份劳动仲裁申请书。我在某科技公司工作8个月，公司一直没和我签合同，2024年3月至5月拖欠工资共24000元。我想申请支付拖欠工资和未签劳动合同双倍工资。

#### Deepseek V3 输出逻辑

模型会重点提取：

• 劳动关系时间跨度
• 未签合同事实
• 拖欠工资金额
• 申请请求事项

#### 最终 Word 效果

会形成比较规范的仲裁申请结构，包括：

• 申请人与被申请人
• 事实与理由
• 仲裁请求
• 常规法律依据表达
• 风险提示尾注

#### 适合哪些人

• 劳动者个人
• 劳动争议咨询机构
• 企业内部 HR 合规复核

---

场景三：租赁合同补充协议

#### 输入需求示例

帮我生成一份租赁合同补充协议。原合同租期不变，新增条款是乙方可提前30日书面通知解除合同，但需承担一个月租金作为违约金。

#### Deepseek V3 输出逻辑

模型会识别：

• 原合同关系仍有效
• 本次变更的具体条款
• 解约条件
• 违约责任

#### 最终 Word 效果

相比前两类文书，这类合同补充协议更强调：

• 条款编号
• 表述准确性
• 原合同与补充协议的关系
• 生效方式

#### 适合哪些人

• 房东与租客
• 小型中介机构
• 公司行政/法务辅助场景

---

这套流程为什么容易复制：因为你真正学到的是“结构化生成”方法

如果你把今天这个教程只理解成“AI 写法律文书”，那就低估它了。

更准确地说，你学到的是一套通用方法：

1. 把自然语言需求转成结构化字段

2. 让模型按固定格式输出

3. 把结构化字段填进标准模板

4. 导出成可交付文件

这套方法往外一扩，就能做很多事：

• 合同草拟
• 行政申诉材料
• 客服工单回复
• 企业制度模板生成
• 标书基础内容整理

这也是为什么我一直觉得，AI 真正改变工作的，不是“会不会写”，而是能不能把写出来的东西自动接进流程里。

---

注意事项：法律类 AI 工作流，务必守住这 3 条底线

1. AI 生成内容不等于正式法律意见

2. 涉及诉讼、仲裁、重大合同，务必由专业律师审核

3. 不建议直接输入完整身份证号、银行卡号等敏感信息

如果你把这三条守住，这套流程会非常好用；如果忽略边界，再强的模型也可能把你带进“看起来很专业，实际风险很大”的误区。

---

最后：先把流程跑通，比一开始追求完美更重要

如果你之前没搭过自动化流程，最容易掉进一个坑：上来就想做“最完整版本”。

但真正高效的方式是：

• 先用 Manual Trigger
• 先只做 1 种文书
• 先只保留 7 个字段
• 先导出最简单的 Word 模板
• 跑通以后，再做分类、校验、重试、版本控制

很多时候，从 0 到 1 的关键，不是技术多复杂，而是你愿不愿意先搭一个能工作的最小版本。

如果你准备开始实操，模型接入这一步可以先在 api.884819.xyz 完成。它对新手比较友好，注册门槛低，而且国产模型可以直接用来做这类结构化生成任务。

今天你搭的是法律文书自动生成器；下一步，其实离“真正可交付的 AI 工作流”只差几步：表单收集、PDF 转 Word、自动发送，以及更重要的一层——自动检查文书里的缺项、逻辑漏洞和格式错误。

这也是我特别想继续写的下一篇：如果这次我们解决的是“生成”，那下一篇，就该进入更实用的一步了。

#AI教程 #n8n #DeepseekV3 #法律文书 #自动化工作流 #8848AI #Prompt技巧 #人工智能