蚂蚁集团要上市了，朋友圈里全是狂欢，好像每个人都分到了期权。我盯着电脑屏幕，右下角是团队这个月的工时统计表，密密麻麻的红线，交付进度又拖了。什么金融科技，什么流量终局，本质上不还是那套东西吗？把足够多的用户圈进来，用足够复杂的规则和足够深的入口，完成收割。我们做的那些小程序、H5活动页，逻辑上跟这个没区别，只是我们收割的是甲方的预算，他们收割的是更底层的东西。
今天为了赶一个银行客户的报告，又搞到凌晨。需求是要从他们给过来的几百份PDF合同里，把关键条款、金额、日期这些信息抓出来，做成结构化表格。甲方给的数据永远是一团乱麻，命名不规范，扫描件还有歪的。团队里的小孩一开始想上OCR然后调接口，被我按住了。预算就那么多，调用次数超了谁付钱？这种时候，就得用土办法，正则表达式加逻辑判断，硬啃。
我的框架其实很简单，但很有效。首先，用PyPDF2或者pdfplumber把文本抽出来，这一步就有坑，有些PDF是图片转的，底层根本没文字，那就得先走一遍OCR，但只对没文字的页处理，用pytesseract，控制成本。文本拿到手，才是重头戏。你不能指望一个正则打天下。我的做法是分层。第一层，先用一堆预定义的正则模式去套，比如找金额，`\d{1,3}(?:,\d{3})*(?:\.\d{2})?` 这种基础款要备着，但还要考虑“人民币壹佰万元整”这种大写，得另写规则转换。第二层，上下文关联。光找到一个日期没用，得知道它是什么日期。比如在“起息日”后面冒号附近找到的日期，和“到期日”后面的日期，要打上不同的标签。这里就用逻辑判断了，扫描抓取到的文本行，维护一个“上下文状态机”。比如，当检测到“利率”这个词时，就把状态标记为“利率条款”，接下来抓到的数字大概率就是利率值，直到遇到下一个章节标题为止。
第三层，也是最脏最累的，处理例外和噪音。合同里总有“详见附件一”、“如遇……则……”这种废话，还有页码、页眉。我的办法是建一个垃圾词库，匹配到就直接丢弃这一行。但有时候有用的信息就和垃圾混在一起，比如“年化利率（单利）为 4.5%”，括号就是噪音，但不能全删。这时候就用分组捕获，只提纯数字和核心名词。所有这些规则和逻辑，我都封装成一个配置文件，用YAML来写，这样下次遇到类似的合同，改改配置就能复用，而不是重写代码。
搞完这一套，看着程序自动吐出来的Excel表格，确实有快感。但下一秒就想到，这套东西能养活团队多久？蚂蚁用大数据和模型做风控，我们还在用正则和状态机抠字眼。效率上有云泥之别。但现状就是，很多传统企业的数字化就卡在这里，他们不需要，也养不起一个AI团队，他们要的就是把眼前这堆纸质文件电子化、结构化。我们吃的就是这口饭。AI？当然有用，但那是锦上添花，是有了清晰结构化数据之后的事情。在数据还是一团浆糊的时候，人的逻辑设计，那些`if-else`，那些对业务场景的理解，才是核心。团队里的小孩总觉得新技术炫酷，动不动就要“ALL IN AI”，我每次都得把他们拉回来：先把手动重复的活儿，用脚本自动化了，再谈智能。地基不打，楼盖不起来。
可话说回来，看着蚂蚁的估值，心里不酸是假的。我们吭哧吭哧地做数据民工，处理这些“非结构化”的脏数据，每一分钱都是人力堆出来的。而人家站在流量的顶端，用我们已经处理好的、或者说用户主动贡献的“结构化”行为数据，直接点石成金。这就是生态位的差距。也许有一天，AI真的能完全理解合同语义，自动抽取关联信息，那我这套框架就该进博物馆了。但在那之前，在2020年的秋天，在无数个需要交付的深夜里，它依然是我和团队吃饭的家伙。只是不知道，这把勺子，还能用几年。
