既然手工录入太慢，我就写了个 OCR 识别录入系统（GPT-4 增强版）。但今天这玩意儿差点废了，因为整个四川工业用电全面关停。我坐在家里，笔记本电池撑死两小时，台式机就是个摆设。供电通知说晚上十一点到凌晨五点有电，我第一反应不是去给手机充电，是赶紧把脚本部署到那台破 VPS 上，让它趁着有网有电把今天的单据跑完。
VPS 在杭州，电是足的，但我本地的开发环境全瘫了。之前为了省事，所有图像预处理和 GPT-4 的 API 调用测试都在本地，现在连个像样的 IDE 都打不开。只能用笔记本残电，SSH 连上去，vim 硬改代码。妈的，一个缩进错误调试了半小时，眼睛都快瞎了。这种时候才觉得，什么优雅的架构都是狗屁，能跑起来就是胜利。
这个系统的核心痛点根本不是 OCR 识别率——用 PaddleOCR 加自己标注的几百张票据数据，准确率早就到 98% 了。真正的魔鬼在结构化。一张餐饮发票，你要把金额、日期、税号、商品明细（特别是那种“餐费”、“招待费”的模糊分类）全抠出来，还要跟公司内部的审批科目做映射。之前用规则引擎，写了一堆 if-else 和正则表达式，维护起来像在屎山里雕花。上个月咬牙上了 GPT-4 的 API，让它做理解后结构化输出 JSON，效果是飞跃，但成本也吓人。一张图平均要消耗 1500 tokens，算下来录入一张票的成本从几分钱变成了两三毛。老板问我“能不能再优化一下”，我心想优化个屁，这钱花在免去一个全职录入员上，已经是血赚了。
但电一停，所有这些精密的算计都显得无比脆弱。API 调用有频率限制，我的脚本里设置了退避重试，但如果 VPS 本身因为网络波动连不上 OpenAI，或者账单欠费（这次停电搞得我连信用卡还款都差点忘了），整个流程就卡死。更讽刺的是，我为了提升效率做的自动化，现在完全依赖外部电网和互联网这两个最不稳定的“基础设施”。你控制不了服务器机房，控制不了骨干网路由，甚至控制不了家门口那个变电站什么时候跳闸。
晚上十一点，电终于来了。像打仗一样，先把所有设备插上充电，然后启动台式机，监控脚本日志。看到“Processing invoice_0842.jpg… Success”的字样一条条刷出来，才稍微松了口气。但我知道这口气松不了多久。我盯着手机里拍的、因为停电没能及时扫描的几十张纸质单据，开始认真想移动端离线方案。是不是得在手机上跑轻量化的模型？TensorFlow Lite 还是 ONNX Runtime？预处理能不能在端上完成？至少把图像识别和初步裁剪做了，生成一个待处理队列，等有网有电了再同步到云端调用 GPT-4 做深度解析。这又涉及到数据同步的冲突解决，想想就头大。
可这就是 2022 年的现实。你一边用着最前沿的 AI 接口，一边被最原始的物理限制作弄。所谓的“效率提升”，在宏观的波动面前，薄得像一张纸。我记录下这个想法，不是因为多有远见，纯粹是疼出来的教训。下次停电可能更久，我得让这套系统，至少能喘着气活下去。
