自动办公中AI批量处理PDF和图片，哪2个工具组合最稳定？

悄告诉你说实话,我一开始是个AI工具怀疑论者,啦。

去年双十一为了抢猫粮，搞了个自动比价的脚本，结果把某东的价格接口给调崩了，被封号三天，啦。

那之后就老实多了，但人嘛，总是不长记性。

上个月，我实在受不了了，因为我家那个做财务的老婆，天天晚，上抱着笔记本手工核对供应商发票，那PDF加起来差不多四五百份，光看就头大。

她抱怨多了，我寻思着，咱也是搞自动化的，这面子挂不住，得整点真东西出来。

我的需求特简单，但特刁钻。

老婆那堆PDF，有三种来源，一种是扫描的A4合同，歪歪扭扭；一，种是电子发票，带二维码；还有一种是最恶心的，银行回单截图，和PDF混在一个压缩包里。

图片方面就更杂了，有手机拍的、有微信下载的、还有是PDF导出成图片的。

要把这些玩意儿统一转成excel或者可编辑的word，再按日期和金额归好类。

我用的这套组合，核心就俩：Lightning AI的文档解析API + 本地跑的一个老版本的PaddleOCR。

别问为啥不直接用付费的，问就是穷，还有前年双十一买的某云服务器还在吃灰，不跑点东西亏得慌。

先说这第一个坑。

我一开始图省事，拿所有PDF直接丢给Lightning的在线接口，那个每月免费额度大概百来页吧，我老婆那点量，一天就干穿了。

而且那接口对纯图片扫描件处理还行，但遇到那种带密码的、或者本身是浏览器打印出来的HTML转PDF，识别出来的文字顺序是乱的，排版比我初中写的作文还离谱。

特别是那种带页眉页脚和表格框的，它给全粘一起了。

后来我发现路子得反着走。

PDF不一定非得直接解析，得分流。

纯净的文字版PDF，比如电子发票生成的，直接调Lightning的文本提取接口就行，又快又准，基本没乱码。

但扫描版和图片，你再怎么让API硬扛，它也是用OCR引擎去猜。

这时候我就把扫描件和图片先统一扔给本地PaddleOCR，让它识别出带坐标的文本块。

然后我写了个小脚本，根据这些坐标判断那个是标题、哪个是表格线还是正文，再自己排个版。

这一下子，那错误率就从差不多五分之一降到了百分之五以内。

至于图片批量转PDF再处理这种骚操作，我也试过。

但我发现，直接把图片扔给PaddleOCR的检测框，比先合并成PDF再解析，要稳得多。

因为PDF转换过程中有压缩，有些细笔画的小字直接就断成雪花点了。

我们那个破扫描仪扫出来的图，本身就带个阴影，你再去压缩，那不是给识别添乱嘛。

第二步，就是我踩的那个最深的坑，差点把电脑搞死机。

当时为了图快，我给PaddleOCR开了四个线程，同时处理大概一千多张图。

好家伙，不到五分钟，内存占用直接干到86%，我电脑风扇声音大到像直升机起飞。

我老婆在旁边看电视剧都没听清台词，回头瞪我一眼。

后来我学乖了，把大图分批处理，每批一百来张，中间sleep个几分之一秒。

还特意写了段代码，如果内存占用超百分之七十，就暂停线程调度。

这玩意儿让我那个老破小的服务器反倒比新配的台式机跑得还稳当。

关于稳定性这词儿，我理解的跟别人可能不太一样。

最稳的组合不在于单个工具多牛，而在于你能不能让数据流错开。

纯文字版PDF走轻量API，图片和扫描件留在本地走重OCR。

这样即便某个晚上批量跑崩了，你损失的也就是那百来张图片的二次处理时间，而不是整个流程从零开始。

我老婆那倒霉单位，上周发来一批文件，文件名后缀是.PDF，结果打开全是.JPG的假PDF，就是用图片硬改扩展名的。

我那套分流逻辑完美避开了这个坑，因为我看的是文件头的magic number，不是后缀。

哦对，上周末我还抽空给家里那只傻猫做了个自动喂食器，用的树莓派加舵机，代码逻辑简单到爆，但犯了个低级错误——没给摄像头模块加散热片，玩了半小时，直接过热重启。

这玩意儿跟AI工具一样，环节越多，越容易在自己想不到的地方掉链子。

现在这套组合跑了大概一个星期了，每天稳定处理两三百个文件。

唯一的不太方便是老婆现在天天让我帮她同事也处理，说是要攒人情。

这我是真没想到，工具稳了，人反而累了。

算了，回头给她做个简易版网页传文件的界面，别再让我手动搬了，我腰不好。