从人工审材料到自动化办件：FDE用AI提升车管所网办效率

访谈资料整理：依据 Datawhale《FDE案例100》所收录访谈。案例叙述与成果均归属于原访谈，本站未进行独立项目审计。

原案例封面

为什么这个案例值得看？

车管所网办前台已经数字化，后台仍需人工逐张审核身份证、合同、营业执照和发票等图片。项目把机器视觉、OCR、大模型和 RPA 串成办件链路，单件全流程审核由约 15 分钟缩短到 3—5 分钟，日均办件量由约 700—800 件提高到约 1100 件。

这个案例的价值不只在于采用了某种模型，而在于把数据、规则、系统和人工责任连接成可执行的业务链路。落地过程围绕问题识别、方案选择、交付路径、业务结果和关键难点展开。

一、企业与业务场景

这个案例有一点特殊，一开始客户并没有提出一个“AI需求”。

FDE进入车管所，最早只是为了接一个系统运维项目。

当时原来的系统承建商已经倒闭，留下来的源代码并不完整，文档也缺失，而且整个系统涉及多种技术，有.NET客户端、安卓端显示程序，也有Web管理和调度系统。

很多公司评估以后都不愿意接，因为这不是找一个工程师简单维护一下就能解决的问题，需要真正把遗留系统扎进去看懂。

FDE把这个项目接了下来。

但现在从项目结果看，运维只是FDE进入业务现场的入口，真正有价值的需求，是进入现场以后才慢慢发现的。

在驻场过程中，FDE开始观察车管所的网办业务。

浙江的政务服务数字化程度已经比较高，很多事情群众在线上就可以办理，甚至一次都不用跑。

但FDE发现一个很有意思的问题，前台已经数字化了，后台却还有大量工作依赖人工。

群众在线提交业务后，会上传各种材料，比如身份证、营业执照、合同、发票等。

这些材料基本都是图片，而且拍摄质量五花八门。

工作人员要一张一张点开，再用肉眼判断材料对不对、信息是否完整，然后继续进行后续审核和录入。

这个流程一直这么运行，所以大家甚至已经习惯了。

但FDE在现场看下来，问题其实很明显，可以总结成三个特征，慢、累、量上不去。

第一是慢。

大量图片都需要人工打开、查看、核对，再把相关信息录入系统。

单件业务从头到尾审核下来，大概要15分钟。

第二是累。

这种工作谈不上复杂，只是高度重复。

工作人员每天长时间盯着屏幕看照片，有人直接反馈“眼睛都受不了”。

第三是业务量上不去。

车管所的网办业务背后还有一个比较特殊的业务关系。

部分服务由驻点快递企业参与，车管所完成审核和制证以后，由快递公司负责后续打包和寄递。

快递企业需要投入人员驻点，如果业务量不够、人工成本又高，这项服务本身就会面临经营压力。

所以这件事情表面上看，是“工作人员看图片太累”，但往后拆，其实牵扯的是整个业务链条。

审核效率决定办件能力，办件能力影响群众服务，也影响合作方的运营成本和整个服务模式能不能持续。

FDE在现场待得越久，越清楚一件事，FDE不能只等着客户把需求写成一句“业务人员要一个AI审核系统”再来做。

很多时候，真正的需求并不会自己跳出来。

FDE需要先进入现场，看业务是怎么跑的，看人在做什么，看哪个环节每天重复发生，再去判断这里有没有值得被AI重新改造的地方。

二、原有流程与核心问题

其实没有特别的解决方案，就是靠人。

群众把材料上传以后，工作人员打开图片，用肉眼审核，再人工处理后面的业务。

这个流程已经运行了很长时间，对车管所来说，它甚至不被认为是一个特别需要解决的问题。

这点项目实践表明很重要。

项目团队今天回头看，会觉得“这么明显的重复劳动，为什么不自动化？”但站在当时业务部门的角度，它是可以运行的。

人员在那里，流程已经形成，大家知道每天该怎么做，虽然慢一点、累一点，但没有影响到系统基本运转。

所以FDE第一次跟客户提出，可以用视觉技术替代一部分人工审核的时候，对方其实并没有马上接受。

他们的第一反应是，现在这样不也能干吗，为什么还要再花钱上一套新东西。

