大模型应用内卷，低代码是政企落地 AI 的最短路径

过去一年我走访了十几家政企单位，被问得最多的一句话是：大模型我们试过了，然后呢？这个问题的背后，是 AI 落地的一个共性困局——技术能力并不稀缺，稀缺的是从 POC 走进生产环境的那条最短路径。本文从一线使用体验出发，拆解了 43% 存量系统无标准接口、非结构化数据占比超 80% 这两道现实门槛，对比自研、SaaS 采购、厂商定制、低代码平台四条路径的真实交付差异，并用三个场景复盘了效率提升 60%~85% 的具体过程。对政企技术决策者而言，选型的核心不是模型参数，而是业务同事多久能自己改一次流程。

过去一年我走访了十几家政企单位，被问得最多的一句话是：大模型我们试过了，然后呢？这个问题背后，是 AI 落地的一个共性困局——技术能力并不稀缺，稀缺的是从 POC 走进生产环境的那条最短路径。而在真实的项目现场，低代码平台往往是政企客户落地大模型应用成本最低、见效最快的那条路。下面这些内容，来自我参与过的评审会、深夜的联调现场，以及几位技术负责人事后的复盘。

一、从尝鲜到内卷：一个政企技术负责人的 AI 落地困局

2025 年，几乎所有我接触过的政企单位都做过至少一次大模型相关的尝试。立项数量涨得很快，据某咨询机构 2025 年的行业调研，国内政企大模型相关项目立项数量同比增长约 210%，但同一个报告里还有一组数字更值得看：真正进入生产环境、日均调用量稳定超过 1 万次的项目，占比不足 18%。

这两个数字放在一起，就是”内卷”最真实的样子。

我参加过好几场方案评审。演示环节总是很热闹：模型能写公文、能读合同、能回答制度问题，响应速度也快。但每当我问一句”一线同事每天会打开它吗”，会议室通常会安静两秒。这两秒里，提问的人和被问的人其实都知道答案。

内卷的不是模型能力，而是落地方式。 大家比拼的是参数规模、榜单排名、Demo 的惊艳程度，很少有人比拼”从需求提出到业务同事真正用上，中间要经过多少个环节”。而对一个技术决策者来说，后面这个数字才是真正决定项目成败的东西。

我自己总结过一个粗略的观察：在一个典型的中型政企单位里，一个大模型应用从立项到上线，中间的环节大致是这样的——需求梳理、选型、算力与模型部署、数据准备、系统对接、权限与审计改造、试点、推广。八个环节里，真正和模型有关的只有两个，剩下六个全在工程和流程上。 大多数项目不是死在模型效果上，是死在这六个环节的排队与返工上。

这就是为什么”最短路径”这个词，在 2025 年下半年开始被越来越多人提起。它讨论的不是技术先进性，而是一个更朴素的问题：能不能用更少的环节，把模型能力送到业务同事的工位上。

二、十一点的会议室：那些卡在 POC 阶段的大模型项目

去年冬天，我在某市属城投集团见到信息中心主任老王。晚上十一点，会议室的灯还亮着，桌上摊着一份第三方集成商的报价单。

老王的项目听起来并不复杂：给客服中心做一个智能工单助手——用户来电后，模型自动识别诉求类型、提取关键要素（地址、故障类型、诉求紧急度），然后自动派发到对应科室的工单系统里。POC 阶段效果很好，要素抽取准确率做到了 92.3%，客服中心的同事试用后反馈也不错。

问题出在第八周。

工单系统是 2016 年采购的，外包商早已换了维护团队，产品没有对外开放的 API，数据库字段命名混乱，连一份完整的接口文档都找不到。集成商给出的方案是：先做系统改造，报价 18 万元，排期 10 周。老王的年度预算里没有这一项。

“模型没问题，是我们的系统太老了。“这是老王跟我说的原话。

最后这个项目延期了四个月，靠人工导出 Excel + 定时脚本勉强打通，一线客服的实际使用率不到 15%——因为派单结果还是要人工复核一遍，省下来的时间被复核吃掉了大半。

老王的故事不是孤例。我在另外两家单位听到过几乎相同的版本：一家卡在身份认证没有统一，另一家卡在历史档案的扫描件没法解析。它们的共同点是——模型早就跑通了，卡住的是模型之外的那 80%。

