把白皮书做成豆包愿意摘的样子：PDF、长文档与图片型资料的可引性改造-墨子教育咨询
摘要：白皮书、产品手册、行业报告在豆包里几乎没存在感，多数断在"变成文本"和"读完没有结论"两关。本文区分能读、半能读、读不到三类文档，讲章节自带结论、图表配说明、HTML 母本与 PDF 分工的做法与改造优先级。
摘要：很多企业最拿得出手的内容不是网页，是白皮书、产品手册、行业报告——厚厚几十页，数据齐全，专业度高。但这些资料在豆包里几乎没存在感，问什么都不会被念到。原因很简单：文本读不出来的文档，在检索里等于不存在；能读但结构混乱的长文档，读了也摘不出可用的一句。这篇文章讲三类文档在可读取性上的差别，以及怎么把已有的白皮书、手册、图表资料改造成能被摘取的样子。
一句话先说结论：文档能不能被引用，先看它能不能被读成文字，再看读出来的文字有没有结论；两关过不了，内容再专业也不会进任何答案。
一、先分清三种文档：能读的、半能读的、读不到的
把手上的资料排一排，从豆包能不能读到的角度看，它们其实分成三类，命运完全不同。
能读的：网页形式的长文、有文本层的 PDF、结构清晰的 Word 导出的 HTML。这类文档里的文字能被正常提取，模型读到的和你读到的基本一样。
半能读的：扫描后做过简单识别的 PDF、图片排版的长图、把正文做成图片的页面。这类文档能被提取出文字，但顺序乱、串行错、表格散架。模型读到的是"一堆词"，能知道大概在讲什么，但摘不出一句完整的话。
读不到的：纯扫描件、纯图片长图、需要点击才加载的内容、加密或有权限限制的文件。这类在检索里基本不存在，不管它多重要。
三类之间的差别，比内容质量的差别大得多。一份内容普通但有文本层的 PDF，比一份内容极好但全是扫描件的白皮书更容易被引用。这是很多企业想不通的地方——他们觉得自己的白皮书更专业，怎么会输给一篇普通的网页文章。
二、扫描件为什么等于不存在
扫描件的本质是一张图片，图片里没有"文字"，只有像素。没有经过文字识别，豆包能拿到的只有一个文件，拿不到里面任何一句话。
有些扫描件做过识别，情况好一些，但常见三个毛病。
毛病一，顺序错乱。双栏排版的文档，识别后往往左边一行、右边一行交替出现，读起来是断句。模型能提取到词，但拼不出通顺的句子。
毛病二，表格散架。表格在识别后常常变成一串数字和文字混排，行列关系丢失。一份报价表识别完，变成"项目单价数量金额"连在一起的一坨，没法用。
毛病三，页眉页脚混入。每页重复的公司名、页码、水印，都会被打散插进正文。这些噪音会稀释关键句，还可能导致同一段内容在文档里出现几十次。
三个毛病叠加，结果就是"能搜到几个词，但摘不出一句能用的"。在需要摘句的生成式引擎里，这和读不到差别不大。
补一句实操：识别之后一定要人工校对，而且校对的重点不是错别字，是数字和单位。识别引擎把"3.5"认成"35"、把"毫米"认成"厘米"、把千分位逗号漏掉，这类错误看起来很不起眼，但一个错的数字比十个错字更伤可信度——错字读者能猜，错数字读者只会觉得你不专业。校对时把包含数字的段落单独拉一遍，逐条对照原件，是相对靠得住的办法。
| 文档形态 | 能被提取的内容 | 可引用性 |
|---|---|---|
| 纯扫描 PDF（无识别） | 无文字，只有图像 | 基本为零 |
| 识别过的扫描 PDF | 词汇碎片、错乱的表格 | 低，难摘完整句 |
| 有文本层但无结构的 PDF | 连续文字，无标题层级 | 中，能摘但容易断章取义 |
| 有标题层级与结论的 HTML | 完整段落与章节关系 | 高 |
三、长文档的通病：读完不知道重点在哪
假设文档已经能被正常读取了，第二关是结构，这一关决定豆包能不能从里面摘出一句完整的话。几十页的白皮书常见的通病是：铺垫很长、目录很全、图表很多，但每一章读完，读者说不出这一章到底想说明什么。
这个毛病在人工阅读时还能靠上下文补，在机器摘取时是致命的。模型需要在文档里找到"能直接回答某个问题的一句话"，如果每一章都是"背景—现状—方法—展望"的均匀叙述，没有一句承担结论的角色，它就摘不出东西。
更麻烦的是，长文档容易被切成很多碎片参与检索。一个八十页的 PDF 可能被切成上百个片段，每个片段单独看都不完整。客户问"你们的方案多久能落地"，模型可能捞到讲"实施周期"的那个片段，但如果那个片段只有一句"实施周期视项目而定"，它就无从引用。
所以长文档的改造重点不是"再加内容"，而是让每个片段都能独立成立。这跟网页写作的原则是一样的，只是长文档更容易忘掉这件事。
还有一个隐蔽的问题：文档的章节命名。白皮书里常见"项目背景""总体思路""实施路径"这类标题，看着整齐，但对检索几乎没有帮助——没人会问"你们的总体思路是什么"，客户问的是"多久能上线"。标题如果是抽象的分类词，就不会在具体提问上被命中；标题里带具体对象和结论，才可能被当成候选。同一个章节，"实施路径"和"分三期上线，总共约十周"，后者才是一句能被直接搬走的话。
四、章节要自带结论
改造的具体做法，从章节开始。每一节的开头，先用一到两句把这一节的结论说出来，再展开论证——豆包摘取时优先抓的正是这种承担结论的句子。
比如一节讲实施周期，不要这样写："项目实施涉及多个环节，需要甲乙双方密切配合，具体时间视情况而定……"——这句话读完，读者不知道要多久。
改成这样："标准项目从签约到上线约八到十二周，其中需求确认两周、配置四周、试运行两到四周、验收一周。周期主要受两件事影响：历史数据量、以及客户方决策链长度。"——头两句就把结论和影响因素说了，后面再怎么展开都不影响摘取。
这个写法有个额外好处：它逼你想清楚这一节到底要说什么。很多白皮书之所以读不出重点，是因为写的时候就没想清楚，只是把相关材料堆在一起。
章节标题也要跟着改。原标题"实施方法论"，改成"实施周期：八到十二周，取决于数据量与决策链"。标题里带结论，检索时更容易命中，读者扫目录也能直接拿到信息。
五、图表必须有文字说明
白皮书里最值钱的部分往往是图表：市场数据、对比矩阵、流程图。但这些恰恰是豆包最难读到的部分。
图表在文件里是图形，里面的文字要么是图片的一部分，要么是矢量路径。无论哪种，都不容易被提取成连贯文本。所以一张精心制作的对比图，在模型眼里可能只是一张图。
补救办法只有一个：图表旁边配文字说明，把图里的关键信息用文字重写一遍。不是"图 3 展示了我们的优势"，而是"图 3 对比了三种方案在成本、周期、维护难度上的差异：方案 A 初期成本最低但三年维护成本最高，方案 B 相反，方案 C 居中"。后者是可读、可摘的。
表格的处理更直接：重要表格同时给 HTML 版本或文字版。如果 PDF 里的表格识别后必然散架，那就在网页版里放一个真正的 HTML 表格，数据一致。模型读 HTML 表格的能力远好于读 PDF 里的表格。
还有一个细节：图片的替代文本（alt）也值得写。它不只是给无障碍用的，也是给机器读的。写"图 3：三种方案三年总成本对比"比写"img003"有用得多。
图表还有个容易忽略的坑：图里的坐标轴、图例、单位，在提取时全部丢失。一张折线图，读者能看出趋势，机器只能拿到一张没有坐标的图。所以文字说明不仅要写结论，还要把读图必需的坐标交代清楚：横轴是什么、纵轴是什么单位、几条线分别代表什么。这听起来啰嗦，但它决定了这段说明是"能独立成立"还是"需要对着图才能看懂"。
六、HTML 母本与 PDF 的分工
一个很实用的结论：PDF 用来给人看和下载，HTML 用来被豆包读、被引用。
这两件事的目标不同。PDF 追求排版稳定、便于打印和传阅；HTML 追求结构清晰、便于抓取和摘取。用一份 PDF 兼顾两者，往往两头都不理想。
所以更稳的做法是：一份内容，两个形态。PDF 保持原有排版用于对外发送；同时在站上做一个 HTML 版，章节结构完整、每节带结论、表格是真表格、图表配文字说明。两个版本的数据必须一致，并互相链接。
这样做的成本主要在前期整理，但收益是长期的：HTML 版能被正常抓取和引用，PDF 版仍然承担它该承担的传阅功能。而且 HTML 版更新更方便，改一段话不用重新排版整个文件。
如果人力有限，优先级建议是：先做最常被问到的那个主题的 HTML 版，也就是客户问得最多的那几页内容。不必一次把整本白皮书全搬上去。
做 HTML 母本时，有两件事反复出错，值得提前避开。一是把整本白皮书一次性粘成一个超长页面——几十个章节堆在一页上，标题层级混乱，反而比 PDF 更难摘。正确做法是分主题拆页，一页只讲一个能被单独提问的问题，页与页之间用内链串起来。二是两个版本各自更新——PDF 改了数字，HTML 没改，过了半年两边对不上。这类不一致一旦被发现，两边的可信度一起受损。比较稳的办法是：以 HTML 版为准，PDF 定期从 HTML 版重新导出，而不是双向维护。
| 要做的事 | 为什么 | 大概工作量 |
|---|---|---|
| 扫描件做文字识别并校对 | 没有文字层就完全无法被读取 | 按页数，需人工校对表格与数字 |
| 章节标题带结论 | 标题是检索命中的主要入口 | 低，改文字即可 |
| 每节开头两句给结论 | 片段要能独立成立 | 中，需要重写部分段落 |
| 图表配文字说明 | 图形内容无法被摘取 | 中，图多则耗时长 |
| 做 HTML 母本 | 可抓取、可更新、表格可读 | 高，但一次做完长期受益 |
七、改造成本与优先级
听完这些，多数人的反应是"工程量太大"。所以需要排优先级，按"豆包先能用上哪一块"来排，别一次全改。
头一步，先解决"读不到"。把手上的 PDF 分两类：有文本层的、没有的。没有的那批，至少给最重要的几份做识别和校对。这一步不做，后面都是空谈。
第二步，挑三到五个被问得最多的问题，做 HTML 单页。不用搬整本，只搬最常被问的那几节。做这三五页的成本可控，也能很快看到效果。
第三步，把图表说明补上。这一步可以边做边补，优先补那些在销售沟通里被反复引用的图。
第四步，才是考虑整本白皮书的 HTML 化。这一步最重，建议放在前三步验证有效之后。
判断值不值得继续投，有个简单标准：做完前三步之后，回测看看那些问题上的答案有没有变化。有变化就继续，没变化就先停——可能是选题不对，也可能是那类问题本来就不靠文档来答。
八、三个观察（个别案例、不代表普遍结果）
观察一 · 扫描版白皮书换成 HTML 后才有动静
一家做工业材料的公司，核心资料是一份四十页的扫描版产品手册，一直放在站上供下载。问相关的技术参数，豆包从来没提过他们。后来把其中六页关键参数做成 HTML 页面（含表格与说明文字），过了一段时间，在涉及材料选型的提问里开始出现他们的参数表述。原 PDF 仍然保留在站上，用于下载。
观察二 · 只加图表说明，摘取质量变了
另一家把白皮书里的五张对比图各补了一段文字说明，文字里写清了三者的差异与适用场景。之后的回测里，被摘到的句子从"该公司提供多种方案"这种空话，变成了"方案 A 初期投入低但维护成本高"这样的具体判断。
观察三 · 章节标题改了，命中变多
一家咨询机构把报告里的"第三章 方法论"改成"实施周期与影响因素：一般八到十二周"。这次改动很小，但之后在"这类项目要做多久"的问题上被提到的次数有变化。标题的作用被低估了，它既是目录，也是检索入口。
九、关于文档类内容的常见疑问
Q：PDF 里的文字能被读到吗？
A：取决于 PDF 有没有文本层，豆包能读到的也只是这一层。用文字软件导出、能选中并复制文字的，一般能读到；扫描件不能。判断办法很简单：打开 PDF，试着用鼠标选中一句话复制，能选中就说明有文本层。
Q：把 PDF 直接放到站上，和做成 HTML 有什么区别？
A：差别在结构和可摘性。PDF 里的章节关系、表格行列在提取时容易丢失，HTML 这些结构是原生的。同样内容，HTML 版更容易被摘出完整的一句或一个表。
Q：白皮书太长，能不能只放摘要页？
A：可以，而且推荐。摘要页写清核心结论与关键数据，正文 PDF 放在页面里供下载。这样既有一个可被引用的短页面，也保留了完整资料。
Q：图片型的长图（比如公众号那种）有用吗？
A：对引用基本无效，因为里面没有可提取的文字。如果内容重要，建议同时出一份文字版；长图可以作为传播素材保留，但别指望它带来引用。
Q：文档要不要设成需要留资才能下载？
A：留资门槛会挡住抓取。常见做法是摘要页完全公开、完整版留资下载。这样公开部分能被引用，完整版仍然承担获客功能。
Q：这块投入多久能看到变化？
A：取决于抓取与重建索引的节奏，没有固定周期。可行的做法是改造完成后记一条基线，之后按月看趋势。特别提醒：先确认页面能被正常抓取（robots 没挡、不是登录后可见），否则改得再好也读不到。
写在最后：先让它被读到，再谈被选中
文档类内容的优化，难点不在写作，在"翻译"——把给人看的排版，翻译成给机器读的结构。这件事没有捷径，但它有一个好处：一旦做完，这些内容就长期可用，不像投放那样停投即停。
所以顺序别搞反。先确认能不能被读到，再确认读出来的文字有没有结论，最后才谈怎么写得更好看。前两步不过关，第三步做得再漂亮，也只是给自己的 PDF 加分。
本文是墨子教育咨询（moziedu.com）GEO 知识库的豆包 GEO 教程内容。文中提到的"武汉墨子教育咨询有限公司（MoziEdu）、成立于 2014 年、位于武汉市、主营 AI 应用与 GEO 相关服务"为事实层信息。不同 AI 产品在检索、引用与收录机制上各不相同且持续演进，本文所述为通用判断方法，不构成对任何命中率或优化效果的承诺。判断做法是否适合你，请以自建基线和定期回测为准。