Q1:作为FDE,你应用AI的具体场景是什么?在这个场景下遇到的具体问题长什么样?
这个案例有一点特殊,一开始客户并没有提出一个“AI需求”。我进入车管所,最早只是
为了接一个系统运维项目。
当时原来的系统承建商已经倒闭,留下来的源代码并不完整,文档也缺失,而且整个系
统涉及多种技术,有\.NET客户端、安卓端显示程序,也有Web管理和调度系统。很多
公司评估以后都不愿意接,因为这不是找一个工程师简单维护一下就能解决的问题,需
要真正把遗留系统扎进去看懂。我把这个项目接了下来。
但现在回过头来看,运维只是我进入业务现场的入口,真正有价值的需求,是进入现场
以后才慢慢发现的。在驻场过程中,我开始观察车管所的网办业务。
浙江的政务服务数字化程度已经比较高,很多事情群众在线上就可以办理,甚至一次都
不用跑。但我发现一个很有意思的问题,前台已经数字化了,后台却还有大量工作依赖
人工。
群众在线提交业务后,会上传各种材料,比如身份证、营业执照、合同、发票等。这些
材料基本都是图片,而且拍摄质量五花八门。
工作人员要一张一张点开,再用肉眼判断材料对不对、信息是否完整,然后继续进行后
续审核和录入。这个流程一直这么运行,所以大家甚至已经习惯了。但我在现场看下
来,问题其实很明显,可以总结成三个特征,慢、累、量上不去。
第一是慢。大量图片都需要人工打开、查看、核对,再把相关信息录入系统。单件业务
从头到尾审核下来,大概要15分钟。
第二是累。这种工作谈不上复杂,只是高度重复。工作人员每天长时间盯着屏幕看照
片,有人直接反馈“眼睛都受不了”。
第三是业务量上不去。车管所的网办业务背后还有一个比较特殊的业务关系。部分服务
由驻点快递企业参与,车管所完成审核和制证以后,由快递公司负责后续打包和寄递。
快递企业需要投入人员驻点,如果业务量不够、人工成本又高,这项服务本身就会面临
经营压力。
所以这件事情表面上看,是“工作人员看图片太累”,但往后拆,其实牵扯的是整个业
务链条。审核效率决定办件能力,办件能力影响群众服务,也影响合作方的运营成本和
整个服务模式能不能持续。
我在现场待得越久,越清楚一件事,FDE不能只等着客户把需求写成一句“我要一个AI审
核系统”再来做。很多时候,真正的需求并不会自己跳出来。你得先进入现场,看业务
是怎么跑的,看人在做什么,看哪个环节每天重复发生,再去判断这里有没有值得被AI
重新改造的地方。
Q2:在你参与之前,这个问题过去是怎么解决的?
其实没有特别的解决方案,就是靠人。
群众把材料上传以后,工作人员打开图片,用肉眼审核,再人工处理后面的业务。这个
流程已经运行了很长时间,对车管所来说,它甚至不被认为是一个特别需要解决的问
题。这点我觉得很重要。
我们今天回头看,会觉得“这么明显的重复劳动,为什么不自动化?”但站在当时业务
部门的角度,它是可以运行的。人员在那里,流程已经形成,大家知道每天该怎么做,
虽然慢一点、累一点,但没有影响到系统基本运转。
所以我第一次跟客户提出,可以用视觉技术替代一部分人工审核的时候,对方其实并没
有马上接受。他们的第一反应是,现在这样不也能干吗,为什么还要再花钱上一套新东
西。另外,他们对AI能不能真的达到业务要求也没有把握,哪怕市面上已经有一些现成
能力,一方面价格不低,另一方面谁也不敢保证拿过来就能解决车管所真实场景里的问
题。
所以从传统方式走向AI,原来的方式并没有突然失效。真正的变化来自业务条件。当时
经济环境发生变化,驻点服务企业也开始面临经营压力,希望减少人员投入,同时把业
务量做上去。原来“不够痛”的效率问题,一下子变得现实起来。这时候,我们前期准
备的方案才真正有了落地机会。
所以我后来做项目有一个很深的感受,很多AI需求一直都在,只是还没有痛到需要改
变。FDE要做的,是提前看见这个问题,在业务真正需要改变的时候,已经有一个可以
验证的方案放在那里,不去强行制造需求。
Q3:后来你使用AI解决这个问题的整体思路和关键步骤是什么?
整个项目没有先设计出一套完整方案,再一次性上线。实际上,它经历了一个很长的观
察、验证、建立信任、立项、迭代的过程。
第一步,是先把问题看清楚,不急着选模型。
我没有一开始就跟客户讲“我们要上AI”。我先把业务拆开来看,人工到底在干什么。拆
完以后会发现,整个审核过程本质上主要有几类工作,看图片、识别材料类型、读取关
键信息、判断材料是否符合要求、填写相关数据,以及在不同系统之间搬运信息。
这样一拆,技术路径其实就自然出来了。需要“看”的部分,用机器视觉、OCR和相关
识别算法;需要从合同等复杂文本中提取信息的部分,后来逐步引入大模型;需要重复
填写和系统间流转的部分,则通过RPA完成。
所以我们最终围绕的是一个目标,尽可能让机器替代人工去完成重复性的“看、读、
填、搬”。
第二步,是用真实业务数据一点点把能力磨出来。
车管所材料审核最大的特点,是数据非常不标准。我们最后做了大约9类图像材料,包
括合同、发票、营业执照、身份证复印件等。每一种材料都要重新收集真实素材、标
注、训练,再上线观察效果。这里跟实验室环境完全不一样。
比如身份证国徽面,正常情况下应该拍完整身份证,但有些群众上传的照片可能只拍了
一个国徽。合同更麻烦,机动车抵押登记涉及大量金融机构,每家公司的格式合同都不
一样,有些为了把内容压缩在一页纸上,字体非常小,还有很多材料本身就是复印件,
再经过拍照上传以后,图像质量进一步下降。
所以训练不可能一次就结束,要不断把真实业务中的异常样本拿回来,补充正样本、负
样本,再继续优化。整个研发和迭代周期前后大概持续了半年,识别率也是这样一点点
从70%多提升到98%左右。
第三步,是把AI嵌回原来的业务流程,不做孤立工具。
这一点是我觉得非常关键的。如果只是做一个识别Demo,识别完告诉工作人员“这张
图片是什么”,价值其实很有限。真正要解决的,是识别之后业务能不能继续往下跑。
所以我们把识别、审核、填单以及后续系统流转整个串起来。车管所原有业务涉及不同
Web系统,审核通过之后,数据还需要进入公安部统一的业务系统。我们没有要求工作
人员重新学习一套完全独立的工作方式,而是通过RPA把不同系统联动起来,实现了数
据搬运。
最终,大部分正常业务可以自动完成,工作人员主要看结果和报表,只有异常情况才需
要人工介入核验。换句话说,我们把AI直接变成了原业务流程中的一个执行环节,工作
人员不需要再面对一个独立工具。
第四步,是先用结果建立信任,再推动正式立项。
政务项目还有一个很现实的问题,不是技术做出来就能上线。最开始客户对AI效果没有
把握,项目要正式启动,还涉及报告、立项、预算以及技术可行性论证。所以我们前期
承担了一部分售前成本,先选取部分场景做起来。
与其让客户相信我们的PPT,不如让他先看到真实效果。与此同时,我们原来的运维服
务也在持续推进,通过一次次交付,客户知道我们不是“画饼”,技术能力和服务能力
都逐渐得到认可。等到AI方案本身也跑出了一定效果,再叠加人员减少、业务效率压力
以及政府创新需求等条件,项目才真正获得立项机会。
所以在这个项目里,信任是在一次次交互结果里建立起来的,光靠认识远远不够。FDE
进入一个组织以后,第一个项目未必就是最终最有价值的项目。有时候先从一个小切口
进去,把第一件事情做好,才有机会真正看见后面的需求。
Q4:相比传统方式,使用AI后的实际效果如何?
先看效率。原来一单业务全流程审核大概需要15分钟,现在基本可以缩短到三五分钟。
随着审核效率提高,日均办件量也从原来的约七八百件,提高到1100件左右。
图1:业务系统成果演示图
这里需要说明的是,AI并没有凭空创造这些需求。很多群众原本就有办理需求,只是过
去受制于审核产能,业务处理不过来。AI把原来卡在人工审核环节里的产能释放出来以
后,这部分需求才真正被承接。
但我觉得,比数字更重要的是人的工作发生了变化。原来工作人员需要把大量时间花在
打开图片、检查材料、填写信息这些重复劳动上。自动化以后,这部分工作减少了,他
们可以把时间用在群众咨询、新增业务以及更需要人工判断和沟通的事情上。
比如群众来到大厅以后有很多问题需要解释,以前后台审核占掉大量精力,现在工作人
员可以把更多时间放到服务群众上。所以这件事的本质,是重新分配人的时间,让一个
人审核得更快只是表面收益。
对于参与驻点服务的合作方来说,变化同样明显。在人员不增加甚至减少的情况下,整
体办件量仍然能够保持并略有增长,这让原来因为人工成本过高而承压的服务模式有了
更好的经营空间。
而对车管所来说,项目最终顺利通过验收,后续又持续有新的业务交给我们。后来双方
还共同成立了AI创新实验室,我们也继续派人员驻点,共同研发新的应用。在我看来,
这可能比某一个技术指标更能说明项目到底有没有真正创造价值。一个AI项目真正成功
的标志,是验收通过之后,客户还愿意继续和你做第二个、第三个项目。
Q5:在部署AI过程中,是否遇到了新问题或挑战?你是怎么解决的?
如果让我总结这个项目最难的地方,最难的是组织和规则,算法反而排在后面。
第一个挑战,是材料数据太不标准,识别率上不去。
车管所的材料不像实验室数据集那么干净,身份证、合同、发票这些常见材料在实际上
传时会出现各种意想不到的形态。这些问题相对明确,但解决起来并不轻松。识别率不
够,我们就继续收集样本;负样本不足,就补负样本;参数不合适,就继续优化。这些
问题虽然麻烦,但基本都有工程上的解决路径,真正难的在后面。
第二个挑战,是AI把过去人工审核里的“放宽”暴露了出来。
自动审核跑起来以后,我们发现有些业务过去人工审核时存在一定程度的“放宽”。这
时候问题从“模型能不能识别出来”,变成了“识别出来以后到底应该怎么办”。
如果完全按照技术标准严格执行,可能影响原有业务量和合作关系;如果继续保持过去
的宽松尺度,又可能失去自动审核的意义。这种事情技术团队自己不能拍板。我们的做
法是把问题和数据客观呈现给甲方,哪些材料存在问题,按照不同审核尺度每天能处理
多少业务,业务量会发生什么变化,然后让甲方结合实际经营和管理要求做最终决策。
经过一段时间运行,大家有了真实业务数据,再逐渐找到效率、合规和业务量之间的平
衡点。这里FDE需要非常清楚自己的边界。我们的职责是把技术能力做出来,把问题暴
露出来,把不同选择可能产生的结果说明白;但涉及业务利益和管理规则的最终决策,
必须交给业务负责人。
第三个挑战,是组织协同。
图2:算法成果嵌入到业务流程中
一个项目刚进去的时候,你可能只跟一个部门、一个负责人打交道。但真正开始落地以
后,会涉及不同部门、不同角色甚至外部合作伙伴。信息化、数字化、智能化一旦真正
改变流程,就一定可能影响某些人的原有工作和利益。
所以FDE除了做技术,还必须会沟通、协调、项目管理,甚至要会“算利益账”。你要让
不同角色看到,这个变化对他意味着什么,谁会获得收益,谁的工作会改变,出现冲突
以后谁有最终决策权。这些问题处理不好,再好的模型也很难真正进入生产环境。
Q6:根据你的经验,我们怎么才能更好地把AI部署到实际业务中?
做完这个项目,我心里渐渐笃定了一件事。AI应用一定是从业务内部生长出来的,外部
强行叠加进去的东西往往留不下来。
现在我去很多企业交流,大家都会说自己有“AI焦虑”。老板知道AI很重要,信息部门也
知道AI很重要,但你问“你具体想解决什么问题”,很多人反而说不清楚。这时候如果
FDE直接开始讲Agent、RAG、大模型,意义并不大。
我现在更习惯先问企业一个问题,你能不能先列出企业经营过程中最重要的十个问题。
如果十个问题能够列出来,我们再一起判断,哪些问题可以通过数字化解决,哪些可以
通过智能化解决,哪些问题现在值得投入,哪些问题即使AI能做,投入产出比也不成
立。这才是FDE真正应该做的第一步。所以我认为,FDE进入企业,首先应该更像一个
顾问,其次才是一个开发工程师。
第一,先找到真问题,再讨论AI。
不要从“我会什么技术”出发找应用,要从业务每天真实发生的问题出发。一个问题是
不是值得做,我会看几个很现实的指标,它是不是高频发生,是不是影响效率、收入、
成本或者服务质量,业务部门自己有没有解决意愿,有没有预算。只有这些条件成立,
AI项目才有真正落地的基础。
第二,从一个小切口进入,别一上来就做“大而全”。
我进入车管所的入口,甚至只是一个遗留系统运维项目。但这个小项目让我进入了现
场,也让我真正看见业务怎么运行。所以不要低估第一个小项目的价值。小切口的意
义,是建立信任,也是获得观察业务的机会。第一件事情做好以后,你才能逐渐进入更
核心的流程,看到更多原来在会议室里看不到的问题。
第三,FDE必须长期靠近现场。
很多需求不是访谈一次就能问出来的。这个案例里的材料审核问题,就是我在运维过程
中一点点观察出来的。客户一开始甚至不觉得这是一个特别需要解决的问题。所以我们
现在也会把人员派驻到客户现场,因为只有靠近现场,你才能知道工作人员每天到底在
做什么,什么事情最耗时间,哪些流程大家已经习以为常,却可能正是最值得AI改造的
地方。
第四,不要只把AI做成一个工具,要把它嵌进业务流程。
真正的业务价值,在于识别之后数据能不能自动流转,流程能不能继续往下执行,异常
情况谁来处理,原来的工作人员要不要多做一步操作。如果AI只是多出来一个页面,最
后还需要人工复制结果、粘贴到另一个系统里,那它带来的价值就会大打折扣。AI真正
落地,是它成为业务流程的一部分,旁边不用再单独多一个AI工具。
第五,组织能力往往比技术能力更决定项目成败。
技术能力当然重要。没有基本技术能力,这个事情根本接不下来。但到了真实项目里,
技术越来越像一项基本技能。真正拉开差距的,是沟通、管理、协调、需求分析以及理
解业务的综合能力。
因为FDE面对的,从来都超出模型本身,背后还有客户、管理者、一线工作人员、合作
伙伴、预算、流程、利益关系以及组织内部的决策机制。
一个FDE真正要搭建的,其实是业务与技术之间的桥梁。技术只是桥的一端,另一端是
业务问题、组织关系和真实价值。只有两边真正接起来,AI才算完成了从“技术能力”到
“业务能力”的最后一步。