从图片到可编辑 Word：DocLens 本地 OCR 文档结构化还原实战

把一摞纸质合同摊在桌上，用手机一张张拍完，再把图片里的文字敲进 Word——这套动作我干过整整两年。直到后来我给自己搭了一条本地流水线：图片丢进去，版面、段落、表格、标题层级一起还原，最后吐出一个可以直接改的 .docx。这套流程里我试过不少方案，最后稳定留下来的就是这个叫 DocLens 的开源扫描工具。它做的事情说起来很朴素：把图片里的文字识别出来，再按接近原始版面的结构重新排进 Word 文档。但真正上手你会发现，"识别出字"和"还原成能用的文档"之间隔着一条不小的沟，沟里全是分辨率、透视变形、多栏串行、表格错位这些细节问题。这篇内容我打算把这条流水线从头到尾拆开讲清楚：它是怎么设计的、每个参数为什么这么设、批量处理怎么组织、出错以后怎么定位。适合手头有一堆纸质资料要数字化的人，也适合想自己改源码加功能的人，哪怕你之前完全没碰过 OCR，跟着走也能跑通。

1. 为什么我最后选了本地 OCR：DocLens 的整体设计思路

1.1 从"拍完照就完事"到"结构化还原"的痛点拆解

很多人对图片转文字的理解停留在一个很浅的层面：能认出来就行。我最早也是这么想的，随手找个在线识别页面，粘一段文字下来，能用就完事。真正做批量整理的时候才发现，识别准确率只是第一道门槛，后面还有三道更烦人的关卡。

第一道是版面丢失。在线工具给你的通常是一整段纯文本，原本的标题、缩进、段落分隔全部消失，一份两页的说明文档识别完变成三千字的一坨，你还得手工重新分段、重新加标题。第二道是表格塌方。表格里的文字被识别成一串按行拼接的字符，行列关系彻底断掉，这时候你唯一的办法是对着原图一个格子一个格子往回填。第三道是校对成本。识别率 97% 听起来很高，但一万字里就有三百个错字，逐字核对的时间可能比你自己敲还长。

DocLens 的设计思路正是奔着这三道关卡去的。它没有把 OCR 当成终点，而是把 OCR 当成流水线中间的一环，前后各加了一道工序：前面做图像预处理和版面分析，后面做结构重建和 Word 导出。这个思路上的差别很关键——纯 OCR 引擎关心的是"这一小块图里是什么字"，而文档扫描工具关心的是"这些字在页面上处于什么位置、属于哪个层级"。前者输出的是字符串，后者输出的是一份带结构的文档。

我在实际项目里对比过这两种路径的工作量。一份 20 页、含 6 张表格的技术资料，纯 OCR 方案识别完成之后，我花了大概两个小时重新排版；走 DocLens 这条结构化流水线，识别加校对一共四十分钟左右。差别不在识别速度上，而在返工量上。

1.2 DocLens 的四层流水线架构与选型取舍

DocLens 内部大致可以分成四层，我按数据流动的顺序说。

第一层是图像预处理层。输入是一张手机拍的照片或者扫描件，输出是一张"规整"过的图像。这一层做的事包括：自动判断旋转角度并摆正、检测纸张边界并裁掉桌面背景、估计背景光照并去掉阴影、做适度的对比度拉伸和锐化、把分辨率归一化到适合模型推理的尺寸。这些动作看起来琐碎，但它们的性价比极高——同一张照片，做过透视矫正和没做过的，识别率能差出十几个百分点。

第二层是版面分析层。它不认字，只认"区域"。把页面切成若干个块：正文段落块、标题块、表格块、图片块、页眉页脚块。这层的输出是一组带坐标和类型的框。有了这层，后面才知道哪些文字该按段落处理，哪些该走表格还原，哪些该直接丢弃。

第三层是识别层。对每个文本区域做两件事：文本检测（找出每一行文字的位置，用的是基于可微分二值化的分割网络这一类方案）和文本识别（把每一行的图像转成字符序列，主流做法是卷积特征加序列解码）。中间还会插一个方向分类器，处理那些被旋转了 90 度或 180 度的行。

第四层是重建与导出层。根据第二层的区域类型和第三层的文本内容，重新组织阅读顺序，推断段落边界和标题层级，还原表格的行列结构，最后用文档生成库写出 .docx 文件。

