企业官网建设流程全解析

手头一批 400 多页的扫描件，丢进 Umi-OCR 点了开始，去泡了杯茶回来，进度条才挪到三分之一。这个场景大概每个用离线 OCR 处理过大批量文档的人都遇到过。Umi-OCR 本身是个相当能打的开源离线文字识别工具，界面干净、不用联网、支持截图识别、批量图片识别、PDF 文档识别，还能顺带做二维码和部分公式识别，装完就能用，对不想折腾环境的人非常友好。但“能用”和“跑得快”之间，隔着一段不小的距离。默认配置是给通用场景准备的保守值，它优先保证的是“不出错”，而不是“跑满你的机器”。

这篇内容就是把这段距离拆开讲清楚。所谓“300% 提速”，不是某一个开关一按就飞起来，而是把引擎选型、模型档位、线程并发、图像预处理、硬件加速、任务编排、流水线接入这七个环节里被浪费掉的时间，一段一段捡回来。单看每一环可能只是 20%、30% 的提升，叠在一起，同一批任务从 40 多分钟压到 10 分钟出头是完全做得到的。适合两类人看：一类是经常要批量处理扫描件、发票、合同、论文 PDF 的办公用户，另一类是想把 OCR 接进自己脚本流水线的开发者。前者看操作，后者看参数和接口。

1. 先定位瓶颈：300% 提速到底快在哪一段

1.1 OCR 耗时的真实分布，别把什么都算成“识别慢”

很多人一觉得慢，第一反应就是“模型不行，换个更强的”。这个判断十次里有七八次是错的。一次完整的批量识别，时间其实分散在五个环节：文件读取与解码、图像预处理、文本检测（找文字框）、文本识别（认字）、结果后处理与写盘。真正吃时间的通常不是最后那个“认字”的动作，而是前面几个被忽略的环节，以及后端进程之间的数据搬运。

我拿一批 300 页的 A4 扫描件做过拆解记录。这批文件是 300dpi 的彩色 PNG 转成的 PDF，单页图像在 2500×3500 像素左右。默认配置下总耗时约 42 分钟，按环节大致是这么分布的：PDF 拆页与图像解码约 4 分钟，图像缩放与预处理约 3 分钟，检测模型推理约 12 分钟，识别模型推理约 18 分钟，结果合并写盘约 5 分钟。可以看到，检测加识别占了七成，但如果把输入图像的长边从 3500 压到 1600，检测和识别这两块的耗时几乎直接砍半，因为模型内部的卷积计算量和输入像素数基本是平方级关系。

这就是为什么第一个动作永远应该是“定位”，而不是“乱调”。你需要的是一份能对照的耗时基线：同一批 20 页样本，用默认配置跑一遍，记下总耗时；然后每次只改一个变量，再跑一遍。改了什么、快了多少、有没有掉准确率，三列记下来。这个过程听起来笨，但它能让你在半小时内搞清楚自己机器的瓶颈到底在 CPU 算力、磁盘 IO，还是后端的进程通信上。后面七个秘诀的收益大小，全都取决于你这个基线测得准不准。

1.2 一张表看清你的瓶颈属于哪一类

不同瓶颈的表现完全不同，对号入座比盲目试参数高效得多。下面这张表是我自己整理的经验对照，症状、原因、优先动作三列，遇到问题先查表再动手。

表里最容易被忽视的是第三行和第四行。图像分辨率这件事，很多人有个直觉误区，觉得“分辨率越高识别越准”。在 OCR 里这个关系是有拐点的：长边从 800 提到 1600，准确率确实会上去；从 1600 提到 3000，准确率提升微乎其微，耗时却翻倍。因为主流检测模型的输入边长本来就有上限，超出的部分会被缩放掉，你喂进去的高清像素根本没参与计算，只是白白消耗了解码和缩放的时间。所以对于 300dpi 的扫描件，先降采样再识别，是性价比最高的一刀。

而“越跑越慢”这个现象，多半是输出文件在膨胀。如果输出格式选了带完整坐标信息的结构化格式，几万个文本块累积下来，单个结果文件能到几十兆，写盘和后续解析都会拖后腿。批量任务里，输出格式的选择对总耗时的影响有时候能到 15% 以上，这一条后面第八章还会细说。

2. 秘诀一：选对后端引擎，先把地基打对

2.1 三种常见后端引擎的机制差异

