上传看着只是【把文件拖进去】,其实是本章的第一道质量闸门——因为它决定了 AI 能看见什么。三条硬性检查(格式/体积/数量)决定文件传不传得上去;三条质量检查(文字层/期间/单位)决定它传上去之后会不会悄悄出错。后者更贵,因为它不报错。
7.2.1 把任务交代清楚了,本节给它素材——而素材的成色,直接决定结论的成色。 与 6.4.1 对照:那里也有一句几乎一样的话——【文件必须先落到一个两边都能访问的地方】。区别是:第六章的"两边"是 RPA 和扣子工作流(要的是可访问的 URL),本章的"两边"是你和扣子空间(要的是一份能解析的文档)。
一、上传这一步,为什么值得单独成一节
教材把它单列成一个小节,原因很实在:本章所有的分析结论,都建立在"它读到的东西"之上。
你上传什么 → 它就只看得见什么 → 它写出来的每一条结论
都只能来自这份文件
这条链路有一个容易被忽略的推论:如果素材本身有问题,后面七节的所有检查都是白做的——因为它不是在"分析"出一个错,它是在"忠实整理"一个错的素材。
6.1.1 讲过【主数据里没有这个编码,不是模型识别错了】——它如实读对了,错的是上游。 本节同理:扫描件里"1,000 万"被认成"100 万",不是它分析错了,是你给它的素材看错了。
二、六条检查:三条硬的、三条软的
这是本节的核心表。看清楚"硬"和"软"的分界:
| # | 检查 | 类型 | 通不过的后果 | 谁能发现 |
|---|---|---|---|---|
| 1 | 是不是 PDF | 硬 | 传不进去/解析不了 | 系统当场报错 |
| 2 | 单个是否 ≤ 50MB | 硬 | 传不进去 | 系统当场报错 |
| 3 | 一批是否 ≤ 10 个 | 硬 | 传不进去 | 系统当场报错 |
| 4 | 有没有文字层 | 软 | 数字被认错 | 要读到结论才发现 |
| 5 | 文件名里有没有期间 | 软 | 拿错期去比 | 要读到结论才发现 |
| 6 | 单位有没有声明 | 软 | 差一万倍 | 要读到结论才发现 |
三条硬的,是"操作问题"——报错信息会告诉你,重来一遍就好。 三条软的,是"质量问题"——它不报错,你只能靠习惯挡在前面。
能报错的错,都不算贵;不报错的错,才是本节要拦的。 这条判据在本课出现过很多次:6.4.2 的"结果丢失不报错"、4.2 的"失败要留痕"——都在说同一件事:最危险的不是失败,是静默的失败。
三、扫描件:本章最常见的翻车点
第 4 条(文字层)值得单独讲,因为它是最像"没问题"的那一类问题。
一份扫描版年报:能传上去,能解析,能出结果,写得还挺通顺。它唯一的问题是——
纸上是:1,000,000,000 元
它认成:100,000,000 元
它写成:本期营业收入约 1 亿元(P12)
这句"1 亿元"读起来毫无破绽:格式对、单位对、语气对、还有页码。
第六章的扫描件错,你对一遍原文就能发现(数字摆在那儿,位数一看就不对)。 本章的扫描件错,它藏的是一句通顺的话——而通顺,正是你最难起疑的形态。 所以本章的做法是前置:遇到扫描件,先做 OCR,再上传。 别指望在上百页的结论里靠肉眼捞回一个少掉的零。
四、上传之后发生了什么
文件传上去不是就完事了,通常还会经过解析这一步:
上传文件 → 解析(把 PDF 拆成可检索的文本片段) → 建立索引 → 分析时按需取用
这带来两个实操上的推论:
- 解析需要时间,且有失败的可能。传完别急着发任务,先确认它确实读到了内容(拿一个你已知的数字问一句,看它能不能指出页码)。
- 解析是"按块"的,所以清晰的排版比花哨的排版更好读——这也是第 4 条(文字层)如此重要的原因之一。
五、文件命名的一点讲究
一个小习惯,能省掉后面很多核对时间:把"谁、哪一期、什么单位"写进文件名。
✗ 年报.pdf
✗ 下载(3).pdf
✓ 600519_2025年报_单位元.pdf
✓ 000858_2025三季报_单位万元.pdf
为什么值得:任务描述里要写"对象",而这个"对象"最不容易写错的方式,就是让它同时出现在文件名里——人和 AI 看的是同一个名字。7.2.1 讲的清单第 1 条【核对上传件】,核的就是它。
六、⚠️ 2026 现状:上传这一侧的三件事
现状一:容量规则是明确的硬限制
一次最多 10 个文件,单个不超过 50MB。超了就拆批——注意"拆批"不只是操作问题:如果这份分析本来就该基于全部 11 份文件,拆批意味着你要自己负责把它们的结果合起来。
现状二:文件是传到云端的
上传即上传到平台侧。这是本节之外的一条纪律:别把不该外传的内部文件往上放。本课的场景是公开年报,这一点没有风险;但换成"未披露的内部报表",就完全是另一回事了。
现状三:解析质量取决于原件质量
这一条没有官方数字,但方向明确:清晰、有文字层、排版规整的原件,解析质量明显更好。扫描件、拍照件、加密件都是高风险供给。
6.1.1 讲过行业数据【识别准确率已 99% 以上,但手写连笔、差扫描件、旋转、没见过的版式仍然吃力】。 "差扫描件"四个字,两章都适用——第六章它影响的是字段识别,本章它影响的是结论的数字根基。
七、动手 Demo:上传前体检器
下面这个脚本把上面六条检查(外加数量)写成代码,扫一批文件。
# -*- coding: utf-8 -*-
"""7.2.2 Demo:上传前的财报文件体检器
扣子空间的附件规则(2026 现状):一次最多 10 个文件,单个不超过 50MB。
本 Demo 在此之上再加三条财报特有的检查:
- 有没有文字层(没有=扫描件,识别质量会掉)
- 文件名里有没有期间标识(年报/半年报/Q1~Q4)
- 单位有没有在文件名或正文里声明(元/万元/百万元)
"""
LIMIT_COUNT = 10
LIMIT_MB = 50.0
# (文件名, 是否PDF, 体积MB, 有无文字层, 能否看出期间, 单位已声明)
FILES = [
("600519_2025年报.pdf", True, 8.4, True, True, False),
("600519_2024年报.pdf", True, 7.9, True, True, False),
("600519_2023年报.pdf", True, 9.1, True, True, True),
("2025Q3季报_扫描件.pdf", True, 22.6, False, True, False),
("行业研报_白酒2026.pdf", True, 31.2, True, False, False),
("年报附图_商誉明细.pdf", True, 4.3, True, False, False),
("2025半年报.pdf", True, 6.8, True, True, False),
("年报合订本_高清版.pdf", True, 63.5, True, True, False),
("2025年报.xlsx", False, 1.2, True, True, True),
("2024年报_下载版.pdf", True, 12.3, True, True, False),
("2025三季报.pdf", True, 5.1, True, True, False),
]
def check(name, is_pdf, mb, has_text, has_period, unit_ok):
"""返回 (结论, 原因清单, 等级)"""
if not is_pdf:
return "先处理", ["格式不是 PDF——扣子空间附件以文档为主,表格请单独整理"], 2
if mb > LIMIT_MB:
return "先处理", ["体积 %.1fMB 超过单文件上限 %.0fMB" % (mb, LIMIT_MB)], 2
level = 0
reasons = []
if not has_text:
level = 1
reasons.append("没有文字层(扫描件),识别质量会下降")
if not has_period:
level = 1
reasons.append("文件名里看不出是哪一期")
if not unit_ok:
level = 1
reasons.append("单位未声明(元/万元),引用数字前要确认")
if level == 0:
return "可上传", [], 0
return "需注意", reasons, 1
看到什么算成功(真实输出):
==============================================================================
7.2.2 Demo:11 个文件,哪些能直接传
==============================================================================
规则:一次 <= 10 个文件,单个 <= 50MB
文件 体积 结论
--------------------------------------------------------------------------
600519_2025年报.pdf 8.4MB 需注意
600519_2024年报.pdf 7.9MB 需注意
600519_2023年报.pdf 9.1MB 可上传
2025Q3季报_扫描件.pdf 22.6MB 需注意
行业研报_白酒2026.pdf 31.2MB 需注意
年报附图_商誉明细.pdf 4.3MB 需注意
2025半年报.pdf 6.8MB 需注意
年报合订本_高清版.pdf 63.5MB 先处理
2025年报.xlsx 1.2MB 先处理
2024年报_下载版.pdf 12.3MB 需注意
2025三季报.pdf 5.1MB 需注意
二、需要处理的,逐条说原因
------------------------------------------------------------------------------
1) 600519_2025年报.pdf
- 单位未声明(元/万元),引用数字前要确认
2) 600519_2024年报.pdf
- 单位未声明(元/万元),引用数字前要确认
3) 2025Q3季报_扫描件.pdf
- 没有文字层(扫描件),识别质量会下降
- 单位未声明(元/万元),引用数字前要确认
4) 行业研报_白酒2026.pdf
- 文件名里看不出是哪一期
- 单位未声明(元/万元),引用数字前要确认
5) 年报附图_商誉明细.pdf
- 文件名里看不出是哪一期
- 单位未声明(元/万元),引用数字前要确认
6) 2025半年报.pdf
- 单位未声明(元/万元),引用数字前要确认
7) 年报合订本_高清版.pdf
- 体积 63.5MB 超过单文件上限 50MB
8) 2025年报.xlsx
- 格式不是 PDF——扣子空间附件以文档为主,表格请单独整理
9) 2024年报_下载版.pdf
- 单位未声明(元/万元),引用数字前要确认
10) 2025三季报.pdf
- 单位未声明(元/万元),引用数字前要确认
三、数量核对
------------------------------------------------------------------------------
文件总数 11 个 —— 已超限,要拆批(上限 10)
可上传 1 / 需注意 8 / 先处理 2
四、读结果
------------------------------------------------------------------------------
① 三条硬性检查(格式/体积/数量)是【传不进去】的;
三条质量检查(文字层/期间/单位)是【传进去也会出错】的。
前者当场报错,后者要等你读到结论才发现——后者更贵。
② 那个扫描件是本章最常见的翻车点:它照样能传上去,照样能
出结果,只是数字会悄悄错。【遇到扫描件,先做 OCR 再上传】。
③ 单位未声明这条看着像小事:【元】和【万元】差一万倍,
而 AI 只会照着纸面抄,它不会替你猜单位。
==============================================================================
读结果:
- 11 个文件里只有 1 个"可上传",其余全在"需注意"——这不是这份样本特殊,这是真实情况。真实素材里,"能传上去"和"可以直接用"之间,隔着六条检查。
- "需注意"最多的一类,是"单位未声明"。它最不起眼,但它是唯一一个"看不出来就会差一万倍"的问题。
30 秒实验
拿你手边任意一份 PDF 财报(没有的话,去交易所官网随便下一份),只做一个动作:
用鼠标在 PDF 里【选中一段文字】。
- 如果能选中、能复制 → 有文字层,可以直接上传;
- 如果框了半天选不中,或者选出来是乱码 → 它是扫描件或图片版。
再想一层:如果连你选中都费劲,凭什么觉得 AI 能读得准?
结论:这一个动作,能挡掉本章最贵的那类错。 花 3 秒,省的可能是一次全盘重做。
常见误区
- 【文件能传上去就说明没问题】——传得上去和读得对,是两件事。 六条检查里,只有前三条会报错;后三条不报错,只出错。
- 【扫描件也没关系,AI 不是能识别图片吗】——能识别,但识别质量会明显下降。 而且本章的下降方式最阴:不是给你乱码,是给你一句通顺的错话。先 OCR,再上传。
- 【单位是小事,它会自己看上下文】——它不会替你猜。 年报里"金额单位:万元"通常写在表头,离数字很远;模型照纸面抄,你写"万元"它就是万元,你写"元"它就是元——判断这件事,是你的。
- 【文件越多越好,全都传上去】——多不一定好,还有 10 个的上限。 更实际的问题是:你传的每一份,都要为它的结论负责。传一份自己都没看过的研报,等于给分析结果开了一个你控不住的口子。
自测三问(点开对答案)
1. **上传前的六条检查里,"硬"和"软"分别是什么?为什么要特别防"软"的那三条?** **硬的三条**:是不是 PDF、单个是否 ≤ 50MB、一批是否 ≤ 10 个——**通不过时系统当场报错**,重来一遍就好,成本极低。 **软的三条**:有没有文字层、文件名里有没有期间、单位有没有声明——**它们不报错,只出错**。 **为什么要特别防软的**:因为**它们制造的错藏在一段通顺的文字里**。例如扫描件把"10 亿"认成"1 亿",写成"本期营业收入约 1 亿元(P12)"——**格式对、单位对、有页码,你看不出破绽**。 **一句话**:**能报错的错不贵,不报错的错才贵。** 2. **为什么说"扫描件"是本章最常见的翻车点?本章给它的处置办法是什么?** 因为**它是最像"没问题"的那一类问题**:能上传、能解析、能出结果,而且**它错的形态是一句通顺的话**——而通顺正是人最不容易起疑的形态。 这和第六章的扫描件错不一样:**第六章错在数字上,你回原文一对就能发现位数不对**;本章你要的产出本来就是一段话,**少一个零,读起来一样顺**。 **处置办法是【前置】**:**遇到扫描件,先做 OCR,再上传**。不要指望在几百页的结论里靠肉眼捞回一个零。 验证办法很简单:**在 PDF 里试着选中一段文字**——选不中或选出来是乱码,就是扫描件。 3. **上传之后还有"解析"这一步,它带来哪两个实操上的推论?** **① 解析需要时间、也可能失败**:传完别急着发任务,**先拿一个你已知的数字试问一句**,看它能不能指出页码——**这一步是"喂进去的素材确实读到了"的最小验证**。 **② 解析是"按块"进行的**:所以**排版清晰的原件比花哨的原件更好读**——这也是"文字层"如此重要的一条底层原因。 **这两条合起来说明一件事**:**上传不是结束,是"素材责任"的开始**——你传了什么、它读到了什么,两者必须一致。 **本节只有一句话要带走**:**能报错的错不贵,不报错的错才贵——所以扫描件必须先 OCR。**- ☐ 下一节(7.2.3 智能体分析提示词配置)
相关笔记
- 扣子空间任务创建 —— 本节的上游:任务交代清楚了,才有"该传什么"的问题
- RPA发起会话并识别结果 —— 【文件要先有可访问地址】,两章的同一个前置条件
- 采购订单智能填报概述 —— 那头【99% 准确率】的数据里,"差扫描件"仍在吃力项里
- 采购订单智能识别工作流 —— 那里也讲图像输入,对照看【图像理解】与【文字层】的差别
- 🤖 Agent+RPA实战 · 索引 —— 全课路线图