为什么选这种四层分明的架构，而不是端到端一个大模型全搞定？我理解主要是可调试性。端到端方案的优点是省事，缺点是出错之后你不知道该改哪儿——是图没处理好，还是检测框偏了，还是识别模型不认识这个字体？分层之后每一层都有中间产物可以单独 dump 出来看，排查问题的效率完全不是一个量级。我后面第 5 节讲的排查方法，全部建立在这个分层结构上。

提示：如果你打算二次开发，建议先去配置里把各层的中间结果输出开关打开，跑几张典型图片，把预处理后的图、检测框、识别结果、最终 docx 各存一份。这份"基线样本"在你后面调参数时会非常有用。

1.3 免费与离线这两件事到底值多少

标题里带了"免费"，但我想说的不只是钱的问题。免费和离线这两个属性，在文档数字化这个场景里的实际价值比想象中大。

先说离线。纸质资料里有一部分是不适合上传的——内部流程文件、个人信息表、还没公开的方案稿。在线识别服务再方便，这些内容你也不太愿意往外传。本地运行意味着图片从头到尾没离开过你的硬盘，这个心理负担的消除是实打实的。另外离线还有个附带好处：没有网络延迟和调用频率限制，批量跑几百张图的时候，速度是稳定的，不会因为服务端排队忽快忽慢。

再说免费。开源工具的"免费"其实包含两层：一层是不用付费，另一层是可以改。我在处理一批老式票据的时候遇到一个问题，票面上的金额区域有一种特殊的水印底纹，识别出来总是串字符。在线服务没有任何办法，只能忍。本地工具我可以直接去改预处理那一段，针对这个区域加一个方向滤波，问题就解决了。这种"能钻进引擎内部动手"的自由度，是免费开源方案最被低估的部分。

当然代价也要说清楚：本地运行意味着模型文件要自己下、环境要自己配、显存内存要自己算，第一次跑通可能要花掉一两个小时。这笔时间投入值不值，取决于你的使用频次——一次性处理十张图，用什么都行；每周都要处理上百张，那这一两个小时是稳赚的。

2. 环境准备与安装：把工具跑起来之前的那些坑

2.1 硬件与系统要求，以及我的实测参考值

DocLens 这类工具对硬件的要求，主要卡在两个地方：内存和推理设备。CPU 能跑，但慢；有独立显卡会舒服很多，但不是必须。

下面这张表是我在自己几台机器上跑同一批测试样本（30 张 A4 大小、300 DPI 的扫描图）得到的粗略量级，仅作参考，具体数字会随图片复杂度浮动：

从表里能看出一个很实用的结论：如果你只是偶尔处理几十张图，纯 CPU 完全够用，没必要为了这个去折腾显卡环境。反过来，如果你要做几百上千页的批量数字化，那么一张入门级独显带来的提速是数量级的，值得。

系统层面的要求不高，主流桌面系统都能跑，需要注意的是 Python 版本。我建议锁在 3.9 到 3.11 这个区间，太新的版本有时候轮子还没跟上，装依赖会卡在编译环节。

注意：显存不够的时候，现象不是报错，而是程序在跑到某一页时直接退出，日志里可能只有一句很含糊的提示。如果你遇到这种情况，先把批量大小调成 1 再试，多数时候就好了。

2.2 三种安装方式的对比与我的选择建议

安装方式大致有三种，我按推荐度排序说。

第一种，源码安装加虚拟环境。这是最推荐的，也是我一直在用的方式。流程是：先建一个独立的虚拟环境，再克隆代码，然后装依赖，最后单独下载模型文件。好处是环境干净、出了问题好回滚、想改代码随时改。缺点是步骤多一点。用 conda 管理的典型命令长这样：

conda create -n doclens python=3.10 -y conda activate doclens

建好环境之后进入项目目录安装依赖：

cd doclens pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

这里有个我踩过的坑：依赖里如果同时有 CPU 版和 GPU 版的推理框架，直接装很容易装错。稳妥的做法是先看清楚 requirements 里的分组，只想跑 CPU 的话，把带 GPU 字样的那一组手动跳过。

