非视觉模型阅读 PDF 的信息损失与解决路径 ——基于律所办公的实际心得

我上传了一份30页的股权转让协议PDF，让大模型调用skill帮我梳理法律关系和核心条款。模型输出看起来头头是道：付款节奏、违约责任、交割条件都列得清清楚楚。

但我后来对照原文才发现——协议附件里的对价计算表，有三行金额被填到了错误的列；第17页手写补充条款的“万”字被识别成了“方”，整个条款的意思完全变了；而盖在金额栏上的那枚红色校对章，大模型从头到尾就不知道它存在。

其实模型不是故意糊弄我。问题出在我把PDF交给它的那一刻——它根本没有“看”到我的PDF，它拿到的东西，已经在这条流水线上丢失了大量关键信息。

原因是目前大多数大模型没有视觉能力。这类模型只能处理纯文字，不能处理图片。所以当我上传一份PDF或扫描件时，系统必须走一条绕路：

我上传的PDF/图片

↓

第一步：OCR（光学字符识别）把图片上的文字"认"出来，输出纯文本

↓

第二步：把纯文本喂给大模型，让它分析理解

↓

大模型给我回答

所以，大模型从头到尾没有见过我的原文件。它拿到的只是一串纯文字——就像一个蒙着眼睛的助理，只能听别人把合同念给他听。念的人可能念错、念串行、漏掉表格结构，甚至完全跳过某几页。而这位助理无法自己翻开原件核对，还自信地给了我一份“审查意见”。而初入大模型辅助的我，甚至会傻乎乎要求大模型将该工作流留存以便下次使用。

到底为什么OCR不行？

理解OCR，它的运作可以拆成四个动作：

步骤	做什么	法律场景中的实际含义
① 图片化	如果是 PDF，先把每一页渲染成一张图片	一份 Word 导出的 PDF 合同，系统先把它“拍”成图片
② 区域检测	在图片中识别“哪里是文字区域”	找出正文、页眉、表格、签名栏各自的位置
③ 字符识别	逐个比对像素形状，猜“这是什么字”	看到某个像素形状，判断是“末”还是“未”——这两个字在法律语境下差别巨大
④ 拼成文本	把识别出的字符按行拼接，输出纯文字	文本的顺序、换行、缩进完全取决于 OCR 的判断

API拿到的是什么？

以一份标准的股权转让协议为例，OCR 处理完，喂给大模型的内容大致是这样的（真实情况可能更混乱）：

股权转让协议

甲方（转让方）：张三

乙方（受让方）：李四

第3页/共12页

第一条标的股权

1.1甲方同意将其持有的目标公司30%股权转让给乙方

1.2转让价款及支付方式如下表所示

项目金额（万元）支付时间

首期款500工商变更完成后5个工作日内

第二期款300标的股权交割日后30日内

尾款2002025年12月31日前

甲方（盖章）乙方（盖章）

看起来似乎还行，但仔细看看：

表格的列对应关系已经混乱——“项目”“金额（万元）”“支付时间”三列的对应，我还能靠常识猜，但如果是更复杂的对价计算表呢？

“第3页/共12页”是页脚，但和正文拼在了一起

签名栏没有位置信息——“张三”签在哪个栏？是甲方还是乙方？OCR 输出里，这行字下面紧接着是“乙方（盖章）”，但原文中它们分别在页面的左右两端

如果页面上有任何手写批注、印章、高亮标记——它们要么变成乱码，要么直接消失

这就是我要讨论的核心问题：在这条“图片→纯文字→大模型”的路径上，文件的信息被分两层逐步丢失。下面逐层拆解。

第一层损失：PDF 变成纯文字的过程中，丢了什么？

这一层的问题发生在 OCR 环节——也就是“把图片上的字认出来”这一步。它产生的错误和信息丢失，是在大模型还没介入之前就已经发生了的。

问题一文书结构逻辑混乱：

（1）表格：法律文书中最常见的重灾区

合同中的付款计划表、股权结构表、资产清单、对价计算表——这些是 OCR 出错率最高的区域。原因在于，OCR 是“从左到右、从上到下”逐行扫描的，它不理解“列”的概念。

举个例子，原文是一张简单的付款计划表：

付款节点	金额（万元）	支付条件	最迟支付日
首期款	500	工商变更完成	2025-06-30
第二期	300	审计报告出具	2025-09-30
尾款	200	交割完成	2025-12-31

