撕掉那张印错的体能测试成绩单时，我意识到这活儿不能再这么干了。手写单据录入，这破事从2016年做外包爬数据时就跟着我，十年了，还在用眼睛和Excel对账。只不过现在客户从电商流水换成了健身房的体测数据，错误率一点没少，还多了教练们龙飞凤舞的狂草。
这次我决定彻底解决。直接用大模型API做OCR？太天真了。试过，对规整打印体还行，碰到连笔、缩写、数字“7”和“1”傻傻分不清的时候，准确率直接掉到七成以下，后期人工核对的时间成本反而更高。这不行，我得搞个系统，不是单纯识别，是“理解”并“验证”。
第一步，拆解单据结构。一张体测表，无非是姓名、日期、身高、体重、体脂率、各部位围度。但难点在于格式不固定，有的表格印刷歪了，有的教练直接在空白处追加备注。我的办法是先让AI做全局扫描和区域分割，用YOLO这类目标检测框出每个填写区域，再把框内的图像切片单独送给视觉大模型做识别。这里有个关键：我不让它直接输出最终文本，而是要求它同时输出“识别文本”和“对该文本的置信度评分”，以及“该区域可能的数据类型”（比如，数字区间、日期格式、中文姓名）。
光这样还不够，错误照样会产生。于是“双向校验”上场了。正向校验，是基于规则的：识别出的“身高”数值是178，单位是cm，这合理；但如果识别出“身高”是2.1，单位也是cm，系统就会立刻标记为“高危异常”，触发复核。反向校验，是跨字段的逻辑关联：识别出的“体重”是85公斤，“体脂率”是8%。这时候系统内置的常识模型（我简单训练的一个线性回归参考模型）就会启动——一个体脂8%的男性，体重85公斤，其骨骼肌重量应该在一个大致范围，如果系统根据身高体重算出的BMI值极度异常（比如超过35），那么“体重”和“身高”两个字段至少有一个识别错了，甚至可能全错。系统不会自作主张改数据，而是会把这两个关联字段连同原始图像切片，打包成一个“矛盾组”，高亮推送到复核界面。
复核界面我也没做复杂，就是一个Web页面，左边是原始单据图，中间是AI识别并标记了疑点的结构化数据表格，疑点字段用黄色背景标出，“矛盾组”用红色边框圈在一起。右边是人工修正输入框。修正的动作本身，就是在给系统反馈。每次人工修正的结果，我都会匿名化后存到一个“纠错样本库”里，定期用这个库去微调那个视觉识别模型。让机器在错误中学习，这才是闭环。
技术栈说穿了不稀奇：FastAPI搭了个后端服务，前端用Vue简单糊了个界面，数据库用PostgreSQL，关键是把n8n的工作流用到了极致。整个流程是自动触发的：行政小妹用手机App扫描单据，图片上传到云存储，触发n8n工作流，调用我的AI服务接口，识别、校验、存入待复核数据库，同时给复核人员（就是我自己或者另一个教练）的企业微信发送一条待办通知。复核完成，数据才正式进入分析库。整个流程，人工介入只在最必要的“矛盾裁决”环节。
做这个不是为了炫技。2021年我回归个人，做健身教练时，大量时间被这种行政琐事吞噬，根本没精力研究真正的训练方案。现在用这套东西，我把原来每周要花五六个小时对账的时间，压缩到了不到一小时，主要是处理那些真正棘手的、字迹潦草到人眼都费劲的“矛盾组”。省下来的时间，我能多研究一篇运动生理学论文，或者给学员多做一个周期的个性化方案。
十年前，我焦虑的是流量和SEO，用爬虫疯狂抓取信息。现在，我焦虑的是如何从无效信息中解放自己。技术没变，还是处理数据，但内核变了。以前是向外掠夺数据，现在是向内管理熵增。AI不是来替代我思考的，是来替我扛下那些重复、低效、磨损心力的脏活累活的。把时间还给生活，这句话在2025年，对我而言不是一个口号，而是一行行能跑通的代码和一个确实减少了错误率的校验逻辑。