第二种，打包好的可执行程序。适合完全不想碰命令行的用户，双击就能用。缺点也很明显：模型和代码都被封在里面，想改参数、换模型、加预处理逻辑，基本没有空间。而且这类打包程序通常会内置一个通用版的识别模型，对特定领域的文档（比如竖排古籍、手写表格）效果不一定好。

第三种，容器化部署。适合需要在多台机器上统一环境的场景，比如一个小团队一起做档案整理。学习成本最高，但可复现性最好。个人用户一般用不上。

我给的判断标准很简单：只要你打算用超过一个月，就走第一种。前期多花的二十分钟，后面随便改个参数就赚回来了。

2.3 模型文件与语言包的准备细节

模型文件是新手最容易卡住的地方，因为它不在代码仓库里，需要单独下载。通常包括三个：文本检测模型、文本识别模型、方向分类模型。有些版本还会额外带一个版面分析模型和一个表格结构识别模型。

下载的时候有几个细节值得留意。一个是模型版本要和代码版本对得上。我见过有人拿旧版代码配新版模型，跑起来不报错，但识别结果乱七八糟，查了半天才发现是版本错配。另一个是语言包要按需选。中文场景下一般用中文加英文的混合识别模型，如果你要处理日文或韩文的资料，得换对应的模型，别指望一个通用模型全搞定。

放模型的时候建议保持默认的目录结构，不要随手扔到一个自定义路径——配置文件里写的是相对路径，路径一乱就得改配置，改配置又可能引入新的拼写错误。如果你确实想把模型放在别处（比如模型很大，想放在大容量盘上），那就去配置里统一改一个模型根目录的变量，别一个个改。

文件完整性也要验一下。模型文件动辄几十上百兆，下载中断是常事，中断之后的文件有时候还能被加载，但推理结果会莫名其妙地差。稳妥的办法是对一下官方给的校验值，或者至少看一眼文件大小和标注的是否一致。

3. 核心细节拆解：图像预处理与版面分析到底做了什么

3.1 图像预处理：让识别模型"看得清"的六个动作

预处理这一段是整条流水线里投入产出比最高的部分，我甚至觉得它比换模型更能提升效果。DocLens 的预处理大致分六步，顺序很重要，我把每一步的意图和注意事项都说一下。

第一步，方向判断与摆正。手机拍的照片经常带 90 度或 180 度的旋转，横拍竖排的内容尤其容易出问题。这一步会先跑一个轻量的方向分类，判断当前图像需要转多少度。为什么要放在最前面？因为后面所有的处理都对方向敏感，方向不对，透视矫正会算错，版面分析也会把页眉当成侧边栏。

第二步，纸张边界检测与裁剪。检测页面的四个角点，做透视变换把它拉成规整的矩形。这一步的价值在于消除拍摄角度带来的梯形畸变。文字行在畸变状态下会呈现倾斜或弯曲，检测网络对这种形态的容忍度有限。这里要注意，角点检测在背景和纸张颜色接近的时候容易失败，比如白纸放在白色桌面上拍。遇到这种情况，手动在纯色背景上重拍一张，比调参数省事得多。

第三步，阴影与光照不均的消除。做法通常是估计一个背景光照分布，然后用原图去除它。翻拍的书籍中间装订处的那条暗带、靠近窗户一侧的亮斑，都是靠这一步压平的。这一步做得太猛会有副作用：文字笔画变细，浅色的细体字可能直接消失。所以参数上我一般保守一点。

第四步，去噪。主要是针对高 ISO 拍摄产生的颗粒噪点和扫描件的灰尘点。中度滤波就够了，别上太强的，否则会把标点符号这种小目标一起抹掉。

第五步，对比度拉伸与锐化。用直方图拉伸把灰蒙蒙的扫描件提亮，再用非锐化掩模提升笔画边缘的锐度。锐化的量要克制，过度锐化会在笔画边缘制造白边，反而干扰识别。

第六步，尺寸归一化。把图像的长边缩放到一个固定范围（常见是 960 到 1920 之间），保证同一批图的推理速度稳定。这里有个原则：缩放前先处理，不要先缩放再处理。因为多次插值会让图像越来越糊，先做锐化和去噪，最后只做一次缩放，画质损失最小。