OCR 从左到右扫过去，可能输出成：

付款节点金额（万元）支付条件最迟支付日

首期款 500 工商变更完成 2025-06-30

第二期 300 审计报告出具 2025-09-30

尾款 200 交割完成 2025-12-31

在这个简单例子中，多亏每行只有4列且长度均匀，输出看起来似乎正常。但如果表格包含合并单元格呢？比如“付款节点”列的首期款和第二期合并为一个大的“前期付款”单元格，OCR的输出就会变成：

前期付款 500 工商变更完成 2025-06-30

第二期 300 审计报告出具 2025-09-30

第一行合并单元格的“前期付款”只出现了一次，第二行的“300”就失去了自己所属的节点名称——行与列的对应关系断裂了。大模型拿到这样的文本，会自行“脑补”对应关系，而这种脑补可能完全错误。

更隐蔽的情况是：表格里的数字被错位。比如资产清单中，“资产编号”列的数字被 OCR 认到了“账面价值”列，乍看之下数字本身都是合理的，但律师核查时才会发现编号和金额对不上号。

（2）条款层级体系消失

一份规范的合同，条款编号层级往往是这样的：

第一条定义

1.1在本协议中，除非上下文另有规定，下列词语具有如下含义：

1.1.1“交割日”：指......

1.1.2“重大不利影响”：指......

原文通过字体加粗、字号大小、缩进距离，让读者一眼看出“第一条 > 1.1 > 1.1.1”的层级关系。但 OCR 输出后，所有文字字号相同、无加粗、无缩进：

第一条定义

1.1在本协议中，除非上下文另有规定，下列词语具有如下含义：

1.1.1 "交割日"：指......

1.1.2 "重大不利影响"：指......

大模型拿到这段文本，它靠编号模式（1. / 1.1 / 1.1.1）通常能推断层级。但我无法保证每份合同的编号体系都如此规整——有些合同使用（一）/ 1. / (1) / ①的四级混合编号，有些条款在不同层级之间插入了条件从句。OCR输出的纯文字中，这些结构标记往往丢失。

这个问题在审查合同中的“背离条款”时尤其危险。一份主协议的核心条款，可能被一份补充协议中某个三级子条款修改甚至废止。如果OCR丢失了层级信息，大模型可能把“第3.2.1条”和“第3.2条”的关系读错——把子条款的例外情况，理解成主条款本身的修改。

（3）页眉页脚和页码混入正文

OCR 不知道什么是页眉页脚。对它来说，页面上所有的字都是平等的。所以一份合同的每页底部印的“第 X 页 / 共 Y 页”“机密文件”“XX 律师事务所”，会像正文一样被拼进段落中间。

我以为大模型看到的是连续的法条条款，实际上它拿到的是：

......乙方应于交割日前完成上述事项。

第4页/共12页

第五条违约责任

5.1任何一方违反本协议......

“第4页 / 共12页”这个字符串隔在了第四条和第五条之间。虽然大模型通常能跳过这个干扰，但如果页码恰好落在了某个条款的关键句子中间（比如分隔了主句和但书），它就可能把一句话拆成两段来理解。

（4）签名页和正文之间的分隔丢失

这是法律场景中一个特别重要的问题。合同的最后一页通常是签名页，正文在签名页之前结束。但 OCR 输出会把签名页的内容直接接在正文末尾，中间没有任何分界标记。更麻烦的是，如果签名页上方还有一个“（本页以下无正文，为签署页）”的声明，这个声明在 OCR 输出中会变成正文段落的最后一句，大模型可能把它理解为某个条款的一部分。

问题二：手写内容几乎无法识别

法律文件中的手写内容常见于：当事人手写签注的合同条款、仲裁庭庭审笔录、对方律师在文件上的手写批注、证据材料上的手写说明。这些场景下，手写文字的识别质量直接决定了后续分析的正确性。

传统OCR对手写体的准确率通常不到60%。因为OCR引擎是基于“标准印刷字体”训练的——它学的是宋体、黑体、Times New Roman的笔画规律，而不是真人手写的连笔习惯。