Umi-OCR 的界面和识别核心是分离的，界面负责调度，真正的识别活儿交给后端引擎进程干，两者通过本地管道通信。这个设计的好处是引擎可以换，坏处是不同引擎的性能特性差别很大，选错了后面怎么调都事倍功半。

常见的几类后端，一类是基于 PaddleOCR 体系的 JSON 管道引擎，一类是基于 ONNX Runtime 的轻量引擎，还有一类是集成了多种推理后端的聚合型引擎。它们的核心差异在于三点：模型体积、推理框架的算子优化程度、以及是否支持 MKLDNN 或类似的一类 CPU 指令集加速。

基于 PaddleOCR 的引擎精度上限高，中文长文本、竖排、复杂版面的表现更稳，代价是模型大、首次加载慢、单页耗时偏高。基于 ONNX Runtime 的轻量引擎模型小、启动快、单页耗时明显低，适合版面干净、字体规范的文档，比如打印体合同、发票、标准排版的书页。聚合型引擎的好处是可以在界面里切来切去，不用手动换目录。

关键结论是：如果你处理的是规整的打印文档，轻量引擎在速度上能领先一大截，实测在同样输入下，单页耗时能差到 2 倍以上；如果你处理的是手写、古籍、复杂表格、多语言混排，那还是老老实实用精度更高的引擎，速度慢点但返工少，总体算下来反而更快。

2.2 切换操作与实测对比

切换引擎在设置里的“引擎”或“插件”相关选项里完成，不同版本入口位置略有差异，通常在全局设置里能找到引擎选择下拉框或者引擎管理页。切换的核心动作是两步：先选引擎类型，再确认对应的语言库已经下载好。语言库没下全的时候，引擎会加载失败或者自动回退，这时候你看到的“慢”其实是回退到了默认引擎。

我在同一台四核八线程、16G 内存、无独立显卡的办公机上做过对比，输入是 20 页规整的打印体 PDF，长边统一压到 1600，其他参数保持一致：

这个差距很说明问题。同一批文件、同一台机器，光换个引擎就是 2.4 倍的差距。所以第一个秘诀的价值在于，它决定了你后面所有调优的基数。地基没打对，线程调到 16 也救不回来。

注意：切换引擎之后一定要用同一批样本重跑一次基线，不要凭感觉判断。不同引擎对同一张图的检测框切分逻辑不一样，耗时和结果的段落结构都会变，混着比较很容易得出错误结论。

还有一个实操细节值得说：引擎进程是常驻的，第一次启动要加载模型，这段加载时间在小批量任务里占比很高。如果你只是识别三五张截图，那引擎加载的两三秒可能比识别本身还长。这种情况下别急着优化参数，直接把软件开着不关，让引擎进程活着，后续调用就是热的。这一点在截图识别的场景里尤其明显，热启动和冷启动的体感差别就是“秒出”和“等一下”。

3. 秘诀二：模型档位与语言库的取舍

3.1 轻量模型和精确模型的耗时差距从哪来

同一个引擎内部，模型通常还分档位。以 PaddleOCR 体系为例，检测和识别各自都有 mobile 和 server 两套权重。mobile 版本通过通道剪枝把骨干网络的宽度压下来，参数量可能只有 server 版的几分之一，推理时的浮点运算量随之下降。反映到实际耗时上，在 CPU 环境下，mobile 模型的识别阶段通常能比 server 模型快 2 到 3 倍，检测阶段的差距略小一些。

准确率上的差距则高度依赖你的文档类型。打印体、字号规范、对比度好的文档，mobile 和 server 的差距经常在 1 个百分点以内，人眼几乎看不出差别。但遇到小字号、低对比度、有背景纹理、或者中英混排加符号的情况，server 模型的优势就会显现出来。所以这里的取舍不是“哪个更好”，而是“你的文档配得上哪个档位”。

我的做法是做一个两段式判断：先拿 30 页有代表性的样本，用 mobile 跑一遍，人工抽查 100 个关键字段（金额、编号、日期这类不能错的），错 2 个以内就定 mobile，继续用；错 3 到 5 个，看这些错误是否集中在某几类版面上，如果集中，可以对那几类单独用精确模型跑第二遍；错超过 5 个，直接上精确模型，别在速度上纠结了。

3.2 按场景选模型的决策表