还有一件事要特别提醒：不要随便对整页做二值化。老式的 OCR 流程习惯先二值化再识别，但基于深度学习的检测模型是在彩色或灰度图上训练的，你硬塞一张黑白图给它，效果往往更差。只有在处理传真件、复印件这种本身就接近二值的素材时，才考虑做局部自适应二值化。

3.2 版面分析：识别率高但排版乱，根子在这里

很多人反馈"字都认出来了，但顺序全乱了"，问题几乎都出在版面分析这一层。

版面分析的核心任务是给页面上的文字分配阅读顺序。对于单栏、规整的页面，从上到下、从左到右排就行，没什么难度。麻烦在于三种情况。

第一种是多栏排版。学术论文、报纸、宣传册都是双栏或三栏。如果简单地按行切分，就会出现第一栏第一行接第二栏第一行、再接第一栏第二行这种"横跳"现象，读起来莫名其妙。正确做法是先按横坐标把文字块聚成若干栏，再在每一栏内部按纵坐标排序。DocLens 在这一步用的是投影加聚类的方法：统计文字块在水平方向的分布，找到那些纵向空白带，用空白带把页面切开。

第二种是图文混排。一张插图占据页面右侧三分之一，左侧是正文。如果不管图片，正文的阅读顺序是对的；但如果图片里有文字（比如流程图里的标签），这些文字会被强行插进正文中间。解决办法是给图片块打上类型标签，默认不参与正文排序，需要的话单独导出。

第三种是跨栏元素。通栏的标题、跨两栏的大表格、页脚的注释，它们的宽度超过了单栏，排序时会被切碎。处理方式是先识别出这些"宽度异常"的块，把它们单独拎出来作为分隔点，先把页面切成上下几个区段，再在每个区段内做分栏排序。

3.3 表格与多栏排版的还原原理

表格还原是这类工具里技术含量最高的部分，也是我评判一个工具好不好用的第一标准。

有框线的表格相对好处理：先检测出横线和竖线，求交点，得到单元格的网格，再把每个格子里的文字填进去。难点在于合并单元格——有些横线画到一半就停了，需要根据线段的断点来推断哪几个格子属于同一个单元格。这里的判断逻辑通常是：如果某条竖线在某个区间内缺失，那么这个区间内的相邻单元格就合并。

无框线的表格才是真正的硬骨头。没有线条，只能靠文字的位置关系来推断：同一行的文字纵坐标接近，同一列的文字横坐标对齐。做法是先对所有文字框做纵向聚类得到行，再在每一行内部做横向聚类得到列，最后把各行的列位置做个对齐修正。这套方法在列数固定、内容规整的表格上效果不错，遇到列宽差异极大或者单元格内换行的表格，就容易把一行拆成两行或者把两列并成一列。

我处理过一批老式报价单，表格没有框线，而且某一列经常是空白（没有报价的项目）。这种情况下聚类会失败，因为空列的位置信息完全丢失。我的处理办法是在预处理阶段手动指定一个列位置模板，告诉程序"这个表格固定有 5 列，列边界大致在这些 x 坐标上"，然后让程序按模板切格子。这算是半自动方案，但对于固定格式的表单来说，一次配置可以复用很久，非常划算。

表格识别完之后，结构通常先被表示成一种中间格式，再转换到 Word 的表格对象。这一步要注意列宽映射：Word 表格的列宽如果直接等分，看起来会很别扭，最好按照原始图像里各列的实际像素宽度按比例分配。

3.4 识别引擎的关键参数与调参参考

识别层有几个参数会显著影响结果，我把常用的几个整理出来，附上我自己的取值习惯。

这几个参数之间存在耦合，不要一次全动。我的调参方法是：拿五张有代表性的图做固定测试集，先在默认参数下跑一遍，记下每张图错在哪儿；然后只调一个参数，再跑一遍，看这个错有没有变好、有没有引入新的错。一次只动一个变量，虽然慢，但能真正建立对参数的直觉。

框扩张系数这个参数最容易被忽略，但它的作用很实在。因为一些识别模型需要上下文的边距，框卡得太紧，首尾字符容易被裁掉一半，识别出来就是乱码。我遇到过一种情况：中文的"日"和"目"在高斯模糊之后，如果框卡得太紧，模型分不清，扩一下框就好了。

4. 完整实操流程：从一张照片到一个能改的 Word

4.1 单张图片的端到端实操

先把单张的流程走通，批量才有意义。我按实际操作顺序写。

