99% 的人以为「能上传 PDF」就等于「什么 PDF 都看得懂」。但在实际工作里，扫描件、长报告、图表、合同修订、多文件推理和加密文档，难度完全不是一个级别。我们用 10 个精心设计的文件任务，在真实浏览器环境下把 DeepSeek Chat 的 PDF 能力拆开来测了一遍，给出清晰分数和可复制的设置建议。

这组测试里，DeepSeek Chat 的整体产品工作流得分是 89/100：其中模型在 9 个可提交任务上的回答拿到 84/95，密码保护文件的安全失败机制拿到 5/5。所有文件都为合成数据，不含真实个人、财务或客户信息，测试完全独立，不代表 DeepSeek 官方立场。

这篇不是「体验分享」，而是有答案标准、有扣分规则的对照实验，更接近你在团队里做工具选型时真正需要的那种报告。

DeepSeek Chat web interface showing Instant, Expert, and Vision modes

测试方法与评分逻辑

测试设计：先写答案，再开模型

很多人评估 AI 工具时，只看「感觉还行」。我们反过来做：

  1. 在打开 DeepSeek 之前，先为每个文件写好「标准答案」和扣分条件。
  2. 每个文档都预埋了已知事实、计算结果、页码位置，甚至刻意设计的「陷阱」和干扰项。
  3. 回答只要和文件不一致，就直接判错，不靠主观印象打分。

为了减少干扰，我们还做了几件事：

  • 每个主测试任务都从全新对话开始，避免上下文残留。
  • 关闭搜索功能，强制模型只能依据上传文件作答。
  • 10 个计分任务全部用 Instant 模式，保持可比性。
  • 一旦模型产出第一份完整回答，就按那一版打分，不刷题。
  • 关键字段（数值、计算、修订条款优先级、证据页码）都和预设答案逐项比对。
  • 响应速度不计入准确率，只做记录。
  • 其中 3 个高风险任务在新对话中重复测试，用来观察稳定性。

在测试时，文件上传入口在 Instant 和 Vision 中都可用，但 Expert 模式当时不支持文件，所以我们没有虚构「Expert 也测过文件」的结论。Vision 只在后面图表失败的案例里，用作诊断性复测。

A searchable PDF attached to a new DeepSeek Instant chat

评分规则：10 个任务如何算分

整体分数拆成 10 个子任务：

  • 8 个任务，每个满分 10 分。
  • 1 个 30 页长文档检索任务，满分 15 分，因为涉及多页远距离检索和修订计算。
  • 1 个密码保护 PDF 任务，满分 5 分，考察的是「安全失败」而不是「破解密码」。

密码保护任务中，正确行为是：界面阻止提交，不向模型发送任何内容，也不凭空编造文档内容。因此我们把「产品工作流」和「模型回答」分开统计：

  • 产品工作流总分：89/100（含 5 分安全失败）。
  • 模型实际回答总分：84/95（不含未提交的那一题）。

扣分细则也做了硬性约束：

  • 数值正确，但证据页码过宽或不精确，可以扣 1 分。
  • 只要出现「编造的实质性内容」，该题最高只能拿一半分数。
  • 纯格式差异（比如日期写成英文而不是 ISO 格式），只要含义一致，就不扣分。

完整成绩单：10 个 PDF 任务表现

搜索型文档与结构化信息

测试 1：可搜索发票——9/10

第一个 PDF 是两页的原生文本发票。要求 DeepSeek 提取：发票号、客户名称、到期日、小计、折扣、税额、应付总额，并重新计算最终金额是否正确。

模型给出的所有字段都对上了：它验证了 3,630.00 美元 − 180.00 美元折扣 + 172.50 美元税 = 3,622.50 美元，计算无误。唯一的扣分点是证据标注写成了 evidence_pages: [1, 2]，而所有计分字段都在第 1 页，多写了第 2 页。

DeepSeek returning correct JSON from a searchable invoice PDF

测试 2：政策修订条款——10/10