下面这张表把常见文档类型和推荐档位对应起来，可以直接抄。表中的耗时倍数是相对同引擎 mobile 档的粗略比值，用来做量级判断，不是精确数值。

语言库的选择也影响速度，这点很多人不知道。语言库不是越多越好，加载多个语言库会让识别阶段的分类头变大，字符集搜索空间也随之扩大。如果你只处理中文和英文，就别把日文、韩文、俄文的库都挂上。每多挂一个库，解码阶段的候选计算都会增加一点，累积到几千页就是可观的时间。清理方式很简单，在语言库管理里把用不上的卸载掉，只保留当前任务需要的。

提示：切换模型档位后，第一次识别会重新加载权重，这段加载时间不算在稳态耗时里。做对比测试时，每组配置都先跑一页热身，把冷启动排除掉，数据才有可比性。

还有一个经验：批量任务里不要中途改档位。有些版本的引擎在运行中切换模型会触发进程重启，正在排队的任务会重新走一遍加载流程，反而更慢。要改就等当前批次跑完，或者干脆分成两个批次跑。

4. 秘诀三：线程数与并发进程的最优解

4.1 单进程多线程的真实瓶颈在哪

引擎进程内部通常有一套线程池，控制推理时并行计算的核心数。这里的参数在 PaddleOCR 体系的引擎里一般叫 CPU 线程数，在配置里对应 cpu_threads 之类的字段。默认值往往偏保守，比如 4 或者更少，因为在低配机器上开太多线程会导致频繁的上下文切换，反而掉速。

但要注意，线程数不是越大越好，也不是“等于核数”就最优。原因是 OCR 推理里既有计算密集的卷积，也有大量访存操作，还有前后处理里的串行部分。线程数超过物理核心数之后，收益会迅速衰减。我在这台四核八线程机器上测过一组数据，输入是 20 页规整文档，其他参数固定：

拐点很清楚：在这台机器上，线程数设到接近逻辑核心数是甜点，再往上就开始被调度开销吃掉。如果你的机器是八核十六线程，甜点大概在 8 到 12 之间，具体要自己测。测法很朴素：从核数的一半开始，每次加 2，跑 10 页样本，记时间，画个折线就一目了然。

4.2 并发进程数怎么算，别把机器跑死

线程数解决的是单进程内部的并行，并发进程数解决的是“同时跑几个任务”。在批量场景里，后者的收益有时候比前者更大，因为单个任务在文件解码、写盘这些阶段是 IO 密集的，CPU 其实在等。开两到三个引擎实例并行处理不同的文件，能把这些等待时间填满。

但并发数有个硬约束：内存。每个引擎实例都要把模型权重加载一遍，轻量引擎的模型可能占几百兆，精确模型能到 1G 以上。四个实例就是好几 G，再加上操作系统和其他程序，16G 内存的机器开四个精确模型实例很容易开始换页，一换页速度直接崩。

我的配置公式是这样：可用并发数等于（物理内存减去系统占用后余量）除以单实例峰值内存，再和 CPU 核心数除以单实例推荐线程数取小值。举个具体例子，16G 内存的机器，留 4G 给系统，剩 12G；轻量引擎单实例峰值按 0.6G 算，内存维度允许 20 个；CPU 八核，单实例推荐 6 线程，CPU 维度允许 1 个多一点的实例。取小值，实际操作就是开 2 个实例、每个 4 线程，这样既不会互相抢核，也能让 IO 和计算重叠起来。

还有一个坑要说：并发实例数超过 2 之后，磁盘 IO 很容易成为新瓶颈，尤其是机械硬盘或者网络盘。表现是所有实例都在等读写，CPU 占用反而不高。这种时候就别加实例了，先把源文件批量转存到本地固态盘，收益比调参数大得多。

5. 秘诀四：图像预处理里性价比最高的几刀

5.1 长边限制：一个参数顶三个优化

前面提过，检测模型的输入边长有上限，喂进去超出的像素会被缩放掉。所以正确做法是在预处理阶段就自己把图缩到合适的尺寸，把缩放的成本前置到更便宜的环节，同时减少后续模型的无效计算。这个参数在 PaddleOCR 体系的引擎配置里一般叫边长限制，默认值常见是 960 左右。