第一步，准备一张测试图。建议选一张内容有代表性的：有标题、有正文、有至少一个表格、字迹清晰、没有严重倾斜。别拿一张纯文字截图测试，那种图什么工具都能过，测不出问题。

第二步，把图片放进输入目录，运行单图模式。命令行大致是这样：

python scan.py \ --input ./samples/page01.jpg \ --output ./out \ --backend accurate \ --lang ch \ --export docx \ --dump-intermediate

这里的--dump-intermediate是我强烈建议加上的，它会把预处理后的图、检测框可视化图、识别文本一起存下来，方便对照。

第三步，看输出。先看预处理那张图有没有问题——纸张是不是正的、阴影有没有去掉、边缘有没有被裁掉内容。这一步不对，后面全是白搭。再看检测框的可视化图，重点看三处：框有没有漏掉某一行、有没有把两行框成一个、框有没有把字符切边。

第四步，看 docx。按重要性依次检查：阅读顺序对不对、段落有没有被切碎、标题层级有没有识别出来、表格行列对不对。发现问题就回到对应层去调，别在黑盒状态下瞎猜。

第五步，校对。打开导出的文档，从头读一遍。这里我有个习惯：边读边把不确定的地方在原文上标出来，读完一轮再统一回去核对原图。比一个字一个字盯着看效率高得多。

4.2 批量处理与目录结构组织

批量处理的价值不在于省点击，而在于一致性。同一批图用同一套参数处理，结果风格统一，后面的校对和归档都省心。

目录结构我建议这样组织：

project/ input/ 2024-batch-01/ page-001.jpg page-002.jpg output/ 2024-batch-01/ page-001.docx page-001.txt page-001.json fails/

fails目录很重要。批量跑的时候总有几张会失败——图片损坏、分辨率太低、全空白。程序应该跳过失败的继续跑，把失败文件名记下来，而不是整批中断。等你回头处理这几张特殊样本，效率高很多。

批量命令大概长这样：

python batch_scan.py \ --input-dir ./input/2024-batch-01 \ --output-dir ./output/2024-batch-01 \ --backend light \ --batch-size 1 \ --resume

--resume（断点续跑）这个选项很关键。处理几百张图的时候，中途因为内存问题或者误操作中断是常有的事，没有断点续跑就只能从头再来。它的实现逻辑很简单：扫描输出目录，跳过已经存在同名结果的输入文件。你自己写脚本的话，也一定要加上这个逻辑。

--batch-size我一般设成 1。设大了虽然吞吐量可能高一点，但一旦某张图特别大导致显存爆掉，整批就挂了。稳字优先。

4.3 导出 Word 的参数与样式模板

导出这一步决定了最终文档"好不好用"。DocLens 的导出模块通常提供几个可调项，我挑最重要的三个说。

第一个是字号推断。程序会统计页面上所有文字块的字高分布，把明显偏大的那些判为标题。这里有个常见问题：扫描件里字号是像素高度，换算成磅值需要一个基准。如果换算基准没设对，导出来的文档会出现"标题只有 10 磅、正文却有 14 磅"这种奇葩结果。解决办法是给一个明确的正文字号基准（比如正文统一 10.5 磅，也就是五号），然后按像素高度比例换算其余部分。

第二个是样式映射。默认导出通常是直接写死的格式，改起来麻烦。更好的做法是基于模板导出：准备一个 .docx 模板文件，里面预先定义好"标题 1""标题 2""正文""表格文字"这些样式，导出时按样式名套用。这样你想统一改字体、改行距、改段前段后，只需要改模板，不用碰代码。我在做正式文档的时候都是走这条路，改一次模板，几百份文档的样式统一就搞定了。

第三个是分页控制。这里指的是原始图片里如果某一页内容结束了，导出时要不要插入分页符。对于一本书、一份多页合同的场景，答案是要；对于一堆零散的单页资料拼在一起，答案通常是不要。这个选项一般叫"保留原分页"之类的名字，记得手动设一下。

还有一个细节值得单独提：中文全角标点和英文标点的处理。识别模型有时候会把中文的逗号识别成英文逗号，导出的文档里就会出现"今天，天气很好"这种混排。这个可以在后处理阶段做规则替换：在中文语境下把英文标点统一替换成全角。但要注意别把数字里的点（比如 3.14）和网址里的点替换掉，替换规则要写得细一点。

