ARTICLE · 1185430
体制内的AI现场:前台早就数字化了,后台还是人
一个车管所的工作人员，每天把群众上传的身份证、合同、发票图片一张一张点开，肉眼判断对不对、全不全，再录入系统。审核一件大概15分钟——案例作者自述口径。有人直接反馈：「眼睛都受不了。」
这是后台。同一个机构的前台，是另一番样子——「浙江的政务服务数字化程度已经比较高，很多事情群众在线上就可以办理，甚至一次都不用跑」。说这话的，正是进驻这家车管所、把AI落进业务的案例作者。
最扎的不是慢。是这个环节在车管所自己人眼里，「甚至不被认为是一个特别需要解决的问题」。它运行了很多年，不投诉、不亮灯、能跑——所以它从来不出现在任何一张数字化验收单上。
我手上这批材料，是2026年9月Datawhale发布的《FDE案例100》首批24个案例，全是FDE——进客户现场把AI落进业务的交付角色——亲手做出来的项目。里面有德国工厂，也有跨境生意，这篇只取三个中国的体制内现场：一个车管所，一个央企科研机构，一家省属国企。
这三个现场的账，跟「体制内是AI落地洼地」的公论反着打：车管所网办项目已上线并通过验收，之后客户还续做新项目；央企财务从一个破冰项目扩到了10个场景（当事人自述）；国企里长出了行政同事自己搭的小工具。
先把丑话讲在前面：这24案是同一个访谈编选工程的整理稿，不是24个对照实验，下面所有效果，我只说到「当事人自述」为止。
都说体制内最不敢错、最怕担责、流程最重。可为什么最不敢错的地方，反而先跑通了？答案压在最后。先把三个现场看完。
车管所：验收单上没有的那一行
这个项目的入口，不是AI需求。
案例作者最早去车管所，接的是一个没人愿接的遗留系统运维：原承建商倒闭，源代码不完整，文档缺失，系统横跨.NET客户端、安卓端、Web管理调度，「很多公司评估以后都不愿意接」。他把这个项目接了下来——运维成了进现场的门票。
驻场之后他才看清那个反差：「前台已经数字化了，后台却还有大量工作依赖人工」。群众在线提交业务后上传的材料基本都是图片，拍摄质量五花八门，工作人员要一张一张点开、肉眼判断、再审核录入。他把问题总结成六个字：「慢、累、量上不去」。
慢不只是体验问题。车管所网办背后有一条利益链：驻点快递企业投入人员驻点，靠业务量摊薄人工成本——业务量上不去，这项服务本身就面临经营压力。审核效率决定办件能力，办件能力影响群众服务，也影响合作方的运营成本和整个服务模式能不能持续。一件15分钟的肉眼审核，卡住的是整条链的饭碗。
他第一次向客户提视觉替代人工，对方的反应是：「现在这样不也能干吗，为什么还要再花钱上一套新东西」。转机不是技术，是经营条件变了——驻点企业承压，「原来『不够痛』的效率问题，一下子变得现实起来」。作者的总结是：「很多AI需求一直都在，只是还没有痛到需要改变」。
做法不炫技。把人工拆成「看、读、填、搬」：看图用机器视觉和OCR，复杂合同文本逐步引入大模型，重复填写和系统间流转交给RPA。AI研发阶段前后覆盖了大约9类图像材料——合同、发票、营业执照、身份证复印件等（研发覆盖口径），每类各自收集真实异常样本，迭代约半年，识别率从70%多提到98%左右（当事人自述，无类别分布与误报口径）。
真正值钱的是下一步：嵌回去。他的原话是：「如果只是做一个识别Demo……价值其实很有限。真正要解决的，是识别之后业务能不能继续往下跑。」识别、审核、填单、进公安部统一系统的数据流转，用RPA串成一条线。工作人员从看图的人，变成「主要看结果和报表，只有异常情况才需要人工介入核验」的人。
立项是倒着来的。前期自担售前成本，先选部分场景做起来，「与其让客户相信我们的PPT，不如让他先看到真实效果」。效果跑出来了，项目才拿到立项。
结果口径：单件审核从大概15分钟缩到三五分钟，日均办件从约七八百件提到1100件左右（当事人自述，无全量分母与误判返工口径）。项目最终顺利通过验收（事件事实，不是第三方效率核验），客户续做新项目，双方共建AI创新实验室。作者的判断：「一个AI项目真正成功的标志，是验收通过之后，客户还愿意继续和你做第二个、第三个项目」。
但这个案例最深的一道缝，不在效率账里。
自动审核跑起来之后，现场出现了它在人工时代从不存在的东西：证据。「AI把过去人工审核里的『放宽』暴露了出来」。严格执行，可能影响业务量和合作关系；继续宽松，自动审核又失去意义。「问题从『模型能不能识别出来』，变成了『识别出来以后到底应该怎么办』」。
「这种事情技术团队自己不能拍板」。作者的做法是把问题和数据摊给甲方：哪些材料有问题，按不同审核尺度每天能处理多少业务，业务量会发生什么变化，让甲方结合实际经营和管理要求做最终决策；「涉及业务利益和管理规则的最终决策，必须交给业务负责人」。
我们的拆解到这里才见底：AI进这种现场的第一个产出不是效率，是审计。它先把数字化验收单上从来没有的那一行点出名字——后台15分钟一件的肉眼审核；再把人工审核里靠「放宽」糊过去的裁量全部亮灯。机器进现场，先当的是最严格的审计员，第二才是干活的。
这笔账没闭合的地方也要记下：甲方最终选了哪条线、决策之后谁对后果负责，原文完全没披露。
央企财务：耗时间的不是填表，是填表之前的判断
第二个现场，央企科研机构的财务流程。说话人先钉清楚：受访的毛卫俊是杭州舳舻科技CEO，也是这个案例的作者——下面的引语都是他的，不是央企财务人员的原话。
一张报销发票，财务要判断费用性质是差旅还是招待，要判断记在哪个项目，还要去找这个人的出差申请、审批记录、部门、项目。「这些信息其实分散在不同的业务流程里。真正耗时间的，是填表之前那段判断过程」。判断完了还有执行：打开集团网站，创建单据，一行一行填写，再提交。
「一个是判断时间，一个是执行时间」——两种时间捆在同一个岗位上。业务量一涨，财务只能线性加人：「业务量增加一倍，就增加一倍的财务人员，这条路很难走得通」。链条另一头更亏：科研机构的博士，时间被报销流程吃掉。「让高价值的人去做低价值、重复性的流程工作，本身就是一种浪费」。
解法从入口开始压扁：员工在钉钉里对机器人说「我要报销」，发票发过去，后面交给AI。AI识别发票，关联出差申请、审批、部门、项目，再按财务规则判断。变化的实质是：「以前是人自己去系统里找信息、判断信息，现在变成AI主动把信息组织起来，再辅助完成判断」——聚合上下文这件事，从人搬到了系统。
关键在确认点画在哪。财务是严肃业务，「AI说什么就是什么」不成立。但这个现场没有选择层层盖章，而是在流程里装了一套监督机制：「几个AI角色一起工作：一个负责执行判断，一个负责监督，一个负责发现风险」。分流规则只有一句：「对于已经比较确定的业务，就直接往后走」；几个模型判断后仍有不确定的，进风险监控，由人重点关注。人的位置随之改写：「AI处理大部分确定性工作，人只处理真正需要关注的风险和异常」。最后RPA当「手」，自动进集团网站建单、逐行填写、提交。整条流程五段：业务信息获取→AI判断→AI监督→风险识别→RPA执行。
我们的拆解：注意人在哪里——不在每一笔后面签字，在异常处蹲守。确定性直行，异常才升级。这是把「不敢错」翻译成了分流设计，不是翻译成公章。
结果口径：整类财务场景从过去半个月甚至一个月，到现在约一天、两天；项目最终落地10个AI相关应用场景（当事人自述，无单据分母、无对照明细，也还没有审计口径）。
钱和时序也有讲究。财务数据敏感，不能进公共模型，要数据不出域的私有化部署；毛卫俊提过自己此前帮企业采购两百多万元量级的算力一体机——注意，这是他此前的采购量级自述，不是这个案例已发生的投入。大钱不能先花：「先用小场景证明价值，再推动基础设施建设，不能反过来」。所以第一个项目被叫作「破冰项目」，选场景看三个条件：业务真的痛、实现相对可控、ROI能够快速被看见。业务尝到甜头，项目就从「你要让我用」变成「我希望你帮我继续做」。
这笔账没闭合的地方：放行权在谁、错账问责链怎么走、确定性怎么判定，原文都没给；周期数字是整类场景口径，不是每张发票的对照。
国企：先给签字权，才有人交知识
第三个现场，省属国企一级子公司，服装、美妆、3C十多个电商业务线，OA、ERP、数据中台、信息化部门一样不缺。管理层的诉求很模糊：「能不能再往AI走一步」。真实需求藏在口号底下：业务在涨，编制不涨；法务团队只有两个人，对着全业务线的合同。
第一年走的是标准路子：IT牵头搭技术底座。底座做出来了，然后发现不对——「系统有了，客户的员工没有用起来，业务并没有真的发生变化」。员工来了，「可能连提示词是什么都不知道」。后来牵头权挪到人事部门，从培训重新推进。系统怎么做的问题解决了，员工怎么用、流程怎么改、组织怎么配合的问题，才刚开场。
这个案子最有分量的设计，是签字权。「有些业务涉及法务、财务等责任问题，AI最终不能承担责任，所以真正进入工作流的Agent，大部分最终都需要人确认」；AI负责大量重复工作，「但最终仍然由人确认、签字和承担责任」。
这句话在本案里干着两份活。明面上是合规边界：责任必须落在能担责的人头上。暗地里是组织机制：如果员工觉得「你让我把我的知识全部交出来，然后AI把我的工作替代掉，那我为什么要配合？」，项目从第一天就长阻力。人确认、人签字、人担责，AI才站到助手的位置——员工让渡的是重复劳动，留住的是责任和位置。
土壤养出了果实。全员培训之后，管行政物品的同事，自己用提示词加数据中台的MCP能力，做了个领电池提醒的小工具：员工在IM上问机器人电池还有没有，系统查库存，不够就提醒行政补货。工具本身业务价值不大——这台电池柜的成本账，我在上一篇拆过，这里只看土壤：培训铺了底，助手叙事卸了防备，牵头权挪到了离人最近的部门，企业里才有人敢想「这个问题我能不能用AI解决」。
案例作者转述了一笔客户账：法务助手先筛历史合同的关键条款和风险，再交法务最终确认，原本要新增的一个法务编制省下来了，折算一人年的综合成本（作者转述的客户情况自述，无招聘决策核验）。
作者在复盘里排的序，值得钉在墙上：「人最难，其次是组织，再是数据，最后才是技术」。
这笔账没闭合的地方：项目做了两年，没有量化使用率；确认签字的人拿什么信息、有多少时间、签字能不能真否决，原文一个字没提。
我们的拆解：不敢错，是设计约束
三个现场，三套技术栈——视觉加OCR加RPA，多AI角色加RPA，知识萃取加Agent。去掉行业名词，生长方式是同一套。我们的拆解有三条。
第一条，嵌回原系统，不另起炉灶。车管所的AI嵌回原有Web系统和公安部流转；财务的AI嵌进钉钉入口和集团网站；国企的AI接在已有的OA、ERP、数据中台上。判据就是车管所那句话：机器做完，业务要能接着往下跑。体制内没有「先装个新工具试试」的空间——系统是要背责任的，另起炉灶等于另立一个责任主体。
第二条，多角色监督兜底，替代激进放权。三个案子没有一个把最终决策权交给机器：财务场景三个AI角色互查、异常进风险监控；国企场景大部分进工作流的Agent仍由人确认签字；车管所把尺度决策整个交回甲方。监督不是对AI不放心，是把「不敢错」做成常设机构。
第三条，先验证后立项。车管所自担售前成本，先跑部分场景再立项；财务现场破冰项目先行，大额基建后置。顺序倒过来：先给真效果，再谈预算。
三条背后是同一条设计约束：「不敢错」不是体制内上AI的刹车，是方向盘。它决定了AI落地在这种现场的确认点必须比民企更前置。民企可以小步快跑，错了改回来；体制内一次错账就是问责事故，所以机器的分寸必须提前画死——哪里直行、哪里必须停、停下找谁签字。
同一片土壤里，长出了两种确认密度（这是我们的跨案对照，不是原案说法）：财务场景规则度高、错了能在流程里拦住，就用异常驱动，人不逐笔签核；国企场景责任压顶，原文的口径是「大部分」进工作流的Agent都需要人确认——整体确认密度高一档。确认点密度不是态度问题，是容错成本的函数。
强合规现场上AI，先过四道题
如果你正要把AI推进一个强合规现场，先做四道题，再做方案：
- 确认点画了吗？
上线前先在流程图上标出人介入的位置——异常驱动，不是逐笔签核。哪些业务确定性高可以直行，哪些必须停进风险监控，停下来找谁，先写死，别等出了事再补。 - 尺度谁拍板？
凡是涉及裁量尺度的决策，把「不同尺度→每天处理多少业务→业务量怎么变」的数据摊开，交给业务负责人。技术方呈数据，不站队。 - 嵌回去了吗？
机器做完，活儿要能接着往下跑。孤立Demo，在车管所那案的判据里不算交付。 - 验证在立项前面吗？
自担成本先给真效果，再谈立项预算；大额基建放在价值证明之后。
外加一句自检，进门之前问客户，也问自己：你的数字化验收单上，有没有「后台产能」这一行？没有的话，先去后台站一个下午，数一数那件没人投诉、不亮灯、能跑的事。
这套判断什么时候失灵，也写实。
确认点画在纸上，确认人却没有信息、时间和权限——清单第一条会以最像跑通的方式失效。国企那案的「人确认签字」，原文没有回答确认者拿什么确认、签字能不能真否决；名义确认不是实质责任。
「确定性」的判据本身是模型给的——这是财务那案最大的暗雷。哪些业务算「已经比较确定」可以直行，原文没有披露分离判据；判「确定」的模型错了，异常驱动就变成异常漏行。现场合规压力越大，这条失效的代价越高。
业务还不痛——车管所那句话还有另一面：没有经营压力，先验证后立项会退化成无限期售前，方案备好了，风一直不来。
把自述当成绩——三案的效果数字全部是当事人自述，验收是事件事实，不是第三方效率核验。这套判断描述的是生长方式，不是可复制的模板；换一个现场，样本、尺度、利益结构都得重算。
FDE系列前情：先找损失，再谈AI · 原来「不值得管」的钱，AI让它值得管了 · AI帮你做工具，和工具离了AI才能跑，是两件事 · AI落地分六档：从H0到H5——四篇都在本号历史里。
要是你身边正有人把「体制内上不了AI」当公论讲，把这篇转给他；顺手点个「在看」，四道题下次进场前好翻。
