企业官网建设流程全解析

做站群系统内容建设的时候，最头疼的不是批量发文章，而是手里明明拿着一堆高质量PDF文档，却不知道怎么“吃”进网站里。尤其是带数学公式的技术类内容——教材、论文、实验手册——公式在PDF里本质是矢量笔画，复制出来全是乱码字符，硬转成网页又是一堆断裂的图文碎片，排版直接崩掉。我早期处理这类内容时，图省事直接贴PDF链接或嵌iframe，结果移动端用户基本没法看，搜索引擎对PDF的收录和权重传导也远不如普通HTML页面，运营效果差一大截。所以后来我把整个流程拆成“解析、识别、重组、渲染”四段，逐步把PDF公式文档稳定地转成响应式网页。这篇就把这套完整的处理思路、工具选型和踩坑经验完整拆出来，给同样在做站群内容管理或批量文档转换的朋友一个能直接参考的落地方案。

提示：以下方案基于我个人的真实项目实践，工具和代码均为通用方案。具体到你的站群系统，需要根据内容量级和技术栈做适当调整，不建议直接无脑照搬全部配置。

1. 站群系统为什么必须处理PDF公式转网页

1.1 站群内容生产中的三类PDF来源

站群系统的本质是批量管理多个站点、低成本获取长尾流量，所以内容的“来源广、产量大、可复用”就是生命线。实际操作中，PDF文档大致来自三个渠道，处理策略完全不同。

第一种是自有原创PDF，比如你整理的产品手册、行业白皮书、实验数据报告。这类PDF往往有原始排版源文件，理论上转换最理想，但现实里很多团队根本没有保留源文件，只发出去一份成品PDF，回收时就得重新解析。第二种是从行业公开渠道采集的技术文档，比如公开课讲义、论文预印本、政府公开数据附带的PDF表格等。这类内容本身就是“二手内容”，能不能用于站群，还要看站点定位和版权边界，我通常只提取事实性数据和通用知识，不直接照搬大段原文。第三种是最常见也最麻烦的——合作方发来的扫描版或打印版PDF，页面是图片，连文本层都没有，公式更是彻底的像素块。

这些PDF的共同问题是：搜索引擎对PDF内容的解析能力有限，移动端阅读体验差，站群如果靠挂载PDF文件来做内容，基本等于放弃排名。所以必须转成响应式HTML网页，而公式恰恰是这条路上最难啃的骨头。

1.2 公式转存难在哪里：三层拆解

很多人觉得“PDF转网页”很简单，随便找个转换工具就能出HTML，但那只对纯文本段落有效。公式的难度要从三个层面看，缺一个都会翻车。

视觉层面，公式不是线性文字，而是二维结构。分式有分子分母，积分有上下限，矩阵有行列对齐，求和符号的上下标都要悬挂在正确位置。PDF内部虽然记录了这些字符的位置坐标，但纯文本提取时只按字符顺序输出，结构信息全部丢失，你拿到手的是一堆散乱的“x”“2”“+”字符。

语义层面，同一组字符在不同语境下含义不同。比如“sin”在正文里可能是英文单词“sin”，在公式里是正弦函数，转存时必须识别出它是数学算子而不是普通文本，否则渲染端会把它当成三个独立的斜体字母，效果非常丑。

渲染层面，公式在网页上的呈现和普通文字不一样。普通段落是线性流式排版，公式则可能需要居中、对齐、缩放、跨行，而且在小屏设备上还要考虑换行策略。如果你只把公式转成图片，又会有分辨率模糊、无法检索、不能复制的问题，这对站群内容的SEO和用户体验都是硬伤。

1.3 三种转换路线对比：直接嵌入、截图、结构化转换

面对公式PDF，业界的方案大致分成三条路线，我在项目里都试过，效果天差地别。

直接把PDF文件或iframe嵌入页面——这条路线最“简单粗暴”，但基本不推荐。移动端加载几百KB的PDF要单独调起阅读器，用户跳出率极高，而且PDF内文字对搜索引擎来说是一整块难以解析的二进制流，关键词密度、锚文本这些SEO要素全部失效。如果PDF是动态生成的，还会额外消耗服务器资源。