另外，他们对AI能不能真的达到业务要求也没有把握，哪怕市面上已经有一些现成能力，一方面价格不低，另一方面谁也不敢保证拿过来就能解决车管所真实场景里的问题。

所以从传统方式走向AI，原来的方式并没有突然失效。

真正的变化来自业务条件。

当时经济环境发生变化，驻点服务企业也开始面临经营压力，希望减少人员投入，同时把业务量做上去。

原来“不够痛”的效率问题，一下子变得现实起来。

这时候，项目团队前期准备的方案才真正有了落地机会。

所以随后，FDE做项目有一个很深的感受，很多AI需求一直都在，只是还没有痛到需要改变。

FDE要做的，是提前看见这个问题，在业务真正需要改变的时候，已经有一个可以验证的方案放在那里，不去强行制造需求。

三、AI 解决方案与交付路径

整个项目没有先设计出一套完整方案，再一次性上线。

实际上，它经历了一个很长的观察、验证、建立信任、立项、迭代的过程。

第一步，是先把问题看清楚，不急着选模型。

FDE没有一开始就跟客户讲“企业要上AI”。

FDE先把业务拆开来看，人工到底在干什么。

拆完以后会发现，整个审核过程本质上主要有几类工作，看图片、识别材料类型、读取关键信息、判断材料是否符合要求、填写相关数据，以及在不同系统之间搬运信息。

这样一拆，技术路径其实就自然出来了。

需要“看”的部分，用机器视觉、OCR和相关识别算法；需要从合同等复杂文本中提取信息的部分，后来逐步引入大模型；需要重复填写和系统间流转的部分，则通过RPA完成。

所以项目团队最终围绕的是一个目标，尽可能让机器替代人工去完成重复性的“看、读、填、搬”。

第二步，是用真实业务数据一点点把能力磨出来。

车管所材料审核最大的特点，是数据非常不标准。

项目团队最后做了大约9类图像材料，包括合同、发票、营业执照、身份证复印件等。

每一种材料都要重新收集真实素材、标注、训练，再上线观察效果。

这里跟实验室环境完全不一样。

比如身份证国徽面，正常情况下应该拍完整身份证，但有些群众上传的照片可能只拍了一个国徽。

合同更麻烦，机动车抵押登记涉及大量金融机构，每家公司的格式合同都不一样，有些为了把内容压缩在一页纸上，字体非常小，还有很多材料本身就是复印件，再经过拍照上传以后，图像质量进一步下降。

所以训练不可能一次就结束，要不断把真实业务中的异常样本拿回来，补充正样本、负样本，再继续优化。

整个研发和迭代周期前后大概持续了半年，识别率也是这样一点点从70%多提升到98%左右。

第三步，是把AI嵌回原来的业务流程，不做孤立工具。

这一点是项目实践表明非常关键的。

如果只是做一个识别Demo，识别完告诉工作人员“这张图片是什么”，价值其实很有限。

真正要解决的，是识别之后业务能不能继续往下跑。

所以项目团队把识别、审核、填单以及后续系统流转整个串起来。

车管所原有业务涉及不同Web系统，审核通过之后，数据还需要进入公安部统一的业务系统。

项目团队没有要求工作人员重新学习一套完全独立的工作方式，而是通过RPA把不同系统联动起来，实现了数据搬运。

最终，大部分正常业务可以自动完成，工作人员主要看结果和报表，只有异常情况才需要人工介入核验。

换句话说，项目团队把AI直接变成了原业务流程中的一个执行环节，工作人员不需要再面对一个独立工具。

第四步，是先用结果建立信任，再推动正式立项。

政务项目还有一个很现实的问题，不是技术做出来就能上线。

最开始客户对AI效果没有把握，项目要正式启动，还涉及报告、立项、预算以及技术可行性论证。

所以项目团队前期承担了一部分售前成本，先选取部分场景做起来。

与其让客户相信项目团队的PPT，不如让他先看到真实效果。

与此同时，项目团队原来的运维服务也在持续推进，通过一次次交付，客户知道项目团队不是“画饼”，技术能力和服务能力都逐渐得到认可。

等到AI方案本身也跑出了一定效果，再叠加人员减少、业务效率压力以及政府创新需求等条件，项目才真正获得立项机会。

