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才算完成了从“技术能力”到“业务能力”的最后一步。