第二个文件是 3 页的资助政策：

  • 前两页给出通用申请截止日期、27.5 万美元资助上限、12% 配套比例和联系人。
  • 第 3 页是修订条款：北区机构如果在原截止日前发邮件通知，可获得 5 天延期。

DeepSeek 成功区分了「通用规则」和「有条件例外」，同时返回：

  • 原始截止日期和北区延期后的日期；
  • 完整的资格条件描述；
  • 未被修改的资助上限和配套比例；
  • 联系人姓名；
  • 证据页码 1、2、3。

准确率满分，不过这一轮响应时间异常长，达到 91.8 秒，明显是界面处理延迟的离群值。我们保留了这次结果，没有用更快的重跑替换。

DeepSeek correctly applying a later policy amendment in a PDF

扫描件、版式与表格

测试 3：扫描小票 OCR——10/10

这是一张只有图片、没有文本层的扫描收据，包含：

  • 3 个商品；
  • 小计 36.15 美元；
  • 税额 2.89 美元；
  • 合计 39.04 美元。

Instant 模式成功识别出：小票号、日期、每个商品及单价、小计、税额、总价，以及单价最高的商品，并验证了加总结果。说实话，这一题表现很好，也暴露出一个常被忽略的事实：

「图片型 PDF」不是一个统一能力，简单文档 OCR 和复杂图表理解，在同一个模型里可能是两种完全不同的难度。

DeepSeek extracting line items and totals from an image-only scanned receipt

测试 4：双栏报告版式——10/10

这个 PDF 把两个项目摘要并排排版：

  • 每个项目都有不同的负责人、上线日期、预算和风险等级；
  • 末尾有一句话：分析师应优先选择决策闸门早 14 天的项目。

DeepSeek 在解析时：

  • 没有把左右两栏的字段混在一起；
  • 正确返回 Atlas 和 Beacon 两个项目的 8 个关键字段；
  • 给出 Atlas 被优先选择的原因：决策闸门时间早 14 天。

DeepSeek keeping two project columns separate in a PDF report

测试 5：财务表格计算——10/10

这张表格包含：

  • 每季度毛收入、退货、净收入和销量；
  • 要求模型：汇总全年每个指标、找出净收入最高的季度、算出 Q4 与 Q1 的差额，并验证全年算术是否正确。

DeepSeek 的结果完全对齐：

  • 年度毛收入 535,000 美元；
  • 年度退货 23,000 美元；
  • 年度净收入 512,000 美元；
  • 年度销量 36,750 件；
  • 净收入最高季度为 Q4，金额 143,500 美元；
  • Q4 与 Q1 净收入差额 28,500 美元。

上传过程中，发送按钮在文件处理完成前一直是灰的，处理完后提交，用时约 7.5 秒。这种「先锁发送再放行」的交互，对避免半处理状态下误发请求挺有帮助。

DeepSeek calculating annual figures from a financial table in a PDF

长文档检索与图像图表

测试 6：30 页长文档检索——15/15

我们在一份 30 页的 PDF 里埋了三处关键信息：

  • 第 3 页：运营代码 ORBIT-314 和数量 127；
  • 第 17 页：运营代码 LANTERN-852 和退回数量 43；
  • 第 29 页：预算上限从 65,000 美元修订为 68,750 美元；
  • 其他页面放了很多长得很像的干扰文本。

DeepSeek 的表现：

  • 找到 ORBIT-314 和 127 单位（第 3 页）；
  • 找到 LANTERN-852 和 43 退回单位（第 17 页）；
  • 计算净数量为 84 单位；
  • 正确用第 29 页修订条款，把上限从 65,000 替换为 68,750 美元；
  • 所有返回的页码都和标准答案一致。

DeepSeek retrieving distant facts and an amendment from a 30-page PDF

测试 7：纯图片柱状图——Instant 1/10，Vision 10/10

这一题是模式差异的关键案例。PDF 里只有一张栅格化柱状图：

  • North：84；South：61；East：73；West：92；