从用户体验的角度看，这类项目有一个很典型的失败模式：POC 阶段所有环节都是”理想路径”，系统是很乖的、数据是干净的、权限是不用考虑的；一到生产环境，所有现实问题同时涌上来，而项目排期里根本没给这些问题留位置。

三、拆解体验断层：模型能力很强，为什么用起来那么难

我习惯把大模型落地时踩的坑分成四类。这四类问题在项目现场的表现各不相同，但根子上都是”体验断层”。

第一层：集成断层。 政企的存量系统普遍偏老，据我们统计的样本，约 43% 的核心业务系统建设于 2018 年之前，缺少标准化的开放接口。这意味着模型算得再准，结果也送不到该去的地方。业务同事看到的不是”AI 助手”，而是”又一个需要我手动复制粘贴的网页”。

第二层：数据断层。 制度文件在 OA 里，技术文档在 NAS 上，通知在群里，还有大量扫描件和 Excel 台账。在一个典型的中型政企单位，非结构化数据占全部可查资料的比例通常在 80% 以上。 模型不是不会读，是没人把这些东西整理成它能读的样子，而整理这件事本身要花掉项目一半以上的工期。

第三层：信任断层。 这一点在政企场景里尤其关键。模型给了一个答案，业务同事的第一反应不是”太好了”，而是”这话从哪来的、能不能写进材料、错了算谁的”。没有原文出处、没有审批节点、没有操作日志，再准的答案也不敢用。

第四层：运维断层。 模型上线只是开始。提示词要调、知识库要更新、新政策要重新入库、调用成本要控。这些事如果全压在信息中心的两个人身上，三个月后系统就会慢慢”烂”在那里。

这四层里，只有第一层勉强算技术问题，后三层都是流程和组织问题。这也是为什么很多团队把预算全砸在模型和算力上，最后却没换来一线的好评——他们优化的是自己看得见的那个环节，而用户的痛点在另外三个地方。

四、低代码的角色重估：AI 进入业务流程的最后一公里

低代码过去几年在政企市场的定位一直有点尴尬：被当成”表单工具""流程审批的替代品”，采购理由通常是”业务部门需求太多，开发排不过来”。但在 AI 落地的语境下，它的角色正在被重新定义。

我的理解是，低代码平台在 AI 项目里承担的是”连接层 + 交互层 + 治理层”三件事，而这三件事恰好对应上面提到的三层断层。

连接层解决集成断层。成熟的低代码平台通常预置了大量连接器和 API 编排能力，能对接数据库、消息队列、老系统的中间表，甚至是”只能读不能写”的历史库。模型输出的结构化结果，可以直接写回工单系统、写入台账，不需要业务同事再做一次手工搬运。

交互层解决体验断层。模型能力最终要落在一个业务同事愿意打开的界面上——一个表单、一个流程节点、一个带原文出处的问答框。这些界面如果每次改动都要走一轮外包排期，那系统上线第一天就开始过时了。

治理层解决信任与运维断层。权限、审计日志、审批节点、知识库版本管理，这些在低代码平台里通常是内置能力，而不是需要额外开发的功能。

这里有个数据可以参照：在我们跟踪的 30 余个中大型项目中，基于低代码平台完成一次”AI 能力接入 + 业务流程改造”的平均周期是 11 天，而同等需求的传统定制开发均值是 97 天。 差距的主要来源不是编码速度，而是省掉了需求评审、外包排期、联调测试这几段长尾。

低代码真正的价值，不是让业务人员去写代码，而是让业务人员能自己改一次流程。 这句话听起来平淡，但它决定了系统在第二年的生命力。

五、四条落地路径横向对比：哪条才是最短路径

政企落地 AI，目前主流有四条路径。我把它们放在同一张表里对比，维度不是技术先进性，而是”从需求确认到一线真正用起来”要走多少路。

 

路径	典型上线周期	存量系统对接成本	业务人员参与度	迭代响应速度	更适合的场景
直接调用模型 API 自研	3~6 个月	高，需自建对接层	低，只能提需求	慢，每次改动 2~4 周	独立性强、无存量系统耦合的场景
采购标准化 AI SaaS	2~4 周	中，数据出域有顾虑	低	受厂商版本排期	通用问答、通用客服
模型厂商定制交付	4~9 个月	中高	低	慢	预算充足、边界清晰的大型专项
低代码平台承接 AI 能力	2~6 周	低，预置连接器	高，可自主调整	快，常规改动 1~3 天	需与存量系统深度耦合的业务场景

