元宝支持的 36 种文件格式：能读的、会失真的、压根读不了的

36 这个数字是真的，官方在多个产品页上都写了。但它回答的是"能不能打开"，不是"打开了能不能用"。实际用下来，失败几乎都发生在第二种情况——文件传上去了，元宝也答了，答的内容却悄悄少了一块。

官方口径的 36 种，实际覆盖哪几类

把官方描述归类，落点在这几块：

官方口径给了单文档字数上限和单次文件数上限，具体数值以 App 内帮助页为准。上限不低，但“上限高”和“用得好”不是一回事。

失真之一：扫描件走的是另一条路

文本型 PDF 里，文字是可提取的字符；扫描件里，文字是像素。元宝处理后者要先做 OCR，再理解。

这一步的损耗很直接：印章、手写批注、竖排文字、双栏排版，都是 OCR 的弱项。更麻烦的是错得安静——识别成一串看似合理但实际错误的字，元宝会照着这串错字继续推理，最后给你的结论语法通顺、事实错位。

判断方法：把 PDF 里的一段话复制出来，如果复制得到正常文字，是文本型；复制出来是空白或乱码，就是扫描型。扫描件不要让它做"精确引用原文"的活，只做"这文件大概讲什么"。

失真之二：表格的结构会在总结里塌掉

Excel 是最典型的例子。一个带合并单元格、多级表头、跨表引用的工作簿，在元宝眼里首先是一堆数字。

它能把数字读出来，也能算，但"这一列是同比、那一列是环比""这个合计不含子公司"这类只有看过表结构才知道的信息，经常在总结里消失。你拿到的是一段读起来很顺的文字，回头对账才发现口径错了。

一个可用的做法：先让它复述表头。把第一行、第二行的表头原文念一遍，念对了再问数据。念错就说明结构没读进去，后面不用问了。

失真之三：长文档不是读不完，是答不全

字数上限很容易让人放松警惕。但“能读进去”和“问到哪儿答到哪儿”是两回事。

实际表现是：你问文档第 3 章的一个细节，它答得出来；你问"全文出现过几次同一个概念，分别在哪一章"，它经常只找到前几处。上下文越长，注意力越容易集中在前段和高频内容上。

处理办法是减少一次性投喂。把一份 200 页的文档拆成按章节的 5 个文件，分别提问，再自己合并结论。这比一次丢进去问 20 个问题准得多。同类产品里，Kimi OK Computer 那种以长文档为主打的工具在这类交叉检索上更稳一点，但拆文件这个办法对谁都有效。

还有一个容易忽略的边界：对话框里单次直接输入的文本上限是 5000 字。粘一段长文进去被截断，很多人会误判成模型理解力下降，其实是输入就被切了。

上传前的三个检查

一查类型。扫描件单独处理，别混在文本型文件里一起提问，否则你会分不清哪个结论来自 OCR。

二查结构。表格类文件先让元宝复述表头，对了再往下走。

三查敏感内容。上传的是完整文件，不是摘要。合同里的对价条款、人事表里的薪酬列、客户名单里的联系方式，都会随文件一起进去。同一份表要给别人看，先在本地删列再上传。

想省掉来回上传的麻烦，电脑版直接读微信文件这条路更顺；文件处理完要接办公流程的，可以看 腾讯 WorkBuddy 的处理方式，它的定位就是把文件到成品的链路串起来。