ARTICLE · 1188818
AI项目复盘07|勘察助手OCR识别从提报到交付的三个月全生命周期记录
在《FDE最怕的不是技术问题，而是理不清楚的企业需求》里，我把公司内部23个项目需求盘了一遍，但大多只归了个类，一句话就带过了。
回看这篇文章，这些项目经验写这么薄，有点可惜。因为成了的没说清为什么成，黄了的也没说清哪里踩了坑。于是寻思着一定要把典型案例拎出来，摊开来盘一盘。
接下来请出今天的主角，勘察助手OCR识别（正式交付时叫勘察助手OCR+大模型识别系统）。这个需求是交付部提的，目标是让外业勘察员拿手机拍一张纸质记录表，自动生成结构化数据，替掉“白天在马路边手写填表、晚上回驻地熬夜敲Excel”的苦差事。
它2026年3月18日提报需求，6月24日完成培训交付，前后历时约三个月，项目按计划顺利交付，目前还在持续迭代。
一、一句话结论
勘察助手OCR识别能顺利落地，靠的是从立项第一天就定死“识别为主、人工校正为辅，但最终决策以人工为准”，并把这条人机边界做进了产品的每个环节里。
二、需求刚提上来，先把不该机器干的活划掉
以前一线勘察员去现场跑项目，白天顶着大太阳在马路边数灯杆、量道路断面，手写填完一张30多个字段的纸质记录表。到了晚上再将纸质的记录表数据录入EXCEL表内，录入工作非常耗时，手写的数字“1”和“6”一连笔，看走眼还会录错信息。
3月18日，业务方正式提报了“勘察记录汇总和照度模拟”的建设需求，期望把现场数据采集和后续的照度计算一并交给系统。
我们接手梳理时发现，前半截外业填表录入这件苦差事每天都在发生，照着纸质的《道路勘察记录表》和《道路照度检测记录表》把数据搬进系统，输入输出干净利落，正好是机器擅长的体力活；
但原需求把“照度模拟”相关场景绑在了一块，这个场景涉及非常复杂的计算以及第三方工具，还得靠专业人员权衡工程方案拍板，必须先做一轮范围裁剪。
顺着这个判断，我们在立项时直接动刀划清了边界。
一方面把后半截“照度模拟”相关场景砍掉，只做那两张纸质记录表的识别汇总；
另一方面把小程序里原本规划的五个勘察模块（道路路灯、变压器、配电箱、线箱、机房）砍到只开放第一个“道路路灯”，剩下四个全置灰标上“后续版本”再进行。
人和机器各干哪一半，在立项那天就已经定死了。
三、需求调研分流规矩
5月项目进入需求调研与方案设计阶段。
我们先把两张纸质表单的字段拆细，梳理出《道路勘察记录表》需提取的25个字段和《道路照度检测记录表》需提取的3个字段。
按最初梳理的单条操作流程，勘察员每次拍一张表，系统识别后回填到当前表单页，人在页面上逐项核对完，直接点【提交】就能进正式列表；要是现场还有缺项没填完，也可以点【提交为草稿】暂存起来。
到了5月21日开需求确认会，9个人坐在一起碰细节，这条刚划好的线迎来了最险的一次拉扯。
业务方提出来，外业出去一趟跑十几二十条路是常事，大热天站在马路边一张张传、一条条等太熬人了，要求放开批量上传，一次选几十张照片直接生成多条记录。
我们在会上当场摆出了风险，“批量识别会打断单条校验流程，可能导致用户跳过校验，数据质量不可控。”
手写字识别做不到百分之百准，单张识别时人就停在表单页上看着，可以直接改完提交；
可一旦放开批量上传，几张表同时在后台跑，如果直接塞进正式列表，大家图省事肯定顺手跳过核对，错漏数据混进台账就没法收拾了。
硬拦着不给批量，一线觉得难用；直接放开入库，数据质量肯定垮。
最终会上双方达成一致，批量功能可以做，但必须加上状态管控。
会后往深里做交互设计时，我们觉得最初设想的“待校验”小红点不够直观，为了让大伙用起来更清晰明了，干脆把列表劈成“勘查记录”和独立的“草稿箱”两栏，对单张和批量做分流管控。
单张识别时，勘察员在当前页核对无误后依然可以直接点【提交】进正式列表；
批量导入单次最多传10张（单张原图大概4MB，放后台异步跑，只对《道路勘察记录表》开放），识别生成的数据一律默认提交至草稿箱，必须由人去草稿箱里逐条点开核对确认后，才能点【提交】转进正式列表。
同一场需求确认会上，围绕怎么让数据好用又不乱，还敲定了另外两项后台规则。
一是原图归档，会上有人提醒，“图片量大时直接嵌入会导致导出速度极慢，且缩略图可能看不清。”
我们当场放弃了往Excel里塞缩略图的做法，改成导出汇总表时单独打包一份原图压缩包，并在PC后台配套设计了异步处理的下载中心，点完导出不用干等。
二是PC端不开放数据修改，“多端入口易导致数据混乱，导出后直接在源头修改更合理。”
四、用大模型做语义校对，把单张识别压到20秒跑通验收目标
进入研发实现阶段后，我们还得想办法让勘察员核对时少改几个字。
立项时PRD定下的目标是把原本一条要敲10到15分钟的记录压到3分钟内搞定，单张表识别控制在1分钟内，人工核对后的整体准确率要达到99%以上。
预演方案时，我们先靠传统OCR按固定规则去对字段。结果把一线收回来的真实手写样张往里一跑，问题全暴露出来了。
外业人员在路边垫着板夹写字，字迹连笔、勾选项打勾画偏、数字和单位混着写是家常便饭，死板的规则经常对不齐，认出来的词填错格，用户点开还得大改一通。
为了让回填结果更准、一线用着更顺手，我们把底层方案换成了双引擎，“先由OCR引擎识别图片中的文字信息，再交由大语言模型进行语义理解与结构化解析。”
大模型接管了语义校验、字段匹配、格式标准化、单位换算和数据纠偏后，最终验收实测的数据很争气。
单张手写表单的识别耗时压到了20秒左右，比原定1分钟的目标快了一大截；AI自身的识别率达到了约90%，勘察员在这个底子上做人工审核与微调，单条记录从拍照到改完提交完全能控制在3分钟以内，人工核对后的整体准确率也稳稳实现了99%的目标。
机器在校对这步往前多跨了一大步，把脏活累活揽了过去，但“最终由人确认”这条规矩一寸没挪。
五、培训加移交，交付远不止往群里发份手册
平时很多内部工具上线，群里丢一份操作手册就算交差了。但带AI能力的工具不能这么干，用户要是摸不清它的脾气，要么盲目全信把错数据传上去，要么碰上一两次识别不准就直接弃用。
6月23日我们组织了一场45人的线上加线下的业务培训，把交付、研发、技术方案和各个业务大区共7个部门的人都邀请过来。
我们在培训过程中把系统的家底和限制全摊开讲了，明确区分了“AI识别率约90%”与“人工核对后整体准确率99%”的概念，连后台防刷量的限流规矩（按每天300张的日常基准留了2到3倍余量，设了全平台每天1000次、单任务100次、单IP200次、瞬时并发不超过10次四道防线，足够撑起全年预估6000张、实际2万张以上的识别量）也一五一十交了底。
培训一结束，我们把操作手册、课件、10道随堂测试题、成绩单、签到表和效果反馈表全套整理成册，移交人力资源部和业务部门留档。
完成业务培训和组织过程资产移交后，当天正式签下了项目的《需求验收单》。
六、上线后持续迭代，机器越兜底人越不能省掉审核
系统上线交付后，不意味着项目已经结束了。
根据一线的实际使用需求，我们又顺着业务场景做了两项功能迭代。
第一项调整是按时间范围导出。原来PC后台只能把整个勘察任务的数据一把全导出来，可现场一个大项目往往要连着跑好几天，管理人员每天只想把当天新跑出来的记录拉出来复核。
我们在导出弹窗里加了日期区间筛选，默认带出任务的计划起止时间，并在下载中心补了任务详情查看功能。
第二项调整是给“记录人员”这个字段做相似度匹配映射，由机器协助用户完成姓名匹配，解决手写姓名识别错误的自动纠正问题。
中文名字笔画多，现场手写一连笔，又没有上下文可循，是识别最容易翻车的重灾区。
为了作为工程减负手段帮一线少改两笔，我们把常用的45个人员姓名（12个两字名、33个三字名）建进维护名单，让系统把OCR认出来的名字按字符串相似度往名单上匹配，默认阈值定在0.65。
因为我们预留的这份姓名清单里，基本没有超过两个字重合的情况，所以只要三字姓名对上两个字、算出来的相似度超过0.6667，系统就会自动纠正成“许海强”这样的清单标准姓名。
比如纸表上把“许海强”手写连笔认成了“许海墙”，相似度是0.6667，系统会自动帮用户改成正确的“许海强”；而碰到“许三多”这种相似度只有0.4、没过线的，则会原样保留识别文本（两字姓名额外要求姓氏必须完全匹配）。
不过我们也专门提醒一线，注意不要因为机器存在一定的兜底机制就忽视了人审核的重要性，提交前依然得由人把好最后一道关。
七、写在最后
系统最终能跑出单张识别20秒、3分钟内完成单条录入、整体准确率99%的验收效果，核心在于认清了“AI识别率约90%，而99%的整体准确率必须靠人核对之后才能达到”。围绕这个前提，我们把能力边界同时塞进了三个地方。
① 文档里写清，在操作手册里把字段映射表、限流规则和常见问题逐条列明。
② 培训里讲透，当面给一线交底“识别准确率约90%，但字迹潦草等情况下可能出错，需人工重点核对道路编号、人名”。
③ 系统里做进去，用批量默认进草稿箱、覆盖提醒、删除二次确认和超限提示把风险拦在前面。
下次再接识别分析类没法做到百分百准确的AI需求场景，动手前先别急着卷识别率，先把“机器干到哪一步停手、人在哪一步接管”的边界设计进流程里，比单纯调模型管用得多。
不管底层的模型和匹配规则往前帮着多走了几步，把人工核对留在最后一步，才能把业务数据质量的底兜住。