实际场景中更棘手的是印刷体与手写体混合的情况：一份已签署的合同，正文是打印的，但双方在空白处手写了补充条款，在签字栏签了名字。OCR不区分来源，它会把手写内容当作正文的一部分输出——而且因为识别率低，手写部分输出的可能是半通不通的句子。大模型看到这些“乱码”，要么跳过（丢失关键条款），要么根据上下文强行理解（可能完全偏了）。

还有一种情况：手写批注的指向关系。对方律师在合同稿上用箭头、圈画、波浪线标记了需要修改的地方，并在旁边写了批注。OCR可能会识别出批注的文字，但那个“箭头指向哪个条款”的信息——纯文字根本无法表达。

问题三：跨页和跨文件的上下文断裂

（1）跨页表格

这是 OCR 最经典的失败模式。同一张表格跨了两页，第二页通常会重复表头。OCR 不知道这张表在延续，它看到第二页的表头，以为是新的一张表从头开始。

以一份资产收购协议的附件——资产清单为例，这个表格有 40 行，跨了 3 页。OCR 处理后，大模型会认为这是 3 张不同的表。当律师问“请列出所有资产的账面价值和评估价值”，大模型可能只根据第一张表回答，后两页的数据“在它眼里不属于同一张表”。

（2）合同与附件的引用断裂

一份股权转让协议的典型结构是：

主协议（20页）

├── 附件一：标的公司股权结构表

├── 附件二：资产清单

├── 附件三：重大合同清单

└── 附件四：对价计算表

主协议正文中充满了“见附件一”“按照附件四的计算方式”“附件二所列资产”——这些是跨文件的引用链接。

但当我把这些文件上传给非视觉模型时，通常主协议和附件是作为独立文件分别处理的。系统不知道“附件一”和主协议是同一份交易文件的不同部分。主协议中写的“详见附件一第3项”，在大模型那里只是一个无法跳转的文字描述。它只能凭记忆（如果附件一的内容恰好在同一个上下文窗口里）或者猜测来回答，无法精确关联。

（3）多份文件之间的实体关联

一个 M&A 项目可能涉及：股转协议 + 章程修正案 + 股东会决议 + 债权债务公告 + 多份补充协议。这些文件中的当事人名称、金额、日期、条款编号需要对照审查——甲方在股转协议中承诺的转让价款，是否和股东会决议中记载的一致？补充协议是否实质性修改了原协议的付款节奏？再举个诉讼的例子，当事人提交了一份证据为签署版书面租赁合同，期限仅一年，证明目的是租赁关系存在。租赁关系没有其他书面合同支持，故超过期限转为不定期租赁，主给付义务如租金支付条款一般不变，但仍需交付惯例证明。交付惯例可以通过转账记录来证明，但一份超过期限的合同，几张没有说明转账目的的转账记录，大模型能够跨文件联动思考吗？

非视觉模型（难道说是鲸某？）处理这件事的困境是：每份文件是独立走完“OCR→纯文本”流程的，文件之间的引用关系不在任何一份文件的文字内容中。律师需要的是一个能跨文件关联比对的能力，而传统路径只能做到“每份文件各看各的”。

第二层损失：即使文字100%识别正确，大模型也看不到什么？

第一层问题是OCR没认对。但如果OCR百分百完美呢？不幸的是，仍然有大量关键信息，在“图片”变成“文字”的那一瞬间，就不可逆地消失了。下面这些信息，无论OCR准确率多高，都不可能出现在最终喂给大模型的纯文本中：

其一、签名与印章的空间位置

这是法律工作中最核心的视觉判断之一。

一份合同签名页上，左右两栏分别写着“甲方（盖章）：”和“乙方（盖章）：”。张三的签名签在哪一栏，决定了他在合同中的身份。OCR 输出是这样的：

甲方（盖章）：乙方（盖章）：

张三李四

这看起来还清楚——“张三”在“甲方”下面，“李四”在“乙方”下面。但如果签名栏的布局稍微复杂一点：

实际签名位置在页面偏左，恰好和“乙方”在垂直方向上更接近

签名使用了艺术字体或图案化签章，OCR 在排版判断时可能把两人的身份对调

甚至，如果一方签名的位置恰好超出了自己的栏目边界，挤到了对方的区域——这种“异常空间位置”本身就值得律师注意，但纯文字输出不会告诉我