这个值怎么定？我的经验是分档：纯文本、字号正常的文档，长边 1280 到 1600 就够；含表格、小字脚注、密集排版的，提到 1920 到 2048；需要识别极小字号或者图像本身分辨率极低的，才考虑更高。把 300dpi 的 A4 扫描件（长边约 3500）统一压到 1600，我在实测里看到识别阶段耗时下降接近四成，而关键字段的准确率没有可见变化。

注意：降采样要用高质量的重采样算法，别用最近邻。最近邻会产生锯齿，反而让文字边缘变差，准确率掉得莫名其妙。这一步在 Umi-OCR 的界面里不一定能直接选，可靠的做法是用外部工具先批量处理好图像或 PDF 再喂进去。

对于 PDF 输入，还有个额外技巧：如果原 PDF 是纯图片扫描件且文件巨大，先用轻量的 PDF 处理库把每页降采样重编码，再交给 Umi-OCR。这一步能同时解决两件事——识别变快，以及拆页阶段不那么卡。

5.2 灰度、二值化、去噪和空页跳过

彩色转灰度是另一刀，成本极低，收益稳定。三通道变单通道，解码和预处理的访存量直接降到三分之一。对绝大多数黑白文档来说，转灰度对准确率没有任何负面影响。二值化要慎用，自适应阈值在光照不均的扫描件上容易把细笔画切掉，除非你的源图像对比度非常干净，否则不建议默认开启。

去噪和纠偏属于“看情况”。轻度椒盐噪点可以用中值滤波处理，倾斜角度超过 2 度的页面建议先做纠偏，否则检测框会歪，识别阶段要多花力气还容易出错。但纠偏本身也有成本，对极大量任务来说，如果源文件本来就摆得很正，这一步纯属浪费。

空页跳过是个很实用的省时点。扫描件里经常夹杂空白页、纯图页、目录页，这些页在识别阶段照样会跑一遍完整流程，然后得到空结果。如果你的文档集里空白页占比有 10%，跳过它们就是 10% 的时间省下来。实现方式上，可以用一个极轻量的像素方差判断，方差低于阈值的直接标记为空白，不送进引擎。这个判断的计算成本相比一次完整 OCR 可以忽略不计。

具体操作上，可以把预处理做成一个独立的批处理脚本，跑在所有识别任务之前，把图像统一到同一个规格。下面这段是思路示意，用 Python 加常见图像库实现，重点是流程结构：

from PIL import Image, ImageOps, ImageFilter import os TARGET_LONG_SIDE = 1600 BLANK_VAR_THRESHOLD = 8.0 def preprocess(src_path, dst_path): img = Image.open(src_path) img = ImageOps.exif_transpose(img) # 彩色转灰度，直接砍掉三分之二的通道数据 img = img.convert("L") # 长边限制，保持比例 w, h = img.size long_side = max(w, h) if long_side > TARGET_LONG_SIDE: scale = TARGET_LONG_SIDE / long_side img = img.resize((int(w * scale), int(h * scale)), Image.LANCZOS) # 极轻量的空白页判断 stat = img.convert("L").getdata() mean = sum(stat) / len(stat) var = sum((p - mean) ** 2 for p in stat) / len(stat) if var < BLANK_VAR_THRESHOLD: return False img.save(dst_path, quality=92) return True

这段代码里最值钱的是两个常量。长边 1600 是速度和准确率的一个经验平衡点，空白方差阈值 8 是个保守值，宁肯漏判也别误杀有内容的页。实际用的时候建议先拿 50 页样本跑一遍，看看被判定为空白的页里有没有误伤，再微调这个阈值。

6. 秘诀五：硬件加速的开启条件与收益边界

6.1 什么时候开 GPU 才不是白折腾

很多人一听提速就想上显卡。这事得算账。GPU 的优势在于大规模并行矩阵运算，模型越大、批量越大，收益越明显。但对于轻量 OCR 模型这种体量的网络，单张图在 GPU 上的推理时间可能只有几十毫秒，而把图像从内存搬到显存、把结果搬回来的开销，加上驱动层的调度延迟，很可能把这点优势全部吃掉。小批量任务里，GPU 版本比 CPU 版本还慢的情况非常常见。

我的判断标准有三个，同时满足才值得开：一是批量足够大，单次任务至少几百页往上，能把模型加载和上下文初始化的开销摊薄；二是用的是精确档位模型，网络更深，GPU 的并行优势才发挥得出来；三是机器上的显卡确实有可用显存，且驱动和推理后端匹配。三条里缺一条，我都建议老老实实用 CPU，把精力放在线程和预处理上，那两项的收益更确定。