4.4 校对与后处理：把 95% 提到 99%

前面所有环节做得再好，最后总会有错字。这一节讲的是怎么把校对成本压到最低。

低置信度标记是最有效的手段。识别结果的中间格式里通常带每个文字块的置信度，把低于阈值的块在 Word 里标成黄色底纹，你的眼睛就自动被引导到需要看的地方，不用逐字扫。我实测过，一份一万字的文档，全部标黄的位置大概占 3% 到 5%，校对时间能压缩到原来的三分之一。

规则化纠错可以消灭一批高频错误。我总结的常见模式有几类：

表格人工复核这一步没法完全省。表格里一个数字错了，影响比正文错十个字还严重。我的做法是导出时把表格单独抽成一份清单，对着原图逐个核对关键列（金额、数量、日期这类），其余列抽检。

还有一点经验：后处理规则不要一口气加太多。每加一条规则，都可能引入新的误伤。我建议的节奏是处理完一批文档之后，把校对中遇到的错误分类统计一下，哪一类出现三次以上，才写一条规则去治它。规则库是靠项目喂出来的，不是一开始就能设计全的。

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

5.1 识别率相关问题的快速排查表

遇到效果不好，先别急着换模型，按这张表往下排，八成的问题在前三行就能定位。

5.2 排版错乱的典型成因与修复顺序

排版问题比识别问题更让人抓狂，因为字都是对的，但拼不成一句话。我按修复的优先级排个序。

第一优先修阅读顺序。顺序错了，后面的一切都没有意义。判断方法很简单：通读导出的文档前两段，如果读不通，先去调版面分析。多栏文档是最常见的重灾区，处理方式在 3.2 节讲过，核心是先把页面按纵向空白带切成段，再在段内分栏。

第二优先修段落切分。段落被切得太碎，主要表现为每一行都变成一个独立段落。这通常是因为段落合并的阈值设得太保守——程序判断两行属于同一段的依据是行距和缩进，如果行距估计有偏差，就合不上。可以适当放宽行距阈值，或者加一条规则：上一行结尾不是句末标点，且下一行开头不是特殊符号，就合并。

第三优先修标题层级。标题识别靠字号聚类，如果一份文档里字号种类太多（比如有五种不同大小），聚类就会碎掉。实用做法是限制层级数量，最多识别三级，剩下的统一当正文。层级少一点，反而更准。

第四优先修表格。表格修复成本最高，所以放最后。如果只是个别格子错位，手工改比调参数快；如果是整张表结构崩了，那就去调表格识别模块的参数，或者退回用人工模板的方式。

5.3 性能与资源问题的处理思路

跑批量的时候常见的资源问题有三种。

内存缓慢增长直到崩溃。典型表现是前五十张正常，第六十张突然退出。原因是每一页的处理结果没有及时释放。解决办法是把批量大小设成 1，并且确认程序在每个文件处理完之后做了资源回收。如果你自己在改代码，检查一下有没有把大对象挂在全局变量上。

显存不足。表现是跑到某一张时直接报错退出，而那张图往往特别大。处理方式有两种：一是限制输入图像的长边像素，把超大图先缩下来；二是对超大图做分块处理。我一般选第一种，因为大幅缩图对识别率的影响远小于很多人想象。

批量速度越跑越慢。这种情况多半是输出目录里文件太多，每次写文件都要扫一遍目录。解决办法是按批次拆分输出目录，比如每 200 个文件一个子目录。

5.4 我在实际使用中踩过的几个坑

第一个坑：拿截图当扫描件用。我一开始图省事，直接对屏幕截图做识别，结果表格识别得一塌糊涂。后来才想明白，屏幕截图的像素密度和扫描件完全不同，字号基准换算全乱了。不同来源的图片不要混在同一批里处理，这是我现在的基本原则。

第二个坑：模型下载不完整。有一次模型下载中断，文件大小只有应有的一半，但程序照样加载成功，识别结果差得离谱。我花了两个小时怀疑参数，最后才发现是文件问题。现在我的习惯是下载完立刻对一下大小，有校验值就对校验值。

