ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

低代码+AI:把大模型嵌入业务流程,让智能表单与审批流真正跑起来

低代码+AI:把大模型嵌入业务流程,让智能表单与审批流真正跑起来 我见过太多企业上AI的场景了花几十万分卡接入大模型做一个聊天问答框挂在官网或企微群里。两周之后除了几个好奇的同事试过几次几乎没人再用。问题不在AI不够聪明而在于AI没有真正“长”在业务里。这次我想聊的是JNPF低代码平台结合AI之后我怎么把AI从聊天框里拽出来塞进企业真正跑业务的地方——表单录入、审批流、工单处理、数据报表——并且跑出看得见的效果。如果你正在评估低代码AI落地或者已经在用JNPF但只做了个问答机器人这篇的内容应该能帮上忙。1. 先别急着做聊天机器人AI进业务流程的真正姿势很多团队上AI的第一反应是做问答因为这是最容易演示、最不容易出错、领导看了也开心的功能。但站在业务视角看问答本质上是一个“知识获取”动作它没有改变任何业务数据没有触发任何流程节点也没有留下可追踪的纪录。员工问完AI“离职流程怎么走”该填那张表单还得去填该等哪个环节审批还得去等AI只是把百度搜索变成了对话框效率提升非常有限。1.1 为什么“对话式AI”在企业里容易烂尾烂尾的原因我总结下来有三个。第一知识库更新不及时。AI答得很自信但引用的还是半年前的制度版本业务部门被误导几次就再也不信它。第二和操作闭环脱节。问完流程不能直接发起流程问完订单状态不能直接进入处理页面用户得出答案之后还要重新登录业务系统操作一遍体验反而更繁琐。第三效果无法量化。问答机器人带来的价值很难写成汇报PPT你只能说“月活跃用户多少”但说不清“它帮公司省了多少钱、压缩了多少流程时长”。低代码AI的正确姿势恰恰是把AI放到业务流程的节点上——不是让用户来找AI而是AI在业务流转过程中自动出现在表单提交前帮忙清洗数据在审批前给出风险提示在工单创建时自动分类分派。用户甚至感知不到AI的存在但流程明显变顺了这才是嵌入式的价值。1.2 JNPF这类低代码平台给AI交付了什么底座JNPF这类平台真正帮上忙的地方不是AI本身而是它提供了AI可以“动手操作”的底座。模型再聪明没有触达数据、执行动作的通道就只是个嘴替。低代码平台恰好把这几件事做完了可视化表单建模让数据结构化AI能读能写工作流引擎让AI节点成为流程的一环AI的输出可以直接驱动下一步流转细粒度的权限体系保证AI只能碰它该碰的数据操作日志和审计能力让每次AI行为都可追溯。我习惯用一个类比大模型是大脑低代码平台是神经系统业务系统是手脚。大脑想清楚了得靠神经系统把信号传到手脚上执行。没有神经系统大脑再发达也只是个关在罐子里的标本。JNPF这类平台做的就是神经系统这件事——把AI的决策能力连接到具体的业务动作上。这也是为什么我一直强调AI落地不要从模型开始而从流程梳理开始。2. 梳理业务流程里的AI嵌入点哪些环节最适合让AI接手在实际项目里我不会一上来就问“哪些地方能用AI”这个问题太发散容易变成全面开花、全面平庸。我一般反过来问哪些环节又高频、又重复、又有明确规则但规则里带一点判断这类环节最适合AI介入。2.1 表单录入从人填表到机器填表表单录入是低代码系统里最基础也最消耗人力的环节。一个典型的例子是供应商建档业务员收到合作方的营业执照、开户许可、资质证书要手工把公司名称、统一社会信用代码、法人、开户行、账号一个个填进表单一家供应商至少二十分钟还容易填串位。这种场景非常适合AI嵌入。做法是让AI读取上传的图片或PDF自动抽取结构化字段回填到JNPF表单对应组件里。关键不在于“识别文字”本身OCR早就能做难的是字段语义映射——哪一行是公司名称哪一行是开户行地址怎么拆分。大模型的文档理解能力在这里明显比传统OCR更稳。填完之后保留“人工确认”这一步业务员只需要扫一眼有没有识别错误而不是从零录入。这个改动看起来不起眼但在客户多、供应商多的企业里节省的时间非常可观。2.2 审批流AI做预审而不是代替审批审批流是低代码系统应用最广的模块也是AI最容易“显灵”的地方。我接手过一个采购审批场景每笔采购申请都要经过部门负责人、财务、分管副总三级审批每级都要重复阅读申请理由、比价情况、预算占用平均一个单子要两三天才能走完。我给AI定位的角色不是“审批人”而是“审批助手”。它做三件事把冗长的申请材料压缩成一页摘要标注出与历史订单的异常点比如同一供应商连续涨价、预算占比突然升高再给出合规性提醒。审批人打开待办时先看AI摘要再决定是否展开详情决策效率明显提升。需要特别强调的是AI只做预审和建议最终审批动作仍然由人来点这样既保效率也保责任边界。2.3 知识密集场景文档问答和制度检索企业里总有大量非结构化知识制度文件、操作规程、历史方案、售后案例。躺在共享盘里吃灰用的时候搜不到。JNPF的模型不是要取代文档系统而是把文档系统盘活。落地方式是企业知识库问答把制度文档接入后台做切片和向量化再通过检索增强生成RAG让AI基于库里内容回答员工问题。员工问“年假余额是怎么计算的”AI引用制度原文回答并给出原文出处。这里面最关键的细节是必须带引用溯源否则AI一旦编造制度依据比没有AI还危险。我通常在知识库问答的回复模板里强制加入“参考文档链接”字段AI必须回答依据来源才能展示答案。2.4 数据报表与异常解读JNPF自带的报表能力可以统计业务数据但“看报表”和“读懂报表”是两回事。老板真正想问的是这个月华东区回款为什么下滑华南区新增客户里哪个行业增长最快这类问题在传统报表体系里要靠数据分析师临时写SQL在低代码AI体系里则可以把语义层开放给AI让AI把自然语言转换成查询条件再返回数据结论甚至异常归因。这一块落地门槛比前面几个场景高因为报表口径直接关系到管理决策口径错了会得出完全相反的结论。我的建议是先圈定几个固定口径的高频看板比如销售回款、库存周转、工单完成率把口径写成固定说明喂给AI禁止AI自由发挥口径定义。AI负责描述“是什么”人负责决定“怎么办”这个边界必须守住。3. 实操在JNPF里把AI能力挂到流程节点上理论聊得再多不如动手配置一遍。下面我按实际项目中的操作顺序拆解在JNPF里把AI能力挂到流程节点上的四个关键步骤。不同版本的JNPF界面位置可能有差异但底层逻辑是一致的。3.1 第一步模型接入与统一网关JNPF接入AI能力通常是通过配置大模型API来实现。在平台的后台管理里找到模型配置入口填入API的Base URL、密钥和模型名称完成连通性测试。这里我的建议是做一个统一模型网关而不是每个应用各接各的。统一网关解决两个问题一是密钥不散落安全可控二是可以做模型路由。我用过两条路线的模型同时接进来的方案——轻量任务走响应快、成本低的小模型复杂推理走更强的旗舰模型。判断依据可以是任务的复杂程度也可以由用户在流程节点里手动指定。在实际项目里我把表单字段提取这类结构化任务固定走小模型把合同风险分析这种长文本推理走旗舰模型半年下来token成本省了一大截效果也没变差。3.2 第二步做一个智能填单节点在JNPF表单设计器中给目标表单新增一个“AI辅助填写”的触发按钮或者在某个字段上绑定“失焦后自动识别”事件。触发后把当前表单已填内容和其他相关上下文传给模型让模型按预设的提示词生成结果再回填到对应字段。这里最考验的是提示词设计。我以供应商建档为例给你一个参考模板你是一个企业信息录入助手。根据用户上传的证件图片识别结果提取以下字段并严格输出JSON格式 { company_name: 公司全称, credit_code: 统一社会信用代码, legal_person: 法定代表人, registered_capital: 注册资本, address: 注册地址 } 注意事项 1. 如果某个字段识别不出来填null不要推测 2. 地址要完整保留不要省略“省市区” 3. 输出必须是合法JSON不要包含多余文字。提示词里要求JSON输出是为了让JNPF的字段映射组件能直接把结果解析进表单控件。这个设计有个隐藏好处结构化的失败可以被程序捕获。如果AI返回的不是合法JSON系统可以抛出“识别失败请手动填写”的提示而不是把一段胡言乱语填进表单。3.3 第三步审批流里加一个AI辅助节点在流程设计器中找到需要AI介入的审批节点在审批流转前增加一个“业务操作”类型的节点一般叫“调用外部接口”或“执行动作”在这个节点里挂上模型调用。我的习惯是让AI节点输出结构化审批建议格式类似{ summary: 摘要说明, risk_points: [风险点1, 风险点2], compliance_check: 合规性判断, suggestion: 建议通过 / 建议驳回 / 建议转人工, confidence: 0.82 }把这五段内容渲染到审批人的待办详情页审批人可以在10秒内完成判断。这里我强烈建议在流程里再设计一条动态路由当AI的confidence低于某个阈值比如0.6自动把单子转给上一级有经验的主管人工复核而不直接进入常规审批链。这种做法既不耽误正常单子的速度又不会放过AI拿不准的单子是“机器人工”混合模式里我认为最实用的一个设计。3.4 第四步搭一个企业知识库问答应用知识库问答在JNPF里的落地通常需要三个组件配合文档管理、向量化服务和问答页面。先把企业制度文档、操作手册、历史工单上传到文档库然后对文档做切片处理切片的粒度很关键。我踩过坑切得太粗检索出来的片段带着大量无关内容AI回答容易跑偏切得太细语义被切断检索召回率下降。目前我常用的策略是按标题和段落结构切单段控制在300-500字重叠部分留一两句保留上下文。向量化服务可以用平台内置能力也可以单独部署。检索时先把用户问题向量化再在向量库里做相似度检索把命中的原文段落连同问题一起交给大模型生成答案。最后在问答页面上展示引用来源让员工点开链接核对原文。4. 进阶玩法多AI协作与Agent化编排单点AI节点解决的是单个环节的效率问题真正让业务流程发生质变的是把多个AI按业务规则编排成一条工作流——也就是现在常说的Agent化。在低代码平台里这个思路可以用“流程多分支子流程事件触发”来实现不需要写复杂框架。4.1 从单点AI到多角色Agent工作流拿合同评审举例。一份合同进来牵扯到法务、财务、业务三个角色三种关注点完全不同。传统方式是一份合同逐级流转三个人看光排队就得等几天。Agent化之后的流程可以这么设计合同一上传同时触发三个AI子流程——法务AI审查条款风险财务AI核对价格与预算业务AI确认交付条件。三个AI并行干活干完汇聚结果再按综合规则决定是自动通过、退回修改还是转人工评审。这样做的好处不只是快而是每个专业维度都被无遗漏地检查了一遍。人在疲劳时会漏看条款AI不会只要提示词里把检查清单列全它每条都会过一遍。这就是多AI协作在业务流程里最典型的价值。4.2 三种编排模式按业务性质选型我在实际项目里总结出三种最常见的编排模式。第一种是串行流水线上一个AI的输出是下一个AI的输入适合加工链路明确的场景比如“合同文本→提取关键信息→核对预算→生成审批意见”。第二种是并行汇聚多个AI同时处理同一个任务的不同维度最后合并结果适合合同评审、供应商尽调这类多专业并行审查的场景。第三种是动态路由前一个AI判断当前单子的类型再决定调哪个后续流程适合工单分类分派。这三种模式在JNPF里都能落。串行和并行靠流程分支和汇合节点动态路由靠条件分支节点在AI输出结果中配置流转条件。选定模式前先问自己一个问题这个业务环节专业知识是不是分了好几块如果是一块知识串行就够了如果是多块知识互不依赖并行就是最优解。4.3 Agent失败时的降级与人工接管多AI协作意味着链路变长链路变长的代价是出错概率增加。我见过一个团队把采购审批做成五个AI节点串联上线第一天就发现第三个节点的模型接口超时整条流程卡死采购单提不上去业务部门电话直接打到CIO那边。所以在做Agent化编排时我给自己定了一条铁律每一个AI节点后面都配一个降级方案。超时或解析失败时自动跳过AI节点把单据按默认路径流转并打上“AI未处理”的标记重要的节点可以设置“转人工处理”分支把待办推给对应人员。宁可让流程回到传统的纯人工模式也不能因为AI故障阻塞业务。低代码平台的事件监听和异常分支就是为这种兜底场景准备的配置成本很低但关键时刻能救命。5. 真实落地中的避坑清单与成本账这一节都是钱买来的教训每一条都对应一个真实翻车现场。5.1 数据安全先过权限再过模型AI接入业务数据之后最大的风险不是模型不够聪明而是数据越权。JNPF本身有完善的权限体系但在对接模型时很容易出现一个漏洞表单数据取数时用的是后台服务账号这个账号如果有全表权限AI就等于拿到了一把万能钥匙什么数据都能读出来送进模型。我的做法是双重收口。第一重给AI调用单独建一个专用账号权限只开到这个节点最低需要的数据集第二重请求模型之前做脱敏处理身份证、手机号、银行卡、地址等敏感字段先打码再传输。如果数据合规要求高可以考虑私有化部署开源模型把数据彻底留在内网。安全和效率的平衡点不是靠口号喊出来的是靠权限设计和脱敏策略撑出来的。5.2 成本账该怎么算模型调用费是持续性支出不做估算就上线的项目多半会在第一个月的账单面前傻眼。我给出的估算公式很简单单次任务平均消耗token数乘以日均调用次数再乘以吨token价格再乘以30天。以一个审批辅助节点为例每次请求包含申请内容、历史记录、提示词大约消耗2000-3000 token按当前主流API价格粗算一天500次调用一个月成本在数千元级别。想压成本有两个思路一是任务分级简单字段提取走便宜的小模型复杂分析才走旗舰模型二是缓存复用相同或高度相似的请求直接命中缓存不回源调模型。在JNPF里可以针对数据变化频率低的场景把AI结果存到冗余字段中数据没变就直接读变了再触发重新计算。这一招对知识库问答类应用的降本效果非常明显。5.3 AI输出不可靠时的人工兜底设计AI一定会出错这不是概率问题是时间问题。关键是出错时要能被发现、被拦截。我在所有AI节点上都加了三层校验。第一层是格式校验要求AI输出JSON并做schema校验字段缺失或类型不对直接判失败。第二层是业务规则校验比如审批建议和风险点数量不能同时为空金额字段必须大于零。第三层是可信度拦截AI自报置信度低于阈值的单子自动转人工。这三层兜底设计做完AI节点才敢真正挂到生产流程里。5.4 怎么证明这套东西真的有价值项目做了半年老板问得最多的问题就是这堆AI配置到底省了多少事说不清楚就等于白干。我习惯在项目启动第一天就把三个指标埋好单笔流程平均处理时长、一次性通过率、人力工时投入。上线前跑两周基线数据上线后再跑一个月用前后对比说话。我之前在一个售后工单场景里测出的数据是工单分类准确率从人工的78%提到AI辅助后的93%平均工单分配时长从35分钟压到5分钟以内人工复核比例控制在20%以内。这种数据摆出来不需要你解释什么叫低代码AI老板自己就知道下一步该扩大哪些场景。真要说做这类项目最大的经验反而是克制。不要想着把AI铺满每个流程先找一两个高频、重复、规则半清晰半模糊的痛点用JNPF把AI节点跑起来让人工兜底盯两周把准确率数据收集齐再复制到其他部门。我踩过的坑基本都是贪多嚼不烂一次性铺开太多场景AI节点出了问题都分不清是哪一环掉的链子。如果你也在评估低代码AI能做什么不妨从单个表单字段的自动回填开始先让业务部门感受到一次“AI不是在聊天而是真在干活”后面铺开就容易多了。
返回列表