本文详细对比了OCR+RAG与VLM在法务文档审核中的优劣，证明OCR+RAG在成本、精度、可追溯性等方面更优。文章基于LangChain1.0+，结合OCR技术提取文档坐标信息，实现了精确到字符级的法务合同审核Agent。通过MinerU解析PDF、智能切分文档、构建专业审核提示词，系统能精准定位问题条款并提供修改建议，完整源码可直接用于企业法务审核场景。
LangChain1.0+OCR+RAG 搭建法务合同审核 Agent（附源码）
一、为什么法务场景需要OCR而非VLM？
在构建文档智能体（Agent）时，我们经常面临一个技术选型的难题：是直接使用视觉语言模型（VLM）“看”文档，还是采用OCR提取文本结合RAG（检索增强生成）的技术路线？
对于政府招投标书（RFP）、行政公文、法律合同等严格格式文档，我们发现OCR+RAG方案在落地效果上远超VLM。这些文档通常动辄数十页，且对条款的位置、内容规范性有极高要求。
核心考量维度如下：
- 文档长度与Token成本
合同和标书通常是多页长文档。以一份20页的劳动合同为例：
- VLM方案：若将PDF转为图像输入，每页约消耗 1000-2000 tokens，整份文档需2-4万tokens，接近许多模型的上下文上限，且图像Token价格昂贵（通常是文本的5-10倍）。
- OCR方案：提取纯文本通常只需 5000-8000 tokens，成本降低 80%以上。
- 精确坐标定位与可追溯性
法务审核的核心需求是精确定位问题条款。
- OCR方案（如MinerU）：解析时返回每个文本块的精确坐标（bbox: [x1, y1, x2, y2]），可精确到字符级，支持后续的高亮批注。
- VLM方案：其返回结果中缺乏精确的坐标映射，通常只能给出模糊的页码或段落描述，无法支持后续的PDF批注、高亮标记等可视化功能。这对于需要生成审核报告并在原文档上标注问题的场景来说是致命缺陷。
- 表格与复杂格式处理
对于合同中常包含表格（如付款计划表、违约金计算表）和复杂格式（如条款编号、多级标题）
- OCR方案：能将其解析为结构化数据（JSON/Markdown），便于后续的计算校验（如金额汇总、日期逻辑检查）。
- VLM方案：VLM 虽然能识别表格，但其输出往往是描述性文本（“表格中显示…”），难以直接用于数值计算和格式校验，需要额外的后处理步骤
方案对比总结
| 对比维度 | OCR + RAG 方案 | VLM 方案 |
| 长文档处理 | 智能切分，无token上限 | 受限于上下文窗口 |
| 成本 | 纯文本token，成本低 | 图像token，成本高5-10倍 |
| 坐标定位 | 精确到字符级别 | 缺乏精确坐标映射 |
| 可追溯性 | 完整的bbox_list | 仅模糊描述 |
| 规则灵活性 | 支持动态规则库（RAG） | 依赖模型内置知识 |
| 表格处理 | 结构化解析，可计算 | 描述性输出，难计算 |
综上，对于 合同、标书等长文档审核场景，OCR + RAG 方案在 成本、精度、可追溯性、灵活性 等多个维度均优于VLM方案。
VLM 更适合短文档、强视觉依赖的场景（如票据识别、图文混排的宣传册审核），法务文档审核这类 "重文本、重逻辑、重定位"的任务，OCR+RAG才是最优选择 。
本文将带你从零实现一个完整的文档审核系统。核心特点是保留 PDF 文档的坐标信息，实现可追溯、可定位的文档审核和修改。
核心流程：
二、效果展示
三、核心代码实现
这里仅展示核心代码实现流程，扫码加入 赋范空间 免费领取完整项目源码，还有更多Agent开发、模型微调等项目案例等你来挖掘！
PDF 解析与坐标提取（核心）
这是系统的基石。MinerU 不仅提取 Markdown 文本，还会返回 content_list，其中包含每个文本片段在 PDF 中的坐标信息。
import
requests
import
json
from
pathlib
import
Path
def parse_pdf_with_mineru(pdf_path: str, output_dir: str = "./temp") -> str:
"""
调用 MinerU API 解析 PDF，关键参数 return_content_list=true
"""
Path(output_dir).mkdir(exist_ok=
True
)
print(
f"开始解析 PDF: {pdf_path}"
)
with
open(pdf_path,
"rb"
)
as
f:
files = [(
"files"
, (Path(pdf_path).name, f,
"application/pdf"
))]
data = {
"backend"
:
"pipeline"
,
"server_url"
: VLLM_SERVER_URL,
"parse_method"
:
"auto"
,
"return_md"
:
"true"
,
"return_content_list"
:
"true"
,
# 关键：返回坐标信息
}
response = requests.post(MINERU_API_URL, files=files, data=data, timeout=
600
)
response.raise_for_status()
result = response.json()
# 保存结果
file_name = Path(pdf_path).stem
json_path = Path(output_dir) /
f"{file_name}_output.json"
with
open(json_path,
"w"
, encoding=
"utf-8"
)
as
f:
json.dump(result, f, ensure_ascii=
False
, indent=
2
)
return
str(json_path)
扫码加入 赋范空间 免费领取完整项目源码及更多项目案例
其中也包括相关的MinerU、PaddleOCR-VL和DeepSeek-OCR的详细介绍以及如何在本地通过vLLM框架启动解析服务
带坐标的文档智能切分
切分策略
- 按标题层级切分: 优先在 # H1, ## H2, ### H3 处切分
- 控制片段大小: 每个片段不超过 800 tokens
- 分配坐标: 根据文本内容匹配对应的坐标信息
关键点：切分后的文本片段，必须保留其对应的原始坐标信息。
切分示例
MinerU 返回的原始数据：按照行、段落、表格单元格等自然单位切分的。
{
"content_list"
: [
{
"text"
:
"解除劳动合同通知书"
,
"bbox"
: [
359
,
95
,
638
,
120
],
"page_idx"
:
0
},
{
"text"
:
"先生/小姐"
,
"bbox"
: [
199
,
164
,
373
,
181
],
"page_idx"
:
0
},
{
"text"
:
"根据 << 劳动合同法..."
,
"bbox"
: [
170
,
200
,
847
,
255
],
"page_idx"
:
0
},
// ... 共
219
个文本块
]
}
重新切分 (chunk_size=800)：
- 核心逻辑：一个Chunk → 多个BBox: 每个原始文本块都有自己精确的坐标
Chunk
1
(
831
tokens):
内容:
"解除劳动合同通知书\n\n先生/小姐\n\n根据<<劳动合同法>>..."
bbox_lis
t:
[
{bbox: [
359
,
95
,
638
,
120
], tex
t:
"解除劳动合同通知书"
},
{bbox: [
199
,
164
,
373
,
181
], tex
t:
"先生/小姐"
},
{bbox: [
170
,
200
,
847
,
255
], tex
t:
"根据..."
},
// ... 共
86
个原始文本块的坐标
]
后续的审核逻辑：
issue = {
"original"
:
"年 月 日至 年 月 日"
,
# 有问题的原文
"description"
:
"日期填写不完整"
}
# 在chunk的bbox_list中查找匹配的坐标
for
bbox_item
in
chunk[
'bbox_list'
]:
if
"年 月 日至 年 月 日"
in
bbox_item[
'text'
]:
problem_bbox = bbox_item[
'bbox'
]
# 找到了！
problem_page = bbox_item[
'page_idx'
]
# 可以在PDF上精确高亮这个位置
核心代码实现
我们实现一个 split_document_with_coords 函数，它会在切分 Markdown 文本的同时，遍历原始的 content_list，将坐标映射到对应的 Chunk 中。
from
typing
import
Dict, Any, List
def split_document_with_coords(
md_content: str,
content_list: List[Dict],
chunk_size: int = 800
) -> List[Dict[str, Any]]:
"""
切分文档并精确分配坐标（核心逻辑）
"""
# 1. 简单的按段落切分文本
paragraphs = md_content.split(
'\n\n'
)
chunks = []
current_chunk =
""
chunk_start_positions = []
# ... (省略部分基础文本拼接代码，详见完整源码) ...
# 2. 为每个chunk分配坐标
# 逻辑：遍历content_list中的每个bbox，看它的text属于哪个chunk
result = []
for
i, chunk_text
in
enumerate(chunks):
bbox_list = []
for
item
in
content_list:
if
item.get(
'type'
) ==
'text'
:
text = item.get(
'text'
,
''
).strip()
if
not
text:
continue
# 在原文中查找这个text的位置
text_pos = md_content.find(text)
if
text_pos ==
-1
:
# 尝试规范化匹配
normalized_text = normalize_text(text)
normalized_md = normalize_text(md_content)
text_pos = normalized_md.find(normalized_text)
# 判断这个text属于哪个chunk
if
text_pos !=
-1
:
chunk_start = chunk_start_positions[i]
chunk_end = chunk_start + len(chunk_text)
# 如果text在当前chunk的范围内
if
chunk_start <= text_pos < chunk_end:
bbox_list.append({
'type'
: item.get(
'type'
),
'bbox'
: item.get(
'bbox'
),
'page_idx'
: item.get(
'page_idx'
),
'text'
: text,
'content_preview'
: text[:
50
]
})
result.append({
'content'
: chunk_text,
'token_count'
: estimate_tokens(chunk_text),
'bbox_list'
: bbox_list
# 实现了文本到坐标的绑定
})
return
result
构建审核 Agent 的提示词
我们将法务审核标准固化为 Prompt 中的 Context。这里仅展示一小部分，完整见项目源码，也可根据你的场景进行自定义
PROFESSIONAL_CONTRACT_AUDIT_RULES =
""
"
# 合同协议书专业审核规则
## 一、文本规范性审核（P1-P2级）
###
1.1
错别字与形近字检查
- 形近字：
"己"
/
"已"
/
"以"
、
"的"
/
"地"
/
"得"
、
"做"
/
"作"
、
"账"
/
"帐"
- 多字、漏字、笔误
- 严重程度：medium
###
1.2
标点符号规范性
- 标点符号正确使用（句号、逗号、顿号、分号、冒号）
- 括号、引号配对
- 合同特殊要求：金额数字后不加顿号、条款编号后统一标点
- 严重程度：low
......
""
"
PROFESSIONAL
_USER_
PROMPT = """请对以下合同协议书片段进行专业审核：
【待审核文本】
{text}
【审核要求】
1.
严格按照《合同协议书专业审核规则》逐条审查
2.
重点关注P0级问题（法律风险、权利义务、金额数字、逻辑一致性）
3.
对于每个发现的问题：
- 精确引用原文位置
- 说明违反的具体规则
- 评估严重程度和法律风险
- 给出专业的修改建议
4.
生成修正后的完整文本
5.
编写审核总结
【特别说明】
1.
如果发现书名号显示为 $
< <$ 和 $1gt;
>$ 等符号，这是OCR识别错误，应归类为【OCR识别问题】而非【法律术语规范性】问题
2.
对于明显的OCR错误（如特殊符号、乱码），请在modifications中提供正确版本，但在issues中标注为"OCR识别错误"
3.
只有当原文确实使用了错误的标点符号时，才归类为【法律术语规范性】问题
请输出审核结果（JSON格式）。
【输出格式】
以JSON格式返回AuditResult对象，确保：
-
has_issues: 是否发现问题（布尔值）
-
issues: 问题列表（按严重程度排序）
-
modifications: 修改映射列表
-
corrected_text: 修正后的完整文本
-
summary: 审核总结
-
overall
_risk_
level: 整体风险等级（high/medium/low/none）
请开始审核。
"""
基于langChain构建审核 Agent
from
langchain_openai
import
ChatOpenAI
from
langchain_core.prompts
import
ChatPromptTemplate
# 创建 LLM
llm = ChatOpenAI(
model=
"qwen3-max"
,
temperature=
0.1
,
)
# 使用结构化输出
structured_llm = llm.with_structured_output(AuditResult)
# 定义 Prompt
audit_prompt = ChatPromptTemplate.from_messages([
(
"system"
, PROFESSIONAL_SYSTEM_PROMPT),
(
"user"
, PROFESSIONAL_USER_PROMPT)
])
# 创建审核链
audit_chain = audit_prompt | structured_llm
执行审核与结果展示
执行审核代码
将切分好的 Chunk 传入 Agent，即可获得包含法律风险分析、修改建议及原文引用的结构化数据。
try
:
print
(
"\n正在调用专业审核系统..."
)
result = audit_chain.invoke({
"rules"
: PROFESSIONAL_CONTRACT_AUDIT_RULES,
"text"
: chunks[
0
]
})
对审核结果进行解析：
print(
"\n审核成功！"
)
print(
"\n"
+
"="
*
80
)
print(
"【审核结果概览】"
)
print(
"="
*
80
)
print(
f"是否发现问题: {result.has_issues}"
)
print(
f"整体风险等级: {result.overall_risk_level}"
)
print(
f"问题总数: {len(result.issues)}"
)
print(
f"修改总数: {len(result.modifications)}"
)
print(
f"\n审核总结: {result.summary}"
)
if
result.has_issues:
# 按严重程度分组
high_issues = [i
for
i
in
result.issues
if
i.severity ==
'high'
]
medium_issues = [i
for
i
in
result.issues
if
i.severity ==
'medium'
]
low_issues = [i
for
i
in
result.issues
if
i.severity ==
'low'
]
print(
"\n"
+
"="
*
80
)
print(
"【问题详情】"
)
print(
"="
*
80
)
if
high_issues:
print(
f"\n高风险问题 ({len(high_issues)} 个)："
)
print(
"-"
*
80
)
for
i, issue
in
enumerate(high_issues,
1
):
print(
f"\n{i}. [{issue.rule_category}] {issue.issue_type}"
)
print(
f" 描述: {issue.description}"
)
print(
f" 原文: {issue.original}"
)
print(
f" 建议: {issue.suggestion}"
)
if
issue.legal_risk:
print(
f" ⚠️ 法律风险: {issue.legal_risk}"
)
if
medium_issues:
print(
f"\n中风险问题 ({len(medium_issues)} 个)："
)
print(
"-"
*
80
)
for
i, issue
in
enumerate(medium_issues,
1
):
print(
f"\n{i}. [{issue.rule_category}] {issue.issue_type}"
)
print(
f" 描述: {issue.description}"
)
print(
f" 原文: {issue.original}"
)
print(
f" 建议: {issue.suggestion}"
)
if
low_issues:
print(
f"\n低风险问题 ({len(low_issues)} 个)："
)
print(
"-"
*
80
)
for
i, issue
in
enumerate(low_issues,
1
):
print(
f"\n{i}. [{issue.rule_category}] {issue.issue_type}"
)
print(
f" 描述: {issue.description}"
)
print(
f" 原文: {issue.original}"
)
print(
f" 建议: {issue.suggestion}"
)
if
result.modifications:
print(
"\n"
+
"="
*
80
)
print(
f"【修改记录】({len(result.modifications)} 处)"
)
print(
"="
*
80
)
for
i, mod
in
enumerate(result.modifications,
1
):
print(
f"\n修改 {i}:"
)
print(
f" 原文: {mod.original}"
)
print(
f" 修改: {mod.modified}"
)
print(
f" 原因: {mod.reason}"
)
if
mod.rule_ref:
print(
f" 规则: {mod.rule_ref}"
)
print(
"\n"
+
"="
*
80
)
print(
"【修正后的文本】"
)
print(
"="
*
80
)
print(result.corrected_text)
else
:
print(
"\n文档无问题！"
)
print(
"\n"
+
"="
*
80
)
print(
"测试通过！数据结构完全兼容！"
)
print(
"="
*
80
)
except
Exception
as
e:
print(
f"\n测试失败！"
)
print(
f"\n错误类型: {type(e).__name__}"
)
print(
f"错误信息: {e}"
)
print(
"\n完整错误堆栈:"
)
import
traceback
traceback.print_exc()
结果展示
正在调用专业审核系统...
审核成功！
================================================================================
【审核结果概览】
================================================================================
是否发现问题:
True
整体风险等级: high
问题总数:
10
修改总数:
6
审核总结: 本次审核发现该劳动合同相关文书模板存在多项高风险问题：
1
) 法律术语使用不当，
'通知书'
应改为
'决定书'
；
2
) 主体信息缺失，未填写员工姓名和身份证号；
3
) 经济补偿金表述不规范且适用情形错误；
4
) 关键日期和金额空白；
5
) 存在严重歧义性表述。此外还有文本重复、标点不规范等中低风险问题。整体风险等级为high，建议全面修订后再使用。
================================================================================
【问题详情】
================================================================================
高风险问题 (
6
个)：
--------------------------------------------------------------------------------
1.
[法律术语规范性] 法律术语使用不当
描述: 多处使用
'解除劳动合同通知书'
作为单方通知文件名称，但根据《劳动合同法》，用人单位单方解除劳动合同应出具
'解除劳动合同决定书'
或类似具有决定性质的文书，
'通知书'
易被理解为告知而非决定，可能影响法律效力。
原文: 解除劳动合同通知书
建议: 建议统一修改为
'解除劳动合同决定书'
或
'关于解除劳动合同的决定'
，以体现用人单位单方解除行为的法律性质。
2.
[权利义务对等性] 主体信息缺失
描述: 所有文书模板中均未填写员工姓名、身份证号等关键身份信息，仅以
'先生/小姐'
或空白代替，违反《劳动合同法》关于明确劳动关系主体的要求，可能导致文书无效。
原文: 先生/小姐
建议: 应在每份文书开头明确填写员工全名，并在乙方信息处完整填写身份证号码，确保主体明确。
3.
[金额与数字准确性] 经济补偿金表述不规范
描述: 多处经济补偿金条款仅写
'计 元'
，未同时采用大小写金额，且未明确计算依据（如月工资标准），不符合《工资支付暂行规定》关于金额书写规范的要求，易引发争议。
原文: 计 元
建议: 应补充为
'计人民币【大写】元整（¥【小写】）'
，并注明计算基数（如
'按离职前12个月平均工资计算'
）。
4.
[必备条款完整性] 关键日期缺失
描述: 所有模板中的日期字段（如
'年 月 日'
）均为空白，未设置默认格式或填写说明，不符合合同成立的基本要件，可能导致文书无效。
原文: 年 月 日
建议: 应统一格式为
'____年__月__日'
，并在使用说明中要求必须填写具体日期。
5.
[法律合规性] 经济补偿金适用情形错误
描述: 在
'劳动合同到期终止通知书'
中直接规定
'公司需要支付给您相当于 月工资的经济补偿'
，但根据《劳动合同法》第
46
条，劳动合同期满终止时，仅在用人单位不同意续订或降低条件续订而劳动者不同意的情况下才需支付经济补偿。此处表述过于绝对，可能构成违法承诺。
原文: （
2
）此种情况下：公司需要支付给您相当于 月工资的经济补偿，计元。
建议: 应修改为选择项：
'□ 因公司不同意续订劳动合同，需支付经济补偿金...；□ 因公司维持或提高原条件续订而您不同意，无需支付经济补偿金'
。
6.
[表述清晰度] 歧义性表述
描述:
'协商解除劳动合同协议书'
第二条
'计 元方支付 方经济补偿金 元'
存在严重语病和歧义，无法判断支付主体和金额对应关系。
原文: 二、乙方薪资结算至 年 月 日；计 元方支付 方经济补偿金 元；
建议: 应明确为
'乙方薪资结算至____年__月__日，共计人民币____元；甲方支付乙方经济补偿金人民币____元'
。
中风险问题 (
2
个)：
--------------------------------------------------------------------------------
1.
[逻辑一致性] 条款重复冗余
描述: 文档中
'协商解除劳动合同协议书'
、
'劳动合同到期终止通知书'
等模板重复出现两次，内容完全相同，属于明显的文本冗余，可能造成使用混乱。
原文: 协商解除劳动合同协议书...（全文重复）
建议: 删除重复的模板，保留一份即可。
2.
[必备条款完整性] 缺少法律依据引用
描述: 部分解除/终止情形未准确引用法律条款，如
'过失性解除'
选项虽内容正确，但未注明对应《劳动合同法》第
39
条，不利于员工知悉权利。
原文: （
1
）过失性解除 口在试用期内证明不符合录用条件的；...
建议: 应在每类解除情形后注明法律依据，如
'（依据《劳动合同法》第39条）'
。
低风险问题 (
2
个)：
--------------------------------------------------------------------------------
1.
[文本规范性] 标点符号不规范
描述: 多处顿号、逗号使用不规范，如
'口不予支付经济补偿金； 口公司需要支付...'
中分号应为句号或换行，且选项间应统一使用顿号或分行排列。
原文: 口不予支付经济补偿金； 口公司需要支付...
建议: 每个选项应独立成行，末尾不加标点，或统一使用顿号分隔。
2.
[OCR识别问题] 特殊符号错误
描述: 《劳动合同法》书名号显示正常，但部分空格不规范，如
'《 劳动合同法 》'
，属OCR识别导致的多余空格。
原文: 《 劳动合同法 》
建议: 修正为
'《劳动合同法》'
，去除多余空格。
================================================================================
【修改记录】(
6
处)
================================================================================
修改
1
:
原文: 解除劳动合同通知书
修改:
原因: 法律术语规范性要求
规则:
2.1
法律术语规范性
修改
2
:
原文: 先生/小姐
修改:
原因: 明确合同主体
规则:
4.3
必备条款完整性
修改
3
:
原文: 计 元
修改:
原因: 金额书写规范
规则:
2.3
金额与数字准确性
修改
4
:
原文: 二、乙方薪资结算至 年 月 日；计 元方支付 方经济补偿金 元；
修改:
原因: 消除歧义，明确支付关系
规则:
5.1
歧义性表述
修改
5
:
原文: 《 劳动合同法 》
修改:
原因: OCR识别错误修正
规则: OCR识别问题
修改
6
:
原文: （
2
）此种情况下：公司需要支付给您相当于 月工资的经济补偿，计元。
修改:
原因: 符合法律规定，避免违法承诺
规则:
4.1
法律合规性
================================================================================
【修正后的文本】
================================================================================
# 解除劳动合同决定书
【员工姓名】先生/女士
根据《劳动合同法》相关规定，公司依法解除此前您与公司订立的劳动合同(合同期限: ____年__月__日至____年__月__日)。解除您的理由是：
（
1
）过失性解除（依据《劳动合同法》第
39
条）
□ 在试用期内证明不符合录用条件的；
□ 严重违反公司依法制定的规章制度的；
□ 严重失职，营私舞弊，给用人单位造成重大损害的；
□ 以欺诈、胁迫的手段使用人单位违背真实意思签订劳动合同致使劳动合同无效的；
□ 员工同时与其他用人单位建立劳动关系，对完成本单位的工作任务造成严重影响，或者经用人单位提出，拒不改正的；
□ 被依法追究刑事责任的；
（
2
）非过失性解除（依据《劳动合同法》第
40
条）
□ 劳动合同订立时所依据的客观情况发生重大变化，致使原合同无法履行，经当事人协商不能就变更合同达成协议的；
□ 员工不能胜任工作，经过培训或者调整工作岗位，仍不能胜任的；
□ 员工患病或非因工负伤，医疗期满后不能从事原工作，也不能从事由公司安排的其他工作；
（
3
）经济性裁员（依据《劳动合同法》第
41
条）
□ 依据企业破产法规定进行重整的；
□ 生产经营发生严重困难的；
□ 公司转产、重大技术革新或者经营方式调整，经变更劳动合同后仍需裁员的；
□ 其他因劳动合同订立时所依据的客观经济情况发生重大变化，致使劳动合同无法履行的。
您的劳动合同于____年__月__日解除。您需要结算以下薪资和补偿金事项：
（
1
）您薪资结算至____年__月__日；计人民币【大写】元整（¥【小写】）
（
2
）此种情况下：
□ 不予支付经济补偿金；
□ 公司需要支付给您相当于【】个月工资的经济补偿，计人民币【大写】元整（¥【小写】）。
您需要按照公司的离职管理制度规定办理离职手续。
通知单位（盖章）
通知时间：____年__月__日
说明：本通知一式二份，送达劳动者一份，用人单位留存一份，涂改无效。
送达记录：受送达人签字： 签收时间：
---
协商解除劳动合同协议书
甲 方：AA公司
乙 方：【员工姓名】（员工身份证号：【身份证号码】）
甲、乙双方于____年__月__日签订了有/无固定期限劳动合同，现由【甲/乙】方提出协商解除劳动合同要求，经甲、乙双方协商一致，同意解除劳动合同，并达成如下协议：
一、解除劳动合同的日期为：____年__月__日；
二、乙方薪资结算至____年__月__日，共计人民币【大写】元整（¥【小写】）；甲方支付乙方经济补偿金人民币【大写】元整（¥【小写】）；
三、【其他约定事项】；
四、本协议自甲、乙双方签字（盖章）后生效；
五、本协议一式两份，甲、乙双方各执一份，具有同等法律效力，涂改无效。
甲方（盖章）： 乙方（签字）：
法定代表人或委托代理人（签字盖章）：
签约日期：____年__月__日 签约日期：____年__月__日
---
劳动合同到期终止通知书
【员工姓名】先生/女士
公司与您订立的劳动合同（____年__月__日至____年__月__日），即将届满。根据国家和地方相关法律、法规、政策以及劳动合同相关约定，经公司管理层批准，依法与您终止劳动合同。
您需要结算以下薪资和补偿金事项：
（
1
）您薪资结算至____年__月__日；计人民币【大写】元整（¥【小写】）
（
2
）此种情况下：
□ 因公司不同意续订劳动合同，需支付经济补偿金，相当于【】个月工资，计人民币【大写】元整（¥【小写】）；
□ 因公司维持或提高原劳动合同约定条件续订而您不同意，不予支付经济补偿金。
您需要按照公司的离职管理制度规定办理离职手续。
通知单位（盖章）
通知时间：____年__月__日
说明：本通知一式二份，送达劳动者一份，用人单位留存一份，涂改无效。
送达记录：受送达人签字： 签收时间：
---
[其余文书模板按相同原则修正，删除重复内容，补充主体信息、规范金额表述、明确法律依据]
================================================================================
测试通过！数据结构完全兼容！
================================================================================
四、总结
通过 MinerU (OCR) + Smart Chunking (坐标映射) + LLM (Structured Output) 的组合，我们成功构建了一个具备企业级能力的法务审核 Agent
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线科技企业深耕十二载，见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事，早已在效率与薪资上形成代际优势，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套 AI 大模型突围资料包：
- ✅ 从零到一的 AI 学习路径图
- ✅ 大模型调优实战手册（附医疗/金融等大厂真实案例）
- ✅ 百度/阿里专家闭门录播课
- ✅ 大模型当下最新行业报告
- ✅ 真实大厂面试真题
- ✅ 2025 最新岗位需求图谱
所有资料 ⚡️ ，朋友们如果有需要 《AI大模型入门+进阶学习资源包》，下方扫码获取~
① 全套AI大模型应用开发视频教程
（包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点）
② 大模型系统化学习路线
作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！
③ 大模型学习书籍&文档
学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。
④ AI大模型最新行业报告
2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。
⑤ 大模型项目实战&配套源码
学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。
⑥ 大模型大厂面试真题
面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。
以上资料如何领取？
为什么大家都在学大模型？
最近科技巨头英特尔宣布裁员2万人，传统岗位不断缩减，但AI相关技术岗疯狂扩招，有3-5年经验，大厂薪资就能给到50K*20薪！
不出1年，“有AI项目经验”将成为投递简历的门槛。
风口之下，与其像“温水煮青蛙”一样坐等被行业淘汰，不如先人一步，掌握AI大模型原理+应用技术+项目实操经验，“顺风”翻盘！
这些资料真的有用吗？
这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。
以上全套大模型资料如何领取？
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
