最近不少团队来问我同一个问题公司大模型账号都买了内部也搭了一两个智能问答机器人为什么业务部门用了一周就不爱用了聊下来发现问题几乎都出在一处——AI是AI业务是业务两者始终没长在一张皮上。真正把 JNPF 低代码平台和 AI 大模型打通的团队反而悄悄把 AI 嵌进了报销、合同、工单、巡检这些最脏最累的流程里让 AI 在表单上自动填字段、在审批节点上出预审意见、在知识库里检索制度条款。这篇就是我最近在一家制造企业里跑完一整套落地的完整复盘从架构设计、集成方式到每一个流程节点的配置参数尽量把能抄作业的部分都摊开讲。1. 为什么聊天问答不是终点AI必须长在流程里1.1 企业真正需要的不是对话框而是“带手带脚”的AI先把一个观念掰扯清楚聊天问答型AI在企业里之所以容易沦为摆设不是模型能力不行而是交互方式天然断层。员工在对话框里问“差旅报销标准是什么”AI答得再准确员工还是得切回报销系统打开一张空白单据把姓名、部门、事由、金额、发票信息一项一项敲进去然后对照刚才的答案判断哪些能报、哪些超标。整个过程里AI提供的只是一个“参考”所有搬运动作还得人肉完成省下来的时间非常有限。真正让业务部门觉得“这玩意儿有用”的是把AI直接从对话框里拿出来塞进他每天要用的那张表单和那条审批链里。比如员工提交报销单时把发票拍照上传AI自动识别发票抬头、金额、税号按公司差旅制度判断是否超标再在单据上填好建议报销金额、标记异常项审批人打开单据时直接看到“AI预审意见”。这种形态下AI不再是需要用户主动去找的工具而是业务过程的一部分用户不用思考“我要不要问AI”流程自己就把AI的能力调用了。所以说判断一个AI场景成不成熟先不要问“模型能不能答对”而要问“AI的产出能不能直接落回系统里的字段和节点”。如果能这个场景就值得投入如果不能那大概率做出来又是一个七天热度就过的聊天机器人。1.2 JNPF这类低代码平台为什么是AI落地的天然承接者为什么我会拿JNPF来当落地的底座因为低代码平台天然已经替你把AI落地最麻烦的地基打好了。做AI嵌入流程最核心的三件事一是有地方接数据二是有地方跑流程三是有地方渲染交互。单独的模型API调用做得再漂亮也解决不了“数据从哪来”“审批流怎么走”“结果怎么展示”这三件事而这些恰恰是低代码平台的看家本领。JNPF内部那套数据模型把每张业务表单的字段、类型、关联关系都数字化了流程引擎则把审批链路的节点、条件分支、会签驳回规则都固化了表单引擎又提供了现成的页面渲染。我要做的只是开一个接口让AI服务能读到当前单据的字段值能调起流程引擎的动作能把结果回填到对应字段里。这个过程不需要重写系统也不需要专门的AI平台团队在低代码平台里做配置和少量脚本就能打通。更关键的是权限体系。AI一旦开始读写业务数据最怕的就是越权。JNPF这类平台本身已经做了用户、角色、数据范围的控制AI服务只要在设计时遵循“拿当前用户上下文中的数据”天然地就继承了这套权限边界。这比你在外面单独搭一个AI应用再去对接权限系统要安全得多也省事得多。1.3 我见过的高价值场景清单真正适合AI嵌入全业务流程的场景通常具备四个特征高频、重复、规则边界清晰、数据可结构化。高频决定了收益够大重复决定了AI能持续产生价值规则清晰决定了模型不容易胡说数据可结构化决定了结果能落回字段。我最近落地的几个场景分别是报销审批预审、合同条款初筛、客服工单分类与转派、设备巡检异常识别、制度文档问答。这几个场景几乎都长在企业最痛的地方而且不需要AI做完全开放式的创作只需要它在有限约束里做判断和提取。不太适合一上来就做的场景我也踩过坑比如完全开放式的新品创意文案、没有标准答案的战略分析、涉及多方责任认定的复杂客诉。这类场景不是AI做不到而是结果没法用字段和节点去收敛容易变成人工审核地狱。我的建议很直接第一批场景宁可选窄一点、无聊一点、重复度高一点先把闭环跑通再逐步往有创造性的场景延伸。2. 先把集成骨架搭好AI服务与JNPF的对接原理2.1 大模型不是数据库接入前先想清楚接口形态很多人第一次接大模型都习惯在前端页面里直接调模型SDK页面渲染出来一个输入框用户输一段话模型返回一段话完事。这样做演示很爽但真到了业务流程里完全走不通。企业里的AI能力必须统一收敛到后端服务由后端统一封装成“AI服务接口”JNPF的表单、流程节点、定时任务都通过这个接口来调用前端不与大模型直连。这背后有几个很现实的原因。第一是密钥管理大模型API的Key如果散落在前端代码或每个开发者的本地配置里泄露风险极高统一收敛到后端服务之后Key只在服务端出现。第二是租户隔离和数据审计通过统一网关转发请求时可以记录每一次调用的业务单据号、调用人、调用时间、输入输出摘要出问题时有迹可循。第三是Prompt模板可以集中沉淀不要每个流程节点各自拼Prompt而是让AI服务提供不同的“能力方法”——比如“单证识别”“合同审查”“工单分类”——每个方法内部封装好提示词和返回格式。接口形态上我一般分两种同步短任务和异步长任务。像表单字段提取、文本分类、数据校验这类1到3秒内能返回的直接走同步接口业务方等待结果像多页合同完整审查、大批量文档对比这类可能要跑十几秒的必须走异步接口加回调通知不能让用户在页面上干等。这一步的取舍会直接影响后面的用户体验千万别在架构上省事。2.2 数据模型设计让AI能读到业务上下文AI嵌入业务流程最大的坑不是模型不会答而是模型“看不到”上下文。你跟模型说“请审查这份合同有没有延期风险”结果传给它的只有合同正文没有合同类型、签约方、金额、付款条件、相关制度条款模型就只能瞎猜。所以在JNPF里做AI落地第一步往往是梳理数据模型弄清楚一个表单里有哪些关键字段需要喂给模型。我的做法是给每个需要AI的业务对象建立一张“AI数据集视图”。比如报销单的AI数据集包括费用类型、发票金额、发票代码、申请部门、预算科目、报销制度摘要合同审查的AI数据集包括合同名称、对方单位、合同金额、履约期限、付款方式、法务模板编号。这张视图不直接搬整张业务表而是只暴露AI必要的最小集合既减少Prompt长度也降低敏感数据泄露面。字段命名也要做规范化改造。低代码平台里老表单的字段常常是“f_1724829123”这种编号命名直接把原始字段名丢给大模型它根本不知道是什么意思。我用了一个很笨但很有效的办法在AI服务调用前写一层字段映射把业务字段翻译成语义化名称比如把f_1724829123映射成“发票含税总金额”。这层映射看起来不起眼但对最终准确率的提升非常明显。2.3 Prompt模板、函数调用与参数设置Prompt模板不要散落在代码里我建议全部放到AI服务的配置中心同时配合JNPF的平台配置项做成可维护的版本。每个能力方法的Prompt都固定三段式角色设定、输入数据说明、输出格式约束。角色设定告诉模型它是什么比如“你是企业差旅报销审核助手”输入数据说明把前面AI数据集视图里的字段用JSON格式传进去输出格式约束用JSON Schema来限定模型只返回结构化字段不允许自由发挥。函数调用Function Calling这块我强烈建议用上它特别适合需要AI主动获取数据的场景。比如审批流程里需要AI判断“当前单据是否超出预算”可以把读取预算科目余额、读取近期同类申请记录封装成函数让AI在推理过程中自己决定要不要调用这些函数。这样做的好处是不用把所有数据都塞进Prompt里AI按需取数上下文长度可控准确率也更高。参数设置我有几个默认经验值纯结构化提取任务温度调到0.1到0.2几乎不给模型发挥空间文本摘要类任务温度0.3左右面向员工的开放式问答温度0.7。max_tokens一般设1024足够合同审查这类长文本输出就调到2048以上。别小看这些参数同一个模型在报销单据提取任务里温度从0.7降到0.1字段提取准确率能提高不少因为高温下模型会忍不住“脑补”内容。3. 三个业务场景的深度落地实录3.1 智能报销审批从发票识别到预审意见我落地最成功的一个案例是报销审批助手。原来的流程是员工填单、上传发票、领导人工核对发票真伪和制度合规平均一单审批要花两到三天财务还把大量时间耗在重复核对上。改造之后的流程是这样的员工在JNPF报销表单里上传发票图片表单触发后端AI服务先调OCR接口识别发票要素再把识别结果交给大模型做结构化提取和合规判断最后AI把结果回填到表单的预审字段里。流程配置上我在JNPF里新建了一条“报销AI预审”流程第一个节点是“附件上传触发”接到上传事件后调用AI服务接口表单上新增几个只读字段AI识别金额、AI风险标记、AI预审建议。第三个字段其实就是大模型生成的一段话比如“该发票金额1280元超出部门单次报销标准1000元建议按1000元报销超标部分需补充分管领导审批”。审批人打开单据时第一眼看到的就是这段预审建议不用再一张一张看附件。这里有一个细节很关键AI的业务结果和规则引擎的判断要做双重校验。大模型负责识别和语义理解但“是否超标”这种事我建议同时用低代码平台的规则引擎跑一遍硬逻辑两边都通过了才放行任一环节异常就直接打回人工。不要把所有判断都押在模型身上模型偶发的错误是不可避免的规则兜底能帮你把错误率再砍下去一个数量级。3.2 合同AI预审嵌入流程节点的风险扫描合同审查是个典型的“看起来很美、落地很痛”的场景。合同文本长、条款复杂、业务又不敢完全放权给AI所以我没有直接做“AI自动通过”而是做“AI预扫描人工决策”。在JNPF合同审批流程里上传合同附件后触发审查服务AI按风险类别输出一套结构化结果合同相对方是否存在异常、付款条款是否偏离模板、履约期限是否过长、违约责任是否缺失每一项都给出“正常/关注/高风险”的标签和一句解释。功能实现上我把合同模板和常见风险规则做成了两个输入源一是合同全文二是公司法务模板库的相关条款。AI审查时会把合同条款和模板条款做对比差异点逐个列出。这个场景的Prompt输出格式我用了严格的JSON Schema模型只允许返回风险项数组每项包含风险类型、原文引用片段、风险说明、建议动作。因为做了结构化返回JNPF流程节点就能直接把风险项渲染成列表法务可以逐条确认。我特别想提醒的是合同AI预审永远只能做初筛不能做终审。我在流程上设置了硬性约束只要AI标记出任一高风险项流程必须转给法务岗人工复核只有全部风险项为“正常”且金额在一定阈值以下的合同才允许走简化审批路径。这套“AI筛、人决定”的机制才是业务方敢用的关键不要想着一步到位做全自动合同审核。3.3 企业知识库问答与工单辅助知识库问答我做的不是又一个独立聊天机器人而是把AI问答嵌进了JNPF的门户和工作台。员工在系统里收到一个问题想找答案时不用切到其他工具直接在门户搜索框输入问题系统返回的不只是检索命中列表而是一段基于企业制度文本生成的摘要回答并且每段回答都附了引用来源的制度条目链接。实现上用RAG方式先把制度文档拆成段落做向量化存进向量库提问时检索相关片段再拼上下文让大模型生成回答。工单辅助场景我做了两个功能自动分类和智能推荐处理人。原来客服收到用户报障要人工判断是网络问题还是账户问题还是设备问题再转给对应的二线团队。现在AI在工单创建时自动读取描述、分类打标、提取紧急程度字段并推荐处理组和处理优先级。这个功能看起来很简单但因为它嵌在工单创建流程里客服每天要操作几十上百次每次省下两三次点击和思考时间一个月累计下来的效率提升非常可观。RAG落地的最大心得是向量化之前的文档清洗比模型选择更重要。企业里的制度文档往往有大量重复段落、过期版本、扫描PDF、错别字不洗干净就直接切片检索出来的片段质量一定很差。我花了将近一半的时间在整理制度库包括统一格式、删除旧版、拆分长段落、给段落打上来源和生效日期标签这部分功夫做足了后续的准确率才有保障。4. 不得不踩的坑超时、幻觉、权限与成本4.1 大模型响应慢别让用户干等业务流程里的AI调用最怕的不是回答不准而是“转圈圈”。用户提交一张报销单等了15秒AI还没返回他立刻会觉得系统坏了。我处理这类问题有四个办法第一能短则短结构化提取类任务尽量用轻量模型控制在1.5秒内返回第二用流式输出长文本结果前端逐步渲染用户体感上等待时间会短很多第三异步任务加完成通知合同审查这种长任务提交后先给用户一个“处理中”状态完成后推一条站内消息第四高频查询做结果缓存同一个问题、同一份合同短时间内重复提交直接返回上次结果不重复烧钱。4.2 幻觉是最麻烦的敌人用规则兜底做AI嵌入业务最怕的就是模型一本正经地胡说八道尤其是在金额、日期、合同条款这类不能错的字段上。我的原则是凡是可以通过规则计算验证的字段绝不允许模型输出作为唯一依据。金额是否超标、日期是否在有效期内、编号是否符合格式这些在低代码平台里都能用规则引擎写死AI只负责识别和解释规则引擎负责判定两边不一致时以规则引擎为准并进行异常标记。对于真正需要模型语义理解的输出我用三层约束第一层Prompt强制要求模型只基于给定上下文回答不允许补充外部知识第二层输出格式限定为结构化JSON关键字段枚举化比如风险等级只能取值“正常、关注、高风险”让模型在封闭集合里做选择第三层高风险场景保留人工复核节点AI永远只是预筛。这三层下来幻觉对业务的实质影响基本可以控制在一个可接受的范围。4.3 权限与数据安全AI不能绕过原有管控AI嵌入流程以后数据安全问题会被无限放大。你让AI读报销单那它能不能读到别人的报销单你让AI查合同模板库那不同事业部的合同权限如何隔离我的经验是AI服务封装时必须把当前操作人、当前租户、当前单据ID一起传进来后端根据这些参数做数据过滤只把当前用户有权访问的字段打包给模型。一句话AI只是替用户在系统里读数据它的权限边界要和用户本身保持一致绝不能成为绕过权限的隐蔽通道。敏感数据我默认不进模型上下文比如身份证号、银行账号、发票代码这类字段在拼接Prompt前先用脱敏逻辑打码模型返回的结果只保留业务判断。所有AI调用日志我做了一周留存记录请求人、单据号、调用时间、输入输出摘要虽然会增加存储成本但真出了内部审计问题这套日志能救你命。4.4 成本失控与性能衰减别让每笔请求都烧钱大模型按Token计费企业流程每天成千上万次调用成本问题绕不开。我的做法是“分级模型策略”简单任务比如发票要素提取、工单分类用便宜的小模型就能搞定成本只有大模型的十分之一只有合同审查、复杂推理这类任务才调用大模型。再加上字段瘦身AI数据集视图只暴露必要字段多一个字段就多一份Token成本。性能衰减这个问题很少有人提前预警但很重要。同一个Prompt模板用久了以后模型输出质量会缓慢下降尤其是外部模型升级、服务商调整参数之后你之前调的阈值可能就没那么准了。所以我建议建一个基准测试集放三五十条典型单据每两周跑一遍对比准确率、字段提取完整性、格式合规率这几个指标发现衰减及时调模板或换参数。5. 落地后的度量与组织推广5.1 用数据说话怎么评估AI嵌入流程的真实收益企业内部做项目最忌讳的是上线之后只有一个“体验不错”的评价拿不出硬数据。我在试点阶段就定了几项核心指标上线一个月后直接拿前后对比说话单笔报销审批时长从原来平均41小时降到了18小时合同审查初筛环节从人均10分钟降到了2分钟法务真正需要逐条复核的合同量只有原来的四成工单分类准确率在连续修正十几次Prompt后稳定在94%上下转派错误率从15%降到了5%以内。这些数据里我最看重的不是“AI准确率多高”而是“人工处理时长降了多少”。AI嵌入流程的唯一价值是把原来需要人肉完成的步骤自动化掉不体现在流程指标里的AI做得再好都没有意义。每上线一个AI能力我都会让实施团队把前后流程节点的人工耗时重新拉一遍用分钟数说话业务方自然服气。5.2 组织推广别让业务部门把AI当成IT部门的玩具再好的技术方案推不动也是白搭。我踩过最大的坑是自己闷头把功能开发完然后让业务部门“体验一下”结果没人用。后来换了打法每个AI能力上线前先找一两个愿意尝鲜的业务骨干做种子用户让他们参与提需求、试错、反馈他们用出感觉之后再由他们在部门内分享实际使用体验比IT部门去宣讲好用得多。试点场景的选择也要讲究策略不要一上来就挑战最复杂的合同审查。我建议先从“员工自己受益最直接”的场景切入比如报销填单快了、工单转派准了业务人员能立刻感受到好处配合度就高。项目组成立了一个三人混合小组业务出一个人梳理规则和数据IT出一个人做接口和流程配置再加上一个懂Prompt的AI工程师每周花半天时间过一遍反馈把准确率一点点磨上去。这种节奏看起来慢但三个月以后业务部门会真的把AI当作自己工作流里的一部分而不是IT部门送来的一件新鲜玩具。我自己跑完这一遭最大的感受是AI在低代码平台上的价值从来不是把对话框做得更聪明而是把AI变成每个流程节点上默认可用的能力。比起追求一个“什么都能聊”的助手把两三个高频场景里AI的准确率打磨到95%以上让员工每天自动用到十几次带来的体感差异会非常明显。如果你也想从零开始我建议先别铺太开挑一个流程最长、录入最重、业务最痛的点用两周时间把一整套闭环跑通再谈规模化复制。