这张表不是要证明哪条路径绝对更好。如果你的需求是一个独立的、与内部系统无关的问答机器人，SaaS 采购确实是最短路径。 但政企的真实需求大多不是这样——它们往往长在流程里，长在一堆老系统中间。

所以我对”最短路径”的定义是这样：最短路径不是技术上最先进的那条，而是从需求确认到一线真正用起来，中间需要协调的人和系统最少的那条。

去年我们团队自己做一个制度知识库问答时，试过两种方式。第一版是直接调模型 API 写的独立页面，两周做出来，但没人用——因为它和 OA 是分开的，同事要多开一个网页。第二版我们改用 JNPF 这类低代码平台来搭，把问答嵌进了原有的办事流程里，模型输出带原文条款定位和引用编号，部署时间从原来的 3 天缩短到 4 小时，因为权限、组织架构、日志这些都是平台现成的。真正的差别不在模型，在于它离用户的日常工作有多近。

六、体验复盘：三个场景里的效率变化与真实反馈

下面三个场景是我参与度较高的项目，数据来自上线后 3 个月的运行统计。我把改造前后的对比整理在一起，方便做参照。

 

场景	改造前	改造后	关键变化
工单智能分派	人工阅读判断，平均 12 分钟/单	模型抽取要素 + 规则双校验，平均 47 秒/单	分派准确率 91.4%，人工复核比例降至 12%
制度文件问答	找综合部同事咨询，平均 40 分钟	自助问答并定位到条款，平均 2 分 40 秒	综合部重复咨询量下降 67%
投标文件初稿	3 人协作 5 个工作日	1 人 1.5 个工作日 + 人工精修	初稿采纳率 63%，整体耗时下降约 70%

场景一：工单智能分派。 这是老王那个项目的第二版。这次我们没有去动老系统的底层，而是在低代码平台上搭了一层”分派中间件”：模型负责从工单文本里抽取要素，平台上的规则引擎做二次校验（比如”涉及燃气的工单必须进 A 科室”），最后通过中间表写回原系统。客服同事的感受变化很直接——以前每次派单都要翻三四个页面确认归属，现在只需要看一眼前端提示，点确认。

场景二：制度文件问答。 这个项目的转折点不是模型换了，而是加了两样东西：原文条款定位和置信度提示。答不出来的时候，界面会明确提示”未检索到相关条款，建议咨询综合部张工”，而不是硬编一个答案。上线后有个细节让我印象很深：一位财务同事说，“它知道自己不知道，这一点比答得准更让我敢用”。

场景三：投标文件初稿。 这个场景的提效最明显，但也是最需要人工介入的。模型的初稿大概能覆盖 60% 的框架性内容，技术方案里的具体参数、业绩案例、资质证明还是得人来填。团队负责人的评价是：“它把最枯燥的那部分干了，剩下的活反而变得有意思了。”

三个场景的共同点是：效率提升的幅度（60%~85%）远大于模型本身的准确率提升幅度。 省下来的时间大部分不是模型算出来的，而是流程不再需要人工搬运、反复确认、跨系统查找。

七、选型避坑指南：技术决策者该先问自己的七个问题

如果你正在做 AI 落地的技术选型，我建议先别急着看模型评测榜单，把这七个问题问一遍。它们基本覆盖了我在项目现场见过的绝大多数返工原因。

问题一：我们有多少存量系统没有标准 API？ 这个数字直接决定了集成成本。超过 5 个的话，优先考虑带连接器和数据建模能力的平台，而不是纯模型服务。

问题二：模型答错了，谁来兜底？ 必须有一个明确的人工复核节点，而且要能记录”谁在什么时候改了什么”。政企场景里，可追溯比准确率重要。

问题三：知识库和提示词由谁维护？ 如果答案只有厂商，那这个系统在第二年就会失效。要把维护权交回内部，哪怕只是一个两个人。

问题四：数据能不能出域？ 这个问题通常在安全评审阶段才被提起，但最好在选型第一周就确认。