把PDF页面截图，公式区域裁成图片放网页里——这是很多站群的妥协方案，能做，但有明显瓶颈。图片无法被搜索引擎理解，公式内容等于“不可见”，对站群的长尾流量获取几乎没有帮助。图片体积也大，一个页面几十张公式图，加载速度和带宽成本都扛不住。更麻烦的是图片中的公式细节放大会模糊，清晰度永远赶不上原生渲染。

结构化转换，也就是完整解析PDF后生成HTML+MathJax/KaTeX渲染的网页——这是唯一能兼顾排版、SEO、响应式体验的路线。虽然前期开发量最大，但转换后的内容是纯文本结构，公式以LaTeX或MathML形式嵌入DOM，搜索引擎可读，移动端可缩放，用户还能直接复制公式源码。做站群想长期稳定地吃PDF内容红利，这条路是绕不开的。

2. 公式识别与工具选型的核心逻辑

2.1 从PDF里“抠”出公式的三种技术路径

要让公式被识别出来，首先得在PDF的文本流中定位“哪里是公式”。这听起来容易，做起来有门道。我项目里同时用过三种定位方式，各有适用场景。

第一种是字体特征识别。PDF的标准数学字体，比如CM（Computer Modern）系列、MSAM、MSBM，以及很多出版社定制的数学符号字体，通常和正文字体完全不同。用PyMuPDF或pdfplumber读取每个字符的字体名，凡是匹配数学字体的字符，基本上就可以判定属于公式区域。这个方法最精准，但只对电子版PDF有效，扫描件没有字体信息。

第二种是位置坐标聚类。公式通常独立成行且居中，或者与正文混排但基线偏移明显。把页面上的字符按其y坐标聚类成行，再按x坐标判断是否有行居中对齐、行宽度异常，就能筛出一批“疑似公式行”。这个方法能处理一些字体信息不完整的PDF，但误判率偏高，需要配合规则过滤。

第三种是图像识别。当PDF已经是扫描图片或前两种方法都失效时，只能把页面区域渲染成图片，交给公式识别引擎（比如Mathpix API、开源LaTeX-OCR等）。这条路线最费资源，但也是兜底方案，扫描版的公式只有这一条路能走。

2.2 商用API与开源模型的实战对比

公式识别引擎我前后对比过Mathpix、SimpleTeX-OCR、PaddleOCR中的公式模块，还有个轻量的LaTeX-OCR。这里把关键差异列出来。

以我实际经验，纯文本型电子PDF不需要走识别引擎，直接解析文字层就能拿到足够好的结果。只有公式区域才需要裁剪成图片送给识别服务。所以我的推荐组合是：先解析文本层自动定位公式区域，再对定位到的公式块调用识别引擎，最后把识别出的LaTeX代码存下来。这样既控制成本，又保证质量。

注意：公式识别引擎输出的LaTeX经常有细微错误，比如把“1”识别成“l”，把“x”识别成“×”。我建议在入库之前加一道校验，至少检查花括号是否匹配、反斜杠命令是否合法，否则渲染端会直接报错。

2.3 为什么不推荐把公式直接存成图片

很多站群系统的开发者图省事，把识别出来的公式区域直接存成SVG或PNG，然后当图片插入网页。我明确说，这个方案只适合作为临时兜底，不适合作为长期架构。

公式图片有三个致命问题：第一是SEO价值为零，搜索引擎读不到图片内部的数学内容，站群做长尾词排名时，公式里的关键词全部失效；第二是缩放体验差，响应式正文里图片按百分比缩放，高DPI屏幕上公式容易发虚，读者要看清上标下标很费劲；第三是不可复制，用户想把公式复制到自己的文档或计算工具里做不到，这对技术文档类站点的信任度是严重打击。

正确做法是识别出LaTeX源码后，连同MathML或纯文本近似描述一起存入库，前端加载时用MathJax或KaTeX渲染成矢量图形。用户看到的公式是清晰锐利的，搜索引擎爬到的源码是可分析的，需要时还能一键复制LaTeX代码。这才是把公式“转存”成网页的正确理解。

2.4 双轨存储：LaTeX为主、MathML为辅

我最终采用的存储结构是“LaTeX主存储、MathML辅助、纯文本兜底”的三层设计。每条公式记录包含三个字段：latex_source存原始LaTeX命令，mathml_field存由LaTeX转换来的MathML（可以用latexml或pandoc转换），plain_text存人工可读的近似描述，比如“能量方程E=mc^2”。