还有一类中间方案值得提：某些推理后端支持在核显或入门独显上做加速，不用装完整的环境，配置成本低。这类方案的收益介于纯 CPU 和独立显卡之间，对轻薄本用户比较友好，但稳定性依赖驱动版本，跑批量任务前一定要先小规模验证，别一次丢几千页进去中途崩掉。

6.2 显存、驱动与回退策略

真要用硬件加速，几个参数必须提前确认。显存占用大致等于模型权重大小加上批处理时的中间张量，轻量模型可能只占几百兆，精确模型能到 1.5G 以上。批量尺寸设得越大，中间张量越大，显存越容易爆。显存一爆，后端要么直接报错，要么悄悄回退到 CPU，而你从界面上看不出区别，只会觉得“怎么开了加速还这么慢”。

所以回退策略要提前设计好。我的做法是：先用单页测试确认加速路径真的生效，比如看日志里有没有加载对应的执行后端，或者看 GPU 占用有没有起来；然后逐步加大批量，找到显存占用的上限；正式跑的时候留 20% 的显存余量，别贴着上限跑。同时准备好纯 CPU 的配置作为备份，一旦出现异常，切回去继续跑，不至于整批任务卡死。

提示：驱动版本和推理后端的匹配关系很容易出问题，尤其是系统自动更新之后。跑大批量任务之前，先拿 5 页样本验证一遍完整流程，包括加载、识别、写盘，这个习惯能帮你避开很多“跑到一半挂了”的事故。

另外一个容易被忽视的点是电源策略。笔记本用电池的时候，系统会把 CPU 频率压下来，这时候你测出来的耗时和插电时能差 30% 以上。做任何性能对比，都插着电、把电源计划设成高性能，否则数据毫无意义。

7. 秘诀六：批量任务编排，断点续跑和结果复用

7.1 PDF 分片处理与断点续跑

几百页的 PDF 一次性丢进去，最大的风险不是慢，是中途出问题要重来。引擎进程崩一次、内存涨上去被系统杀掉、或者你不小心关了窗口，前面几十分钟就白费了。解决办法是把大任务切小，按页范围分片，比如每 50 页一个批次，每个批次独立输出。

分片的好处有三个：失败只丢一个批次；可以并行处理多个批次；可以根据每批的耗时估算总进度，心里有数。分片的粒度怎么定？我一般按“单批耗时控制在 5 到 10 分钟”来反推页数。太快了批次管理开销占比高，太慢了失败损失大。50 到 100 页是个比较舒服的区间。

断点续跑的判断逻辑很简单：跑之前先扫一遍输出目录，把已经存在且非空的输出文件对应的源文件挑出来跳过。这个逻辑用几行脚本就能实现，但它省下的时间可能比任何参数调优都多。尤其是那种需要反复迭代、调整参数重跑的场景，每次都从头来一遍是纯粹的浪费。

7.2 结果缓存与重复内容去重

还有一类浪费特别隐蔽：重复识别同样的内容。比如同一份文档的不同版本，大部分页是一样的；或者批量任务里混进了重复文件。这种情况可以用文件内容哈希做去重，识别前先算哈希，命中已有结果就直接复用。

缓存的另一个用法是字段级复用。有些业务场景是同一批固定模板的票据，字段位置高度一致，第一次识别之后可以把结果结构存下来，后续只需要校验关键位置。这种做法严格说不算 OCR 提速，但它是端到端流程的提速，效果往往比调引擎参数更明显。

下面这个批处理编排的骨架，思路可以直接搬：

import hashlib, os, json CACHE_DIR = "./ocr_cache" os.makedirs(CACHE_DIR, exist_ok=True) def file_hash(path): h = hashlib.md5() with open(path, "rb") as f: for chunk in iter(lambda: f.read(1 << 20), b""): h.update(chunk) return h.hexdigest() def plan_tasks(src_files): todo, skipped = [], [] for p in src_files: key = file_hash(p) cache_path = os.path.join(CACHE_DIR, key + ".json") if os.path.exists(cache_path) and os.path.getsize(cache_path) > 0: skipped.append((p, cache_path)) else: todo.append((p, cache_path)) return todo, skipped

这段代码的关键在于缓存键用的是文件内容哈希而不是文件名。文件名会变、会被重命名、会带版本号，内容哈希才是稳定的。跳过逻辑放在计划阶段，一次算完，别在识别循环里反复判断，那样判断本身的成本就上去了。