目标答案包括：

  • 数值最高的区域：West；
  • West 与 South 的差值：31；
  • 四个区域总和：310。

Instant 模式对所有数值都返回了 null。我们给了 1 分，只因为它没有乱编数字。随后我们新开对话，切换到 Vision 模式，上传同一 PDF，用同样的提示词：

  • Vision 正确读出四个数值；
  • 正确算出差值和总和；
  • 给出了正确的页码引用；
  • 用时约 8.9 秒。

实用结论： 不要把「文件上传成功」当成「当前模式能理解所有视觉元素」的证明。凡是高度依赖图表或图片的 PDF，先用 Vision 在代表性样本上跑一轮，再决定是否纳入正式流程。

合同修订、多文件推理与加密文件

测试 8：合同修订条款——9/10

这份协议原始条款是：

  • 解约需提前 30 天通知；
  • 付款期限为 15 天；

后续修订条款：

  • 解约提前通知改为 45 天；
  • 付款期限改为 10 天；
  • 生效日期为 2026 年 9 月 1 日；
  • 保留原有的正式通知邮箱。

DeepSeek：

  • 准确返回了原始条款和修订后的现行条款；
  • 正确应用了后生效的修订条款；
  • 唯一扣分点是证据页码多写了第 2 页，而计分条款只需页 1、3、4 即可支撑。

DeepSeek applying the controlling terms from a contract amendment

测试 9：多文件联合推理——10/10

这一题模拟真实业务里常见的「多源数据」场景：

  • 一个 CSV：库存数据；
  • 一个 TXT：补货公式；
  • 一个 PDF：在途到货清单。

任务要求：根据三份文件，计算三个 SKU 的到货后可用库存和补货数量。

DeepSeek 的表现：

  • 正确读取并组合三种不同格式的文件；
  • 正确处理了「到货数量为 0」这种边界情况；
  • 给出的结果完全符合标准答案：A-17 需补 3 件，B-04 无需补货，C-91 需补 5 件。

测试 10：密码保护 PDF——5/5

这一题考察的是「安全边界」，而不是「破解能力」。

  • 加密 PDF 内部藏了一句验证短语；
  • 正确行为是：系统不应声称自己读到了受保护内容。

DeepSeek 的界面行为：

  • 文件卡片标记为「No text extracted」；
  • 发送按钮被禁用；
  • 当输入提示词时，界面显示「Remove failed files to submit」；
  • 因为请求从未发送到模型，模型没有输出任何验证短语或虚构摘要。

从安全视角看，这正是我们希望看到的结果：宁可拒绝处理，也不假装看过文件。

一致性：重复测试的稳定度

重复高风险场景的结果

我们把其中 3 个风险较高的任务，在新对话里各重跑了一次，用来观察「同一文件、同一提示词」下的稳定性。

在这 3 组重复测试中，所有关键字段的结果都和首轮一致，物质性字段一致率达到 100%。这说明在这些特定场景下，DeepSeek 的行为相对稳定。不过，这只是一个小样本的稳定性检查，离「对所有文档都稳定」还差得远，我也不太确定能不能把这种稳定度简单外推到更复杂的真实合同或财报上。

使用建议：模式选择与操作步骤

推荐设置：如何少踩坑

根据这次测试，我们给出一套可直接照抄的使用建议：

  • 文本为主的 PDF（可搜索文档、表格、跨文件文本任务）优先用 Instant。 在发票、政策、长文档检索、表格计算、多文件推理等场景中表现都不错。
  • 图表、截图、扫描图像为主的任务，用 Vision 做主力。 单次测试显示，纯图片柱状图在 Instant 只拿 1/10，而 Vision 能拿 10/10，说明视觉任务要单独评估。
  • 做「只看文件」的工作时，关掉搜索。 这样可以降低模型把外部知识混进回答的概率，尤其适合合规、合同和内部制度类任务。
  • 尽量要求结构化输出。 例如 JSON 字段，这样漏项、算错、页码错都一眼能看出来。
  • 让模型返回精确页码或源文件名。 然后人工抽查。我们这次有 2 个答案本身正确，但证据页码多写了一页。
  • 确认发送按钮已激活再提问。 文件卡片出现不代表解析完成，按钮灰着时别急着点。
  • 不要想当然地认为「上传=解析成功」。 看一眼界面有没有提示「No text extracted」之类的错误，再决定要不要继续。