LaTeX用于前端渲染，体积小、渲染快，MathJax对LaTeX的解析成熟度最高。MathML用于搜索引擎理解公式语义和结构，虽然主流搜索引擎对MathML的索引能力还在完善，但比起纯图片已经好太多。纯文本描述则用于站内搜索、摘要生成和移动端的无障碍读屏支持。三条数据各有用途，缺了哪条都会在某个环节卡壳。

这套双轨存储看起来增加了存储成本，实际上每条公式也就多几百字节，换来的却是“哪里都能用”的灵活性。我在做站群系统的内容API时，把这三个字段统一封装进一个JSON结构，后续不管是生成静态页面、动态接口还是RSS输出，都能直接复用，不用再回源解析。

3. 响应式网页转换的实现路径

3.1 从页面坐标到HTML结构的版面分析

PDF的本质是一张二维画布，字符都有精确的坐标，而HTML是流动的一维文档流。转换的核心工作就是把“坐标空间”还原成“语义空间”。

我处理时先做版面分析，把一页PDF拆成多个区块。用PyMuPDF读取页面的所有文本块、图片块、线条块，然后根据y坐标聚类判断哪些块属于同一行，根据x坐标和块间距判断哪些行属于同一段，再根据段落间距判断是否属于同一小节。这个步骤里最常犯错的是多栏排版，很多论文PDF是双栏的，如果按单栏顺序提取，内容就会左右互窜。我的处理规则是：统计页面左侧和右侧的文本块数量，如果两侧块数基本均衡，就先按x坐标分成左右两个栏，分别提取，最后再按栏序拼接。

公式块在这个阶段会被标记为“独立行”或“行内嵌入”。独立行的特征是整行居中、y坐标与上下文有较大间距、左右两侧没有正文文本；行内嵌入的特征是公式符号夹在两个单词之间，基线略微偏移。标记完成后进入不同的处理分支——独立行公式直接进入识别管线，行内公式则要保留在句子上下文中，识别后替换进段落HTML。

3.2 公式检测结果如何做上下文合并

公式识别最大的翻车点在于“切割不完整”。PDF里的公式块经常被文本提取器拆成了多段，比如一个分式结构的分子和分母被当成两行，一个长公式在多行软回行后变成了三个独立块，如果直接逐块识别，输出的LaTeX必然支离破碎。

我的合并策略分两步。第一步是根据坐标连续性做物理合并：两个文本块的y坐标差小于行高阈值、x坐标有重叠或相邻，就视为同行；同行中相邻字符间距小于正常词间距的，直接拼成同一公式串。第二步是根据语义规则做逻辑合并：识别结果里如果出现“分子没有分母”“括号缺失”这类结构异常，就把相邻公式块识别出的LaTeX源码拼接后重新解析校验。

这里有个很实用的兜底规则：如果同一个公式区域识别了三次还不通过结构校验，就不再强求LaTeX，而是降级为“公式图片+Alt文本”方案。与其为了一个复杂矩阵卡住整篇文档的流程，不如保底转图片，让页面先上线，后续再人工修正。站群系统讲究“吞吐优先”，不能被几个特例拖死。

3.3 响应式布局里公式的缩放与换行策略

公式渲染完成后，真正的响应式适配才开始。普通文本一句话可以自由换行，公式不行，分式的分子分母之间、矩阵的行列之间、积分上下标的位置都是强关联的，强行断行会导致结构错乱。

我采用三档自适应策略。第一档是大屏和中屏，公式保持原生大小，通过flex布局或grid布局让公式与正文混排，公式块宽度不超过容器宽度的92%，遇到超宽公式就整体水平缩放，用transform: scale()配合transform-origin实现。第二档是小屏手机，宽度小于640px时，行内公式如果过长就允许水平滚动，独立公式块设置max-width: 100%配合overflow-x: auto，让用户左右滑动查看完整公式。第三档是极端窄屏或PDF原公式本身就超宽，直接把公式块改为横向可滚动卡片样式，背景稍微区别于正文，并在滚动容器边缘做渐隐提示，告诉用户“这里还能往右滑”。

缩放策略里有个细节我踩过坑：不要对公式直接使用font-size百分比缩放。MathJax渲染出的SVG是按上下文基线对齐的，改字体大小容易导致上下标错位。要缩放就统一用“修改MathJax的scale配置+容器宽度约束”，而不是CSS硬调字号。CSS里可以这样处理：