印章的识别也面临类似问题。法律实践中，印章的位置、覆盖范围、清晰度、重叠情况都可能具有法律含义。合同签订地的公章、骑缝章是否完整贯穿每一页——这些信息在OCR输出中不存在。

更关键的：当印章和签名重叠时。一份合同上，法人签字恰好被公司公章覆盖了一部分。OCR会尝试“透过”印章识别签名，但往往以失败告终——要么输出乱码，要么干脆跳过被覆盖的部分。而大模型不知道这里缺失了什么。

其二、修改痕迹与修订标记

对方发来一份修改后的合同，使用了 Word 的“修订模式”或者 PDF 的标注功能——删除的内容用删除线标记，新增的内容用下划线标记，部分条款旁边有批注气泡。

当我把这份PDF交给OCR处理，删除线和下划线在视觉上是可见的标记，但OCR不认识它们。纯文字输出中，删除的内容和新加的内容变成了前后相连的句子，完全看不出这是两个互斥的版本。

举个例子，原条款是：

违约金为合同总金额的10%20%。

OCR输出：违约金为合同总金额的10% 20%。

大模型理解：违约金有两种可能，10%和20%。（它可能会问我是哪一个，但如果上下文里这类歧义太多，它会自行选一个，或者把两个都列出来但不做判断。）

更严重的是——如果修改痕迹本身具有法律意义。比如在争议中，一方主张合同某条款已被对方在修订中删除，因此不构成合意。但 OCR 输出让删除痕迹消失了，大模型根本不知道这个条款曾经经历过修改。

其三、高亮、颜色标记与视觉强调

合同审查中，律师经常用颜色做区分标记：

黄色高亮：需要重点关注的条款

红色标注：存在重大风险的条款

绿色标注：已确认无问题的条款

一份合同中，有一段以小号灰色字体印刷在末尾的免责声明。在视觉上，这段文字被故意弱化——字号更小、颜色更浅、位置更偏——这些特征本身就反映了起草方的意图（“让我不容易注意到”）。但在纯文字输出中，这段免责声明和前面正文的标题、条款，权重完全一样。大模型无法判断“这段文字原文被故意弱化了”。

加粗和斜体当然也传达法律意义。很多合同的“定义条款”中，定义的术语在正文中出现时会以加粗标记，以区分“作为定义术语的使用”和“一般语境的使用”。纯文字丢失了这个区分，可能导致大模型把一般用法误读为定义用法。

如前所述但又有所不同：证据材料中的照片和截图

诉讼或仲裁中，证据材料经常包含：

微信/钉钉聊天记录截图

现场照片（损害状况、施工进度、货物状态）

邮件截图

财务系统中的数据界面截图

聊天记录截图中的文字是像素组成的图像，不是可选择、可复制的文字。OCR需要先识别截图中的文字，然后才能喂给大模型。但聊天截图的排版结构（谁说了哪句、时间戳、头像对应关系）远非简单的“段落文字”，OCR处理后的输出往往把人名、时间、内容混在一起，看不出对话的先后顺序。

现场照片和财务界面截图的问题更根本——它们传达的核心信息就是视觉本身。一张工地照片显示了明显的结构缺陷，这个“缺陷”是通过形状、对比、空间关系表达的，不是通过文字表达的。如我经手的案件经常有各种对方举证的损失照片，包括污损，水浸等。虽然证据照片上墙面大量返潮，但是照片明显是公共楼道的狭长空间，或者污损位置是污染源难以在不污染家具外部的情况下污染的家具内部。人眼一眼可以看出的证据瑕疵，把照片交给OCR，api空无一物（不用api返回了，我直接返回给你contentblock=null），而律师真正需要的恰恰是照片里的非文字信息。

最后：错误如何被放大

前两层问题说的是“信息怎么丢的”。但还有一层更隐蔽的问题：丢掉的信息不仅不见了，还可能反过来污染正确的信息。

首先 OCR 错误会被大模型“合理化”

OCR 把合同中的“违约金为每日万分之五”识别成了“违约金为每日万分乏五”。“乏五”显然不通，但大模型有一个特性——看到不通的句子，它会调用自己的语言知识去“修”。它可能把“乏五”理解成“之五”的错别字，然后基于“每日万分之五”去分析。

这次它猜对了。但如果 OCR 把“股权转让价款为 1,000 万元”识别成“股权转让价款为 10,000 万元”——多了一个零——数字本身是通顺的，大模型不会觉得有任何异常。于是它基于一个翻了 10 倍的金额，认真分析了整个交易结构。