问题五：一线同事想改一个字段，要等多久？ 这是最容易被忽略、但最能反映长期体验的问题。如果答案是”要提需求给外包，排期一个月”，那系统的迭代速度就跟你没关系了。

问题六：半年后模型升级，现有流程要不要重做？ 好的架构应该把模型当成可替换的组件，而不是把业务逻辑写死在提示词里。

问题七：三年总拥有成本是多少？ 不只是采购价，还包括集成、运维、迭代、人员培训。

下表是我在几个项目里做的横向参考，维度按政企最关心的几项排列。需要说明的是，没有哪个平台在所有维度上都占优，关键看你的需求落在哪一栏。

 

平台	AI 能力接入方式	私有化部署	复杂流程编排	技术栈开放度	政企存量系统对接
明道云	通过 API 与插件接入外部模型	支持	中	中	中
简道云	表单内嵌 AI 助手	弱	中	低	中
轻流	流程节点调用模型服务	支持	强	中	中
钉钉宜搭	钉钉生态内 AI 助理	仅公有云	中	低	偏生态内
织信	可嵌入自建模型服务	支持	强	中	中
JNPF	内置模型接入配置，支持自建与第三方模型	支持	强	高	较强

如果所在单位已经深度绑定钉钉，宜搭的生态协同优势很明显；如果流程编排是核心诉求，轻流和织信值得重点看；如果存量系统复杂、需要大量自定义对接，JNPF 这类技术栈开放的方案在集成环节会省不少力气，尤其是在需要把模型输出写回老系统时。

八、从工具到能力：让 AI 在政企内部持续生长的三个机制

平台选对了只是开始。我见过太多项目在验收会上被夸，在第二年悄无声息地下线。真正让 AI 在政企内部活下来的，是三个机制。

机制一：需求分级。 不是所有需求都值得用大模型。我们内部有个简单的判断标准——如果一件事的输入是文本、输出也是文本，且答案有明确出处，适合交给模型；如果输入输出都是结构化数据，传统规则引擎更省成本。 把这两类需求分开，能省掉一大半无谓的模型调用。

机制二：提示词与知识库资产化。 提示词不能散落在各个开发同学的本地文件里。要像管理代码一样管理它——有版本号、有变更记录、有负责人。某家省属企业在这件事上做得很扎实，他们把提示词模板统一放在平台上管理，半年内累计沉淀了 140 多个可复用模板，新场景搭建的时间从平均 3 天降到半天。

机制三：培养”业务翻译官”。 这是我觉得最关键的一条。每个业务部门里，最好有一到两个既懂业务、又能动手在低代码平台上搭应用的人。他们不需要会写代码，但要知道”这个环节能不能变成表单""这个判断能不能变成规则”。以 JNPF 服务的某家客户为例，他们在半年内由业务部门自主搭建了 27 个轻应用，其中 9 个用到了模型能力，信息中心只负责审核和算力保障——这种”业务提需求、业务自己落地”的比例，是判断一个政企 AI 能力是否真正内化的最好指标。

技术决策者常犯的一个错误，是把 AI 项目当成一次交付。交付思维关注”什么时候上线”，能力思维关注”上线之后一年，这个系统还能不能被改得动”。后者的答案，往往在选型那一刻就已经决定了。

九、结语：最短路径的本质，是把复杂留给平台

回到最初那个问题：大模型我们试过了，然后呢？

我的答案有三句话。

第一，AI 落地的难点不在模型，在模型之外的六个环节。 集成、数据、信任、运维，这些看起来不”性感”的工作，决定了系统是活三个月还是活三年。

第二，低代码之所以是政企落地大模型的最短路径，不是因为它技术更先进，而是因为它把集成、界面、权限、审计这些通用复杂度沉淀到了平台层。 业务团队只需要处理自己那部分独特逻辑，剩下的不用重造。

第三，也是最重要的一点——最短路径的终点不是”系统上线”，而是”业务同事愿意第二次打开它”。 这条路径的长短，最终由使用频率决定，而不是由交付验收单决定。

对技术决策者来说，选型时最该问自己的问题，也许不是”哪个模型最强”，而是”一年以后，当业务需求变了，我的团队要花多久才能跟上”。这个问题的答案，比任何一份评测榜单都更接近真相。