.formula-block { max-width: 100%; overflow-x: auto; overflow-y: hidden; padding: 0.4em 0; -webkit-overflow-scrolling: touch; } .formula-inline { white-space: nowrap; vertical-align: middle; max-width: 100%; display: inline-block; overflow-x: auto; }

3.4 SEO适配：让搜索引擎能读懂公式内容

站群做公式文档转网页，如果只图“人看得舒服”，忽略搜索引擎，那就白白浪费了内容价值。公式页面在这方面的优化有不少窍门。

第一是保留LaTeX源码在页面里。MathJax渲染后的SVG对搜索引擎仍然是不可读的，我在页面底部会放一个隐藏的源码区，用noscript或details标签收纳公式的LaTeX源码，并配上纯文本近似描述。比如一个二项式定理，就写成“二项式定理 (a加b)的平方等于a平方加2ab加b平方”。这方面不能为了“隐藏”做display: none，搜索引擎和读屏工具都会忽略，最好用details/summary结构，既合规又不影响视觉。

第二是公式所在页面要配有正常的标题层级和段落标签。我生成的HTML里，PDF原有的章节标题会映射为h2/h3，正文段落映射为p，公式块放在figure标签内，figcaption里放公式编号和纯文本说明。这样搜索引擎能理解页面结构，长尾关键词也能通过纯文本说明进入索引。

第三是图片公式的Alt属性必须写全。降级为图片的公式，Alt文本不要用“公式1”这种占位，要把公式的可读含义完整写进去。实测下来，有一批Alt文本完整的公式图片页面，一个月内就收到了长尾词的搜索曝光，效果明显好于Alt为空的页面。

4. 实操：一套完整的PDF公式转网页流程

4.1 解析阶段：用Python提取文本块与公式候选区

我在这套流程里用的是Python技术栈，核心库是PyMuPDF和pdfplumber。前者擅长页面渲染和精细坐标读取，后者擅长表格提取和文本块聚类。思路是先用PyMuPDF打开PDF，逐页提取字符级信息，包括每个字符的文本、字体名、字号、坐标；然后把字符聚合成行和块；最后根据字体和位置规则标记公式候选区。

下面这段是我项目里的核心解析代码逻辑，主要用于演示流程，实际生产环境还要加异常处理和增量断点：

import fitz # PyMuPDF MATH_FONT_KEYWORDS = ("CMSY", "CMMI", "CMEX", "MSAM", "MSBM", "Math", "ESSTIX") def extract_blocks_with_formula_candidates(pdf_path, page_no): doc = fitz.open(pdf_path) page = doc[page_no] blocks = page.get_text("dict")["blocks"] formula_blocks = [] normal_lines = [] for block in blocks: if block["type"] != 0: # 跳过图片块 continue for line in block["lines"]: line_text = "" line_has_math_font = False line_chars = [] for span in line["spans"]: line_text += span["text"] line_chars.append((span["text"], span["font"], span["size"])) if any(mk in span["font"] for mk in MATH_FONT_KEYWORDS): line_has_math_font = True if line_has_math_font: formula_blocks.append({ "text": line_text, "bbox": line["bbox"], "font_chars": line_chars, "source": "font_detected" }) else: normal_lines.append(line_text) doc.close() return normal_lines, formula_blocks

实际运行时，我会再加一步“居中行补充检测”：有些公式虽然没用数学字体，但整行居中且左右留白明显，这类行也会并入公式候选区。要注意的是，补充检测会引入少量正文标题误判，需要额外过滤掉行内含中文数目超过一半的段落块。

4.2 识别阶段：公式区域裁剪与LaTeX回传

拿到公式候选区后，下一步是把这些区域渲染成图片并送入识别引擎。其实不需要重新渲染PDF整页，只需要根据bbox坐标用PyMuPDF直接截取局部区域，存成PNG。这样做速度更快，而且避免整页渲染中加入无关干扰。

我封装的识别函数大致是：将公式bbox适当放大margin（建议上下左右各加4像素），渲染后交给识别服务，返回LaTeX源码。如果是本地部署的LaTeX-OCR或PaddleOCR模型，调用方式就是加载模型后直接predict；如果用的Mathpix，就构造带app_id/app_key的HTTP请求。无论哪种方式，都要对返回结果做清洗——去掉空行、修正常见错字、合并多余的括号层级。