如果模型温度不等于零，systemprompt也没关注事实性质，大模型对自己看不到的内容还会“自信地编”

我问大模型：“这份合同的甲方一栏有没有盖章？”

非视觉模型的正常做法应该是回答：“抱歉，我无法查看原始文件，无法确认。”但实际上，有的模型很可能回答：“根据文件名和内容判断，这是一份标准的股权转让协议，通常情况下甲方一栏应该有盖章。”

这就是大模型的“幻觉”——它不知道自己不知道。在它看来，这个问题和“请解释什么是违约责任”是一回事——都是根据已有知识回答。它意识不到自己的知识来源只是 OCR 输出的一串文字，而非原始文件。（当然，幻觉并非只产生于这一个原因，上下文超过百分之40、噪音过多、lost in the middle 都是致幻的典型原因）

解决路径：法律场景下的四步实操方案，从流程上处理全过程的解决

处理前：判断文件类型，预选路径

拿到一份PDF后，先不要直接丢给任何工具。花10秒做一个基本处理与判断（这一步作为案件事实沉淀的一部分，相关skill已经有现成的开源项目，或者由你复现自己对案件事实处理的工作流写成skill，记得开源给我哟）（注意脱敏，以及四重维度的安全风险：国家秘密严禁上传，商业秘密知识产权、工作秘密、自然人隐私用本地脚本处理）：

电子生成的PDF——从Word/WPS直接导出、从工商系统下载的PDF、法院电子送达的文书。这类PDF的文件内部本身就存储着文字数据，不需要OCR。

用PDF文本提取工具直接提文字。推荐pdfplumber（Python工具，可保留一定的表格结构）或直接用Docling（开源工具，可直接输出Markdown，保留标题、表格、图片引用）。然后把提取出的文本喂给大模型。全程不走OCR，不产生第一层损失。（我目前在用的就是Docling。）

扫描件或拍照件——对方寄来的盖章扫描件、手机拍的合同照片、纸质卷宗扫描件。这类文件本质上是“披着PDF外衣的图片”，内部没有文字数据。必须走OCR或视觉模型路线。进入下一步。

混合PDF——部分页面是电子生成的，部分是扫描插入的（常见于证据材料汇编）。可以先分离两种页面，分别处理。

处理中：根据场景进行实际工具组合

场景 A：需要关注结构、格式的合同审查（抽屉协议、开口协议、附件）

这类场景的特点是：条款结构的层级关系有其意义，表格数据需要精确，页码和签名信息不可丢失。

可以采用视觉模型直读：

1. 将合同的每一页导出为高清图片（PNG 或 JPG，分辨率不低于 150 DPI）

2. 将图片直接送入具备视觉能力的大模型（GPT-4o、Claude 3.5/4 系列、Gemini 2.5 Pro 等）（更建议使用ccswitch切换模型工作）

3. 视觉模型能够同时看到图片中的文字内容和空间布局，理解签名位置、表格结构、印章覆盖范围

4. 让模型输出结构化的审查结果

实操注意：

如果合同页数较多，单次处理可能超出模型的上下文限制（一般而言api为了节省token单次工具调用不超过50k字符，消息合集也有限制，超过的虽然会自动写磁盘但是也有直接返回异常状态的）。建议分割pdf，或者分批处理（为了保证逻辑连贯或者减少噪音可以使用subagent返回摘要文件给主agent），每批依据图片内容大小不同应当动态调整页数。

关键页面（签名页、对价计算页、违约责任页）单独处理，不给模型“跳过去”的机会

提示词（Prompt）中明确要求模型：“请逐页检查以下内容：① 所有表格的行列对应是否正确；② 签名和印章的位置；③ 是否有任何文字覆盖或重叠的情况”可以写在项目文件夹下。（最好项目开始时就给出该约束，或从现有工作流调用，复用过程不能简单提示，而要准确说明，适用于本项目并重新写入本项目记忆）

场景 B：大量证据材料的初步梳理

这类场景的特点是：文件数量多、格式杂、每份文件的重要性参差不齐。主要目的是快速梳理出关键信息。

推荐路径——Docling/Mineru预处理+大模型分析：