8. 秘诀七：把识别接进脚本流水线

8.1 命令行调用与管道接口

界面上点来点去适合零散任务，真正要跑量，还是得走命令行或者接口。Umi-OCR 提供了命令行参数支持，常见的用法是直接触发截图识别、从剪贴板识别，或者把指定文件路径传进去做批量处理。不同版本的参数名有差异，用之前先跑一遍帮助命令看清楚，别照抄网上的旧参数。

# 先看当前版本支持哪些参数 Umi-OCR.exe --help # 典型用法：传入文件路径批量识别 Umi-OCR.exe --path "D:/docs/batch_01"

如果你想更细粒度地控制，比如自己决定什么时候发请求、什么时候收结果，可以直接对接后端引擎的管道接口。这类引擎通常支持标准输入输出通信：往标准输入写一行 JSON，里面带上图片路径和参数；从标准输出读一行 JSON，拿到识别结果。这种方式的优势是没有界面开销，上下文可以长期保持，特别适合做成常驻服务。

走管道接口要注意两点：一是编码，Windows 下的管道默认编码容易出问题，读写两端都要显式指定 UTF-8；二是帧边界，一行一个请求一行一个响应，别让结果里的换行把消息切碎，通常引擎会做转义处理，但自己解析的时候要留个心眼。

8.2 输出格式选择与磁盘 IO 优化

输出格式这件事，在几百页的规模上影响不大，上了几万页就很可观。带完整坐标、置信度、段落结构的结构化格式，单页可能几 KB 到几十 KB，几万页下来是几百兆的写入量。如果你的下游只需要纯文本，那就直接输出纯文本，别为了“以后可能用得上”保留全部信息。

写盘还有个技巧：批量输出时把文件按批次分目录，避免单个目录下堆几万个文件。文件系统在超大目录下的索引开销会明显上升，尤其是那些对小文件处理不友好的文件系统。分目录之后，不仅写入快，后续排查和重跑也方便定位。

另外，如果你下游还要做文本清洗、字段抽取，尽量把这一步和识别解耦，别在识别进程里同步做。识别是 CPU 密集，清洗通常也是，两者串在一起会互相拖慢。分成两个阶段，中间用文件或者消息队列过渡，整体吞吐往往更好。

9. 提速翻车现场：常见问题与排查清单

9.1 五种越调越慢的典型情况

调优这件事有个反直觉的地方：很多看起来“应该更快”的操作，实际结果是更慢。我把踩过的整理成五条。

第一条，线程数拉到远超核心数。前面表格里已经看到，12 线程比 8 线程慢了一截。上下文切换的成本在 OCR 这种混合负载里格外明显。

第二条，并发实例开太多。四个实例在四核机器上跑，每个实例都在等 CPU，总耗时比单实例还长，而且内存压力上来之后系统整体变卡，连界面都点不动。

第三条，盲目提高输入分辨率。有人觉得识别不准就把图放大，结果检测阶段耗时翻倍，准确率一点没涨。放大不会凭空产生细节，只会让模型多算一遍已经有的信息。

第四条，同时开一堆优化还改参数。一次只改一个变量这个原则，在性能调优里是铁律。同时改五个参数，变快了不知道为什么快，变慢了也不知道是谁拖的，最后只能全盘回退。

第五条，把预处理放在识别循环里做。每识别一页就现场缩放一次，重复计算。正确做法是预处理作为一个独立阶段先跑完，输出统一规格的中间文件，识别阶段直接吃现成的。

9.2 排查速查表，按症状找原因

排查的核心方法论就一句话：控制变量，单点验证。任何一次调整，都要有一个可对比的基线，并且只动一个地方。这条听起来枯燥，但它能让你在半小时内定位到问题，而不是在参数海洋里游一下午。

最后分享一个我自己的习惯。每次做比较大的批量任务之前，我都会先抽 20 页做一次全流程预演，从预处理到识别到输出到下游解析，全跑通再放量。这 20 页花掉的几分钟，帮我避开过好几次“跑到 80% 才发现输出格式不对”的返工。速度优化到后面，真正的瓶颈往往不是某个参数，而是流程里那些会让人重来一遍的环节，把重来的可能性掐掉，比把单页耗时再压 0.1 秒划算得多。