有个经验值得提一下：裁剪公式图片时，分辨率不要直接用PDF原尺寸，最好乘以2到3倍的缩放系数再渲染。否则一些小的上标、下标字符会糊成一团，识别引擎很容易出错。我通常用fitz里的Matrix(3, 3)截取公式区域，识别准确率能提升一截。

4.3 组装阶段：生成带MathJax的响应式HTML模板

当识别结果的LaTeX源码进入数据库后，组装阶段就是把它们写进一个标准的HTML模板。我采用的是“首屏服务端渲染+公式客户端渲染”混合模式：正文文本、标题、段落结构都直接写在静态HTML里，公式则先插入占位标签，页面加载后由MathJax统一渲染。这样做的好处是搜索引擎先抓到正文，用户看到的第一帧也不是空白。

模板里MathJax的配置需要针对站群场景调优。一面是要开启行内公式和独立公式的自动识别，另一面要关闭自动换行的默认行为，避免公式被MathJax强制打断。我的标准配置如下：

<script> window.MathJax = { tex: { inlineMath: [['$', '$'], ['\\(', '\\)']], displayMath: [['$$', '$$'], ['\\[', '\\]']] }, svg: { fontCache: 'global' }, options: { enableMenu: false, processHtmlClass: 'tex2jax_process' } }; </script> <script async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-svg.js"></script>

文本从数据库到HTML的拼装，我建议用一个模板引擎，轻量的Jinja2就够，避免手写字符串拼接。公式字段在模板中直接以\[ latex_source \]的形式输出，MathJax的TeX输入处理器会自动识别并渲染成SVG。静态化的HTML文件生成后，再统一进入站群系统的发布队列。

4.4 部署阶段：静态化生成与多站点分发

站群系统通常是多站点批量发布，所以我不会在用户请求时动态渲染PDF解析结果，而是预先离线生成好静态HTML，再通过发布队列分发到各站点服务器。这样有几个好处：解析和识别的耗时不会阻塞用户访问，静态页面可以直接交给Nginx或对象存储托管，页面响应速度和抗并发能力都远胜动态方案。

发布队列我按“批次+站点”双层管理。一批PDF完成转换后，生成一批HTML文件，然后按站点规则放入对应目录。每个站点可能需要不同的主题样式，所以模板要支持CSS变量覆盖——公式渲染区域的颜色、字体、间距等通过CSS变量控制，分发时只需替换变量文件，不需要重新生成HTML。

这一步做好后，整个流程就跑通了：PDF进入系统后，自动解析、识别、组装、发布，全程基本无人值守，站群运营人员只需要定期检查识别质量报表，处理个别异常文档。

5. 常见问题与排查技巧实录

5.1 扫描版PDF：公式识别结果全乱怎么办

扫描版PDF是所有方案里最难处理的一类，公式识别结果乱掉几乎是必然的。排查顺序是这样：先确认页面渲染质量，如果原PDF本身是低分辨率照片扫描（低于150DPI），识别引擎基本不可能输出有效LaTeX，这时候别浪费时间调参数，直接上图像预处理。

我的预处理管线包括：灰度化、去噪、对比度增强、二值化、倾斜校正。OpenCV做这套很成熟，几步操作就能把模糊的扫描页变成清晰的二值图像。倾斜校正尤其重要，扫描页稍微歪个几度，公式的结构就全偏了，识别引擎会连分式都分不清。

如果预处理后仍然乱，就降低预期：确认这段内容适合不适合站群收录。如果只是个别复杂公式识别失败，降级为图片方案完全可以接受；但如果整页都是密集的矩阵推导，建议干脆放弃这一页，不要硬塞损坏的LaTeX进页面，否则渲染出来的网页错漏百出，用户一看就知道是机器转换的半成品，对站点信任度损伤很大。

5.2 电子版PDF：公式被文本层拆碎无法重组

电子版PDF的公式字符虽然能提取，但经常被拆成一堆带坐标的碎片字符。比如积分符号、上标“2”、变量“x”分别位于三个文本span里，不做重组就识别，结果必然是一团乱麻。

我的重组思路是“以基线聚类、以间距拼接”。用字符的y坐标聚合出数学基线，然后把基线高度相近的字符按x坐标从小到大排序合并为行，遇到字符间x间距大于正常字距的点时再断开成不同单词。分式的分子和分母基线和主基线不同，这种行不能简单合并，要保留垂直层级信息。