所以在这个项目里，信任是在一次次交互结果里建立起来的，光靠认识远远不够。

FDE进入一个组织以后，第一个项目未必就是最终最有价值的项目。

有时候先从一个小切口进去，把第一件事情做好，才有机会真正看见后面的需求。

四、项目结果与业务价值

先看效率。

原来一单业务全流程审核大概需要15分钟，现在基本可以缩短到三五分钟。

随着审核效率提高，日均办件量也从原来的约七八百件，提高到1100件左右。

这里需要说明的是，AI并没有凭空创造这些需求。

很多群众原本就有办理需求，只是过去受制于审核产能，业务处理不过来。

AI把原来卡在人工审核环节里的产能释放出来以后，这部分需求才真正被承接。

但项目实践表明，比数字更重要的是人的工作发生了变化。

原来工作人员需要把大量时间花在打开图片、检查材料、填写信息这些重复劳动上。

自动化以后，这部分工作减少了，他们可以把时间用在群众咨询、新增业务以及更需要人工判断和沟通的事情上。

比如群众来到大厅以后有很多问题需要解释，以前后台审核占掉大量精力，现在工作人员可以把更多时间放到服务群众上。

所以这件事的本质，是重新分配人的时间，让一个人审核得更快只是表面收益。

对于参与驻点服务的合作方来说，变化同样明显。

在人员不增加甚至减少的情况下，整体办件量仍然能够保持并略有增长，这让原来因为人工成本过高而承压的服务模式有了更好的经营空间。

而对车管所来说，项目最终顺利通过验收，后续又持续有新的业务交给项目团队。

后来双方还共同成立了AI创新实验室，项目团队也继续派人员驻点，共同研发新的应用。

从项目实践看，这可能比某一个技术指标更能说明项目到底有没有真正创造价值。

一个AI项目真正成功的标志，是验收通过之后，客户还愿意继续和项目团队做第二个、第三个项目。

项目图示

原案例图示（PDF 第 20 页）

原案例图示（PDF 第 22 页）

五、关键落地难点

如果让FDE总结这个项目最难的地方，最难的是组织和规则，算法反而排在后面。

第一个挑战，是材料数据太不标准，识别率上不去。

车管所的材料不像实验室数据集那么干净，身份证、合同、发票这些常见材料在实际上传时会出现各种意想不到的形态。

这些问题相对明确，但解决起来并不轻松。

识别率不够，项目团队就继续收集样本；负样本不足，就补负样本；参数不合适，就继续优化。

这些问题虽然麻烦，但基本都有工程上的解决路径，真正难的在后面。

第二个挑战，是AI把过去人工审核里的“放宽”暴露了出来。

自动审核跑起来以后，项目团队发现有些业务过去人工审核时存在一定程度的“放宽”。

这时候问题从“模型能不能识别出来”，变成了“识别出来以后到底应该怎么办”。

如果完全按照技术标准严格执行，可能影响原有业务量和合作关系；如果继续保持过去的宽松尺度，又可能失去自动审核的意义。

这种事情技术团队自己不能拍板。

项目团队的做法是把问题和数据客观呈现给甲方，哪些材料存在问题，按照不同审核尺度每天能处理多少业务，业务量会发生什么变化，然后让甲方结合实际经营和管理要求做最终决策。

经过一段时间运行，大家有了真实业务数据，再逐渐找到效率、合规和业务量之间的平衡点。

这里FDE需要非常清楚自己的边界。

项目团队的职责是把技术能力做出来，把问题暴露出来，把不同选择可能产生的结果说明白；但涉及业务利益和管理规则的最终决策，必须交给业务负责人。

第三个挑战，是组织协同。

一个项目刚进去的时候，项目团队可能只跟一个部门、一个负责人打交道。

但真正开始落地以后，会涉及不同部门、不同角色甚至外部合作伙伴。

信息化、数字化、智能化一旦真正改变流程，就一定可能影响某些人的原有工作和利益。

所以FDE除了做技术，还必须会沟通、协调、项目管理，甚至要会“算利益账”。

项目团队要让不同角色看到，这个变化对他意味着什么，谁会获得收益，谁的工作会改变，出现冲突以后谁有最终决策权。

这些问题处理不好，再好的模型也很难真正进入生产环境。