实操流程：如何上传并检查一个文件

如果你想在团队里推广一套「可审计」的 PDF 分析流程，可以参考下面这套步骤：

  1. 打开一个新的 DeepSeek Chat 对话，先选好你要用的模式（Instant 或 Vision）。
  2. 如果答案必须完全来自上传文件，就先把搜索功能关掉。
  3. 点击附件按钮，选择文件，等到处理完成（发送按钮变为可点）。
  4. 如果文件卡片显示「No text extracted」或发送按钮始终不可用，先移除该文件，检查格式、加密状态或是否有文本层。
  5. 在提示词中明确要求：结构化字段、必要的计算、精确的证据页码，然后把模型输出和原文件逐项对照。

文件类型、上传限制与 API 差异

支持格式与上传限制：别只看上下文窗口

在这次受控测试中，我们在网页端成功使用了 PDF、CSV 和 TXT 三种文件类型。这是 2026 年 7 月 24 日 的一次性观察，不构成长期支持承诺。

DeepSeek 的公开帮助中心给出了一些图片上传失败的示例原因，比如：

  • 图片格式不受支持；
  • 无法提取文本；
  • 超过某个上限（但没有给出具体数值矩阵）。

官方更新日志里也提到过对文件上传和网页总结的优化记录。不过有一点很关键：

不要把 DeepSeek V4 宣传的「上下文窗口大小」直接当成「PDF 上传上限」。上下文容量、文件大小、解析器行为、以及最终传给模型的文本量，是四套不同的约束。

如果你要在生产环境里大规模跑 PDF，最稳妥的做法是：

  • 在当前版本界面上，直接用代表性文档做压力测试；
  • 观察处理时间、截断情况和错误提示；
  • 再决定能不能承载你的业务量级。

网页端文件上传 ≠ API 能力

这次基准测试用的是消费者版 DeepSeek Chat 网页界面，它内置了一层文件处理逻辑。而目前公开的 chat-completions API 文档里，消息内容主要描述为文本。

DeepSeek 提供的 Anthropic 兼容文档中，也明确标注：

  • image、document、container 等上传块暂不支持。

所以，如果你打算在后端用 API 搭建工作流，务必预先规划：

  • 在调用模型前，自行完成文本抽取、表格解析或 OCR；
  • 不要对外宣传「网页端能上传文件」等同于「API 也支持原生文件上传」。

隐私与合规：哪些文件不该上传

DeepSeek 的隐私政策把上传的文件、照片和聊天内容都视为用户输入，并说明：

  • 不建议用户提交敏感个人数据；
  • 输入内容可能用于提供和改进服务；
  • 提供了训练改进的退出选项；
  • 数据在中华人民共和国境内存储和处理。

从隐私和合规角度，我们的建议是：

  • 测试阶段尽量使用合成数据或经过严格匿名化的文件。
  • 未经批准的数据治理流程，不要上传客户合同、病历、身份证件、私人财务记录或商业机密。
  • 使用前先看一眼最新隐私政策和账号设置，确认是否允许用于模型改进。
  • 对所有高影响力结论（比如金额、期限、违约条款），都回到原文档逐条核对。
  • 只在你有权限的前提下本地移除密码，不要在聊天提示词里直接写出密码。

结论：DeepSeek 做 PDF 分析到底靠不靠谱？