实际调试中我发现，PDF导出工具对公式的拆分规律很固定，基本都跟着来源软件的排版规则走。如果你经常处理同一种来源的PDF（比如都是LaTeX导出），可以针对这种来源固化一套重组合并规则，准确率会大幅提升。如果是混合来源，就靠通用基线聚类兜底，能覆盖八成场景。

5.3 前端渲染：公式闪烁、样式错位、加载崩溃

公式在浏览器里渲染，最常见的问题是“闪烁”和“错位”。闪烁是因为MathJax在DOM加载后才把LaTeX转成SVG，页面先显示源码再替换成公式，视觉效果很糟。错位则是因为公式SVG默认的baseline和正文的vertical-align不一致，导致公式高于或低于相邻文字。

闪烁的解法是“预渲染”。可以引入MathJax的node服务端渲染模块，在静态生成阶段就把LaTeX渲染成SVG字符串直接写入HTML。如果不想引入node，就用MathJax的startup.promiseReady配合页面加载完成后立即排版，同时给公式容器加一个最小高度占位，减少视觉跳动。错位的解法是在CSS里给行内公式设置统一的vertical-align，不同公式类型可以微调，我实践下来vertical-align: -0.5ex对多数公式效果比较稳定。

加载崩溃大多发生在两种情况：一是页面公式数量太多，MathJax全局渲染时内存飙高；二是LaTeX源码里有非法命令，MathJax解析时直接报错中断。前者需要把一次性全页渲染改为懒加载渲染，滚动到可视区再排版；后者要在入库时做LaTeX语法校验，发现非法命令就标记降级，不送往前端。

5.4 SEO效果不理想：公式内容没有进入搜索索引

公式页面发布后跑了一段时间，发现搜索关键词还是出不来排名，这大概率不是转换流程的问题，而是公式内容没有被搜索引擎看进眼里。我排查过一轮，总结出三个高频原因。

第一个原因是公式页面的纯文本描述写得太泛。原PDF的数学内容没有在正文中以自然语言体现，搜索引擎无法理解公式的语义。我的改进办法是，解析PDF时同时提取公式前后的上下文段落，自动拼接成一段包含公式含义的自然语言描述，放在公式的figcaption里。比如识别出“\sum_{i=1}^{n} i = n(n+1)/2”，figcation就写“从1到n的整数求和公式，结果等于二分之n乘以n加1”。这样搜索引擎就能抓到“求和公式”这个关键词。

第二个原因是页面的正文太少，整页都是公式和图片，文本密度不够。解决方向是扩展公式相关的解释性文字，比如在公式前后补一段文档内容中的背景介绍、变量说明、例题应用。这不是硬凑字数，而是把PDF里已有的上下文结构化呈现，既有利于SEO，也方便读者理解。

第三个原因是站群多个站点重复发布同一批PDF内容，导致大量重复页面互相竞争。我的处理原则是“同源不同侧写”：不同站点围绕同一PDF的相同公式内容，要改写不同的引导段、不同的描述语言、不同的案例场景，页面主体虽然共享数据，但表达方式和元信息区分开，最大限度规避重复度检测的负面影响。

6. 流程跑通后的几点个人体会

整个过程从最初踩坑到流程稳定，我最大的感受是：PDF公式转响应式网页，技术难度不在某一个环节，而在“串联”。单看解析、识别、渲染，每一段都有成熟工具，但把它们拼成一条能批量跑、可监控、出错自动降级的流水线，才是站群系统真正需要解决的工程问题。

如果只让我给两个最核心的建议：第一，入库数据一定要“LaTeX为主、纯文本兜底”双轨存，不要只存渲染结果，否则以后想换渲染器、想做搜索摘要、想接API全都得重新解析一遍；第二，识别失败的公式不要死磕，设好降级策略——图片+Alt文本可以保证页面先上线，后续再安排人工修正队列慢慢补齐。

这套方案跑下来，我们手里的PDF文档转化成功率（指生成完整可访问响应式页面的比例）稳定在82%左右，剩余18%大多是扫描质量过差或多层嵌套的复杂推导公式，这类内容人工干预一次就能入库，整体运营效率比早期“直接挂PDF”的方式高了三倍不止。后续我还在尝试把公式识别结果接入自动摘要生成，让每个公式页面的描述段落自动产出，那样连人工撰写引导段都可以省掉一大部分。