第三个坑：批量跑之前没做小样本验证。有次我改了个参数，觉得改动很小，直接扔了三百张进去跑。跑完发现新参数在某一类图上翻车，三百张全部要重跑。改参数先跑五张，这是铁律。

第四个坑：过度依赖自动预处理。有些图片自动预处理反而帮倒忙，比如本身就很干净的高质量扫描件，被自动去阴影和锐化之后画质变差了。后来我加了一个开关：图像质量评估达标就跳过预处理。这个判断不难做，看一下对比度和噪点水平就行。

第五个坑：忘了保留中间结果。有一次导出文档发现串行，但中间结果已经清掉了，只能重跑一遍才能定位。从那以后我默认打开中间结果输出，占点硬盘空间，换来的排查效率完全值得。

6. 影响范围与适用边界：什么该用，什么别硬上

6.1 最值得用的几类场景

纸质档案批量数字化是这个工具最对口的场景。格式规整、印刷体、需要保留版面结构，这三点正好都在它的能力范围内。我做过一批两百多页的旧资料，含目录、章节标题、若干表格，整批跑下来，校对时间主要花在表格数字上，正文部分基本可以直接用。

合同与表单归档是第二个高频场景。这类文档的特点是格式固定、重复度高，非常适合建模板。一次配好列位置和字段区域，后面几百份用同一套配置跑，准确率会随着模板优化越来越高。

课堂笔记与讲义整理也很合适。手写部分确实吃力，但印刷体的讲义、复印的资料效果很好，尤其是带公式和图示的那种，版面还原之后可读性比纯文本强太多。

外文资料的初步翻译底稿也值得一提。先用它把外文资料转成可编辑文本，丢进翻译工具，比对着 PDF 一句句看效率高得多。当然这类用途对准确率的要求可以放宽，反正是要再加工的。

6.2 不建议硬上的场景

手写体为主的内容。现有的通用识别模型对手写的支持普遍一般，连笔、个性化笔迹的错误率会高到无法接受。除非你能拿到针对特定笔迹微调过的模型，否则不如老老实实人工录入。

艺术字与复杂排版的设计稿。海报、宣传页那种字体五花八门、文字沿着曲线排布的设计稿，版面分析会彻底懵掉。这类内容本来也不需要转成 Word。

低质量的老照片翻拍件。泛黄、有折痕、字迹模糊的老照片，预处理能救回来一部分，但救不回来的部分会变成大量错字，校对的痛苦程度超过重新录入。判断标准很简单：如果你自己看着那张图都要眯眼猜字，别指望模型能认对。

需要像素级精确定位的场景，比如要把识别结果回填到原始表单的指定位置。这类需求对坐标精度的要求远超一般 OCR，通用工具给不了这个精度，得走定制方案。

6.3 本地工具和在线服务怎么选

这不是非此即彼的问题，我自己是混着用的。

本地工具的优势在于隐私可控、批量稳定、可以改，适合长期、大量、有敏感性的资料。在线服务的优势在于开箱即用、对新场景的泛化能力通常更强（因为背后模型更大、训练数据更多），适合零星的、格式千奇百怪的临时需求。

我的实际分工是这样：日常的批量归档全走本地；遇到一两张特别难搞的图（比如少见的字体、奇怪的版式），先扔给在线服务试试，如果在线也搞不定，说明这图本身有问题，回去重拍或者放弃自动识别。这个分工跑了很久，效率比较稳。

还有个中间选项值得提一下：把在线服务当成基准线。调本地参数的时候，拿同一张图分别跑本地和在线，对比结果差异，能帮你快速判断自己的参数是不是调歪了。这个用法我常用，比对着原图一个一个字看要快。

最后说个扩展思路：这套流水线的中间产物（检测框、识别文本、置信度）其实很有价值，不只是用来生成 Word。我后来基于这些中间结果做了个简单的全文检索库，把几百份扫描资料的关键字段抽出来建了索引，找东西的时候直接搜，比翻 Word 文档快得多。工具本身是终点，但它吐出来的数据可以是另一个起点。

我在实际使用中最大的体会是：这类工具的价值不在于"完全替代人工"，而在于"把人工用在刀刃上"。它负责把 95% 的机械劳动干掉，你只需要处理剩下那 5% 需要判断的地方。想明白这个定位，参数怎么调、流程怎么设计，思路就都清楚了。