在这组小规模、合成数据的基准测试里，只要提示词要求清晰、输出结构化，并选对模式，DeepSeek Chat 在文件分析上的表现是可用且相对稳定的。

  • Instant 模式在文本抽取、数值计算、OCR、长文档检索、修订条款应用和多文件推理上表现不错；
  • 除了图表任务外的两次扣分，都来自「证据页码多写了一页」，而不是数值或条款本身错误。

真正需要警惕的是「纯图片图表」这一类场景：

  • 同一张柱状图，在 Instant 只拿 1/10，在 Vision 却能拿 10/10；
  • 这说明一句笼统的「DeepSeek 能读 PDF」其实信息量不大，关键在于：什么类型的 PDF、用哪个模式、怎么验证答案。

我们做了一个事后敏感性计算：如果把失败的 Instant 图表结果，替换成后续 Vision 诊断的结果，产品总分会从 89/100 提升到 98/100。但这并不是事先声明的路由基准，也没有独立复测，所以 89/100 仍然是主结果。

无论是 89 分还是 98 分，都不意味着可以在法律、财务、医疗、合规或强时效决策中取消人工复核。更现实的用法是：把 DeepSeek 当成一个高效的「初筛和结构化助手」，而不是最终裁决者。

如果你正打算在团队里选一款 PDF 分析工具，这套测试思路和设置方法，可能比问身边人「好不好用」更有参考价值。可以先收藏下来，按里面的步骤给你自己的典型文件跑一遍，再决定要不要大规模接入。

常见问题

Q：怎么判断一个 PDF 适合用 Instant 还是 Vision？

A：可以先看文件里「关键信息」的呈现方式：如果主要是可搜索文本、表格、条款和跨页引用，优先用 Instant；如果答案高度依赖图表、截图、扫描图片或手写内容，就更适合 Vision。判断时可以挑 1–2 个代表性页面做小样本测试，看哪种模式在关键字段上更稳定，然后把这个选择固化进团队的使用规范里，避免每个人随意切换模式。

Q：如何设计提示词，才能让 PDF 分析结果更可靠？

A：核心是「具体」和「可验证」。提示词里尽量写清楚：需要哪些字段、要做哪些计算、输出什么结构（比如 JSON）、必须给出精确页码或源文件名。原因在于，结构化输出能让你快速发现漏项和算错，证据页码则方便抽查。实操时，可以先写一版「字段清单」，再把它直接贴进提示词，并在团队内部统一这份清单，减少每个人随意发挥带来的偏差。

Q：DeepSeek 处理长 PDF 时，会不会漏掉后面的内容？

A：有这个风险，尤其是超长报告或附录很多的文件。模型有上下文容量限制，文件解析层也可能对文本做截断或抽样。判断是否「漏看」的一个办法，是在提示词里要求返回具体页码，并刻意把一些关键信息放在文末或附录里做测试。如果你发现这些信息经常被忽略，就需要考虑拆分文档、分章节上传，或者在上传前用脚本抽取并精简文本，只保留和任务强相关的部分。

Q：多文件一起上传时，怎么避免模型把来源搞混？

A：可以在提示词里明确要求：每个结论都要标注来源文件名和页码，并区分「规则文件」「数据文件」「补充说明」等角色。原因是，多文件场景下最常见的错误不是算错，而是把 A 文件的规则套到 B 文件的数据上。实操建议是：给每个文件起一个简短但有区分度的名字（如 policy.pdf、inventory.csv），并在提示词中直接引用这些名字，方便你事后核对。

Q：在隐私和合规要求较高的公司，如何安全地用 DeepSeek 做 PDF 分析？

A：第一步是搞清楚公司对外部 AI 工具的政策，包括是否允许上传真实客户数据、是否要求脱敏、是否需要签署数据处理协议。DeepSeek 的隐私政策提到，用户输入可能用于服务改进，并在中国境内处理，这对一些行业（金融、医疗、政府）是敏感点。可操作做法是：测试和原型阶段只用合成或匿名化数据；正式接入前，与法务和安全团队确认数据流向和保留策略；对所有高风险结论保留人工复核，并在内部文档中明确哪些类型的文件「禁止上传」。