1.批量使用Docling（IBM开源）或Mineru（对中文支持友好）将扫描件转换为Markdown格式

3. 将 Markdown 文本送入大模型进行分析

实操步骤（以 Docling 为例）：

[bash]

安装 Docling（需要 Python 环境）

pip install docling

将 PDF 转换为 Markdown

docling 证据材料.pdf --output 证据材料.md

输出后得到一个保留了结构的 Markdown 文件，再把这个文件的内容复制给大模型进行分析。

场景 C：手写内容处理

如果文件中有大量手写批注、手写签字或手写条款，普通 OCR 和大部分文档转换工具的表现都会很差。

推荐路径：

1.对于孤立的手写区域（如庭审笔录中的手写记录），使用专门训练过手写识别的模型：TrOCR（微软开源）或GOT-OCR（对中文手写有优化）

2.对于印刷+手写混合页面，最佳方案仍然是视觉模型直读——视觉模型能同时处理印刷体和手写体，且能理解手写内容指向原文档的哪个位置

3. 如果必须降低成本，可以先让普通 OCR 处理印刷部分，手写部分人工录入

场景 D：跨文件关联审查

多份关联文件（主协议+多个附件+补充协议）需要对照审查时：

推荐路径——结构化提取+统一索引：

1. 先用 Docling 或视觉模型，把每份文件转换为结构化的 Markdown

2.在送给大模型之前，手动做一个文件编号和标题映射表：

文件A：股权转让协议（主协议）.md

文件B：附件一-标的公司股权结构表.md

文件C：附件二-资产清单.md

文件D：补充协议（2025年3月）.md

3. 将所有 Markdown 文本拼接，在每个文件的开头插入明确的文件标识：

=== 文件A：股权转让协议（主协议）===

[正文内容...]

=== 文件B：附件一-标的公司股权结构表 ===

[正文内容...]

4.在提示词中明确要求大模型：“上述内容包含4份关联文件（A主协议、B附件一、C附件二、D补充协议）。请在进行任何分析时，明确标注所引用的内容来自哪个文件。对于文件A中出现的'详见附件一'等引用，请对照文件B的内容进行验证。”

处理后：校验机制

无论使用哪种工具路径，都应建立校验环节。这应当是一个工作习惯。（本人常常因为老板push跳过校验而导致输出不尽人意，需知质量质量，质大于量）

针对 OCR 输出 / Docling 输出：

可以让大模型做一次“格式重建”。在提示词中写：“以下内容是一份合同经过OCR/文档转换后的文本，可能存在排版和结构错误。请我：①识别并标注任何我怀疑识别有误的地方（标注为[存疑：原文可能为xxx]）；②将内容按合理的合同结构重新排版；③单独列出所有表格，注明每个表格的行数和列数，如发现有行列对应不清的情况请明确指出。”

之后手动抽查关键数据：从输出文件中取出 3-5 处金额、日期、当事人名称，对照原文核实。如果这几处都正确，对整体质量有一个基本判断；如果有多处错误，说明这条路径不适合这批文件，需要更换方案。

针对视觉模型直读：

视觉模型虽然能同时看到文字和布局，但它也可能“看走眼”。对重大判断（如“甲方是否已在关键条款处盖章”），要求模型同时输出它做出判断的依据——“请引用原文中的具体位置和画面内容来支撑我的结论”。所以要求建立“重大事项人工复核清单”：不要求每页都复核，但对模型标记为“异常”“不确定”“高风险”的地方，逐项对照原文确认。可以留存为可复用的工作流。

最后的焚决：人在回路

对于直接关系工作核心的部分。比如合同审查结论、法律意见书的事实依据、诉讼策略的关键证据分析——最终决策必须经过人的眼睛和大脑。AI的价值是把注意力引导到最需要关注的地方，而不是替代我做判断。一个务实可复用的工作流是：

1. AI 第一轮处理，输出分析报告 + 可疑点清单

2. 律师复核可疑点 + 抽查关键数据

3. 确认无误后，AI 辅助生成最终文书

4. 律师核定后发出

依据大模型圣经：一周不学，全部白学。一年不学，啥也不落。不论是辅助工具还是模型能力，变化的单位可能是以周计的。故以上文章仅基于2026年6月技术背景，请根据当时当下技术手段合理选择，本人经验不具有唯一性，仅供参考。