六、FDE 交付方法与企业启示

做完这个项目，FDE心里渐渐笃定了一件事。

AI应用一定是从业务内部生长出来的，外部强行叠加进去的东西往往留不下来。

现在FDE去很多企业交流，大家都会说自己有“AI焦虑”。

老板知道AI很重要，信息部门也知道AI很重要，但项目团队问“业务人员具体想解决什么问题”，很多人反而说不清楚。

这时候如果FDE直接开始讲Agent、RAG、大模型，意义并不大。

FDE现在更习惯先问企业一个问题，能否先列出企业经营过程中最重要的十个问题。

如果十个问题能够列出来，项目团队再一起判断，哪些问题可以通过数字化解决，哪些可以通过智能化解决，哪些问题现在值得投入，哪些问题即使AI能做，投入产出比也不成立。

这才是FDE真正应该做的第一步。

所以项目经验表明，FDE进入企业，首先应该更像一个顾问，其次才是一个开发工程师。

第一，先找到真问题，再讨论AI。

不要从“业务人员会什么技术”出发找应用，要从业务每天真实发生的问题出发。

一个问题是不是值得做，FDE可以看几个很现实的指标，它是不是高频发生，是不是影响效率、收入、成本或者服务质量，业务部门自己有没有解决意愿，有没有预算。

只有这些条件成立，AI项目才有真正落地的基础。

第二，从一个小切口进入，别一上来就做“大而全”。

FDE进入车管所的入口，甚至只是一个遗留系统运维项目。

但这个小项目让FDE进入了现场，也让FDE真正看见业务怎么运行。

所以不要低估第一个小项目的价值。

小切口的意义，是建立信任，也是获得观察业务的机会。

第一件事情做好以后，才能逐渐进入更核心的流程，看到更多原来在会议室里看不到的问题。

第三，FDE必须长期靠近现场。

很多需求不是访谈一次就能问出来的。

这个案例里的材料审核问题，就是FDE在运维过程中一点点观察出来的。

客户一开始甚至不觉得这是一个特别需要解决的问题。

所以项目团队现在也会把人员派驻到客户现场，因为只有靠近现场，才能知道工作人员每天到底在做什么，什么事情最耗时间，哪些流程大家已经习以为常，却可能正是最值得AI改造的地方。

第四，不要只把AI做成一个工具，要把它嵌进业务流程。

真正的业务价值，在于识别之后数据能不能自动流转，流程能不能继续往下执行，异常情况谁来处理，原来的工作人员要不要多做一步操作。

如果AI只是多出来一个页面，最后还需要人工复制结果、粘贴到另一个系统里，那它带来的价值就会大打折扣。

AI真正落地，是它成为业务流程的一部分，旁边不用再单独多一个AI工具。

第五，组织能力往往比技术能力更决定项目成败。

技术能力当然重要。

没有基本技术能力，这个事情根本接不下来。

但到了真实项目里，技术越来越像一项基本技能。

真正拉开差距的，是沟通、管理、协调、需求分析以及理解业务的综合能力。

因为FDE面对的，从来都超出模型本身，背后还有客户、管理者、一线工作人员、合作伙伴、预算、流程、利益关系以及组织内部的决策机制。

一个FDE真正要搭建的，其实是业务与技术之间的桥梁。

技术只是桥的一端，另一端是业务问题、组织关系和真实价值。

只有两边真正接起来，AI才算完成了从“技术能力”到“业务能力”的最后一步。

七、可复用的交付资产

同类项目若要复制这条路径，可以优先沉淀以下交付物：

• 场景访谈记录与 As-Is／To-Be 流程图
• 业务对象、关键字段、角色责任和异常分支清单
• 知识地图、文档清洗规则、切片规范和高频问题测试集
• 图像类型清单、标注样本集、识别错误集和人工复核规则
• Agent 工作流定义、工具调用清单、提示词版本和任务评测集
• 系统集成图、字段映射、权限配置、失败重试与回写日志
• 覆盖普通、复杂和异常任务的验收样本与业务指标口径

来源与作者

Datawhale《FDE案例100》，受访者：陈景钗（温州市元贞数字科技有限公司创始人）；PDF 第 15-24 页，书内页码 14-23。本文为访谈资料的第三人称整理，不是本站新采访。