1. 为什么“聊天问答”只是低代码AI的冰山一角很多团队第一次接触低代码平台里的AI能力基本都停留在“对话框里问一句、它答一句”的阶段。表单怎么建、流程怎么配、报表怎么拉还是靠人手一步步点。结果就是AI像个外挂的客服跟真正的业务系统是两张皮。我去年帮一家做供应链的客户做内部系统升级时他们的技术负责人跟我说得很直白“我们试过好几个带AI的低代码工具最后都变成给员工配了个聊天窗口业务该多慢还是多慢。”这句话点到了要害。低代码平台的价值本来是把“业务逻辑”从代码里解放出来让懂业务的人能直接搭系统AI的价值则是把“判断和生成”从人脑里解放出来让系统能自己处理模糊信息。这两件事如果只在对话框里碰一下等于两个能力都没发挥出来。真正有价值的做法是让AI深度嵌入到业务流程的每一个节点里——表单填写时自动补全、流程审批时自动预判、数据录入时自动校验、报表生成时自动归因。JNPF这套低代码平台我前前后后用了两年多从最早的纯表单流程版本到后来接入AI能力再到最近这版把MCP协议和Skills机制打通变化非常明显。它现在能做到的事情已经远远超出“聊天问答”的范畴。举个最直观的例子以前做一个采购申请流程员工要手动填供应商、物料、数量、预算科目填错了到审批节点才被打回来现在AI可以在员工刚输入物料名称的时候就根据历史采购记录和当前库存自动带出推荐供应商、参考单价、预算余额甚至在提交前就提示“这个供应商上次交货延期了三天要不要换一家”。这篇文章我想聊的就是这套东西怎么落地。不是讲概念是讲我实际搭过的流程、踩过的坑、调过的参数。适合两类人看一类是正在选型低代码平台、想知道AI到底能嵌到多深的技术负责人另一类是用过JNPF但只停留在表单流程层面、想把AI用起来的实施人员。我会从整体设计思路讲到具体配置再到问题排查尽量把每个环节的“为什么”说清楚。2. 整体设计思路AI不是插件是流程里的一个“岗位”2.1 从“外挂对话框”到“流程节点”的认知转变大部分低代码平台接入AI的方式是在界面右上角放一个悬浮按钮点开是个聊天窗口。这种设计的问题在于AI和业务数据之间隔着一层“人”。员工要把业务数据复制粘贴到对话框里AI给出建议后员工再手动填回表单。这个过程中AI没有直接读写业务数据的能力它只是一个更聪明的搜索引擎。JNPF这版的做法不一样。它把AI能力封装成了流程引擎可以调用的“节点”。什么意思呢就是在你画流程图的时候除了传统的“审批节点”“条件节点”“抄送节点”还多了一类“AI处理节点”。这个节点可以读取上游节点传过来的数据调用大模型或者本地Skills进行处理然后把结果写回流程变量供下游节点使用。这个设计思路的转变很关键。AI不再是一个需要人主动去“问”的东西而是流程走到某个环节时自动触发的“岗位”。就像公司里有个专门负责审核发票的财务流程走到报销环节单据自动流转到他桌上他处理完再往下传。AI节点扮演的就是这个角色只不过它处理的是那些规则明确但需要判断力的任务。2.2 MCP协议在中间扮演了什么角色这里要解释一下MCP。MCP全称是Model Context Protocol是一个让AI模型和外部工具、数据源之间建立标准化连接的协议。你可以把它理解成“AI世界的USB接口”——不管对面是数据库、文件系统、还是某个业务系统的API只要按MCP规范封装好AI就能直接调用。在JNPF的架构里MCP主要解决两个问题。第一是数据接入的标准化。企业的业务数据散落在ERP、CRM、OA、甚至Excel文件里以前要让AI用上这些数据得一个个写适配代码。现在只要把这些数据源封装成MCP ServerAI节点就能通过统一的方式读取。第二是工具调用的标准化。比如AI需要查库存、算价格、发通知这些操作以前要写死在代码里现在可以封装成MCP ToolAI根据上下文自己决定调哪个。我实际用下来MCP最大的好处是“解耦”。业务系统的开发人员不需要懂AI他们只需要把业务能力按MCP规范暴露出来AI这边的调优人员也不需要懂业务系统的内部实现只需要知道有哪些MCP Tool可用。两边可以并行开发最后在流程里汇合。2.3 Skills机制让AI学会“公司内部的做事方式”Skills这个词最近很热但很多人理解得比较窄以为就是给AI写一段提示词。在JNPF的语境里Skills是一套可复用、可组合的“能力包”。一个Skill包含三部分触发条件、处理逻辑、输出格式。举个例子我帮客户做了一个“供应商风险评估”的Skill。触发条件是流程走到采购审批节点且金额超过5万处理逻辑是调用MCP Tool查询该供应商的历史交货准时率、质量退货率、当前合作状态然后让大模型综合这些数据给出风险等级输出格式是固定的JSON包含risk_level、reason、suggestion三个字段。这个Skill做好之后任何采购流程都可以挂载它不需要重复开发。Skills机制的价值在于“沉淀”。企业里有很多隐性的判断规则比如“这个客户虽然信用分低但合作五年了可以放宽账期”“这个物料虽然库存够但下个月要涨价建议多采”。这些规则以前只存在于老员工的脑子里现在可以通过Skills固化下来让AI在流程里自动执行。3. 核心细节解析AI节点到底怎么配3.1 AI节点的输入输出定义配置一个AI节点第一步是定义它吃什么、吐什么。JNPF的AI节点配置界面里输入部分可以选择“流程变量”“表单字段”“固定值”三种来源。我的经验是尽量用流程变量因为表单字段会随着表单改版而失效固定值只适合做常量配置。输出部分需要定义Schema。这里有个坑很多人图省事让AI直接输出一段自然语言然后下游节点用字符串截取的方式去解析。这种做法在演示的时候没问题一上生产就崩。因为大模型的输出有随机性今天说“风险较高”明天说“存在一定风险”字符串匹配根本扛不住。正确的做法是强制AI输出结构化数据。在JNPF里可以通过两种方式实现一是在提示词里明确要求JSON格式并给出示例二是使用平台内置的“结构化输出”开关它会自动约束模型的输出格式。我一般两个都用提示词里写清楚同时打开结构化输出做兜底。{ risk_level: high, risk_score: 78, reasons: [近三个月交货准时率低于80%, 存在两笔未结质量扣款], suggestion: 建议要求供应商提供履约保证金或更换备选供应商 }上面这个结构是我做供应商评估时用的。risk_level只有high、medium、low三个枚举值这样下游的条件节点可以直接用等值判断不需要做模糊匹配。3.2 提示词工程的实操要点提示词这东西网上的教程大多在讲“角色设定”“思维链”这些通用技巧。但在企业流程场景里提示词的核心目标不是让AI“回答得好”而是让AI“输出得稳”。稳定比聪明重要得多。我总结下来企业场景的提示词要包含四个部分角色约束、数据注入、判断规则、输出格式。角色约束是告诉AI“你是谁、你的职责边界在哪”数据注入是把流程变量里的业务数据填进去判断规则是把公司的制度翻译成AI能理解的逻辑输出格式就是上面说的Schema。举个实际的例子。我们做费用报销的AI审核节点时提示词是这样写的你是公司财务共享中心的费用审核专员。你的职责是根据公司报销制度审核员工提交的费用申请。你只能基于以下提供的数据和规则做判断不得引入外部知识。待审核数据报销人部门为{{dept}}费用类型为{{expense_type}}金额为{{amount}}元发生日期为{{date}}事由为{{reason}}。审核规则1. 差旅费单笔超过5000元需附审批单2. 业务招待费需注明招待对象和人数3. 发生日期超过90天的费用不予报销4. 同一事由重复报销的标记为异常。请输出JSON格式的审核结果包含pass布尔值、reject_reason字符串pass为true时为空、risk_flag字符串可选值为none、duplicate、over_limit、expired。这段提示词里没有“请仔细思考”“你是一个专业的”这类废话。每句话都有明确的功能。数据注入用双花括号占位JNPF在运行时会自动替换成实际的流程变量值。3.3 流程变量的传递与作用域AI节点处理完的数据要写回流程变量供下游节点使用。这里有个作用域的问题容易被忽略。JNPF的流程变量分三种作用域全局变量、流程实例变量、节点局部变量。全局变量在整个流程定义里都能访问适合放一些配置项比如“公司差旅标准”“审批金额阈值”。流程实例变量跟具体的流程实例绑定每个实例的值可以不同适合放表单数据、AI处理结果。节点局部变量只在当前节点内有效出了这个节点就销毁适合放一些临时计算值。我踩过的坑是一开始把所有AI输出都写成全局变量结果多个流程实例并发的时候数据互相覆盖。后来改成流程实例变量就正常了。判断标准很简单如果这个数据是“这个流程走到这里时产生的”就用流程实例变量如果是“所有流程都一样的配置”才用全局变量。3.4 Skills的注册与版本管理Skills在JNPF里是以独立模块存在的可以跨流程复用。注册一个Skill需要填名称、描述、输入参数、输出参数、处理逻辑。处理逻辑可以是一段提示词也可以是一个MCP Tool调用链。版本管理这块我要特别提醒。Skills一旦被多个流程引用修改的时候就要非常小心。我的做法是任何Skill的修改都新建一个版本而不是直接改原版本。新版本先在一个测试流程里验证确认没问题后再把生产流程的引用指向新版本。JNPF支持Skill的多版本共存引用的时候指定版本号就行。这个做法看起来麻烦但能避免“改了一个Skill十个流程同时出问题”的灾难。我见过一个团队因为直接改了公共Skill的提示词导致所有采购流程的审批意见格式全乱了排查了一整天才定位到原因。4. 实操过程从零搭一个带AI的采购审批流程4.1 流程建模与节点规划先画流程图。一个典型的采购审批流程包含这些节点发起申请、AI预审、部门审批、AI风险评估、财务审批、采购执行、完成。其中AI预审和AI风险评估是两个AI节点其他是人工节点或系统节点。为什么要在部门审批之前加一个AI预审因为人工审批的时间很宝贵应该花在真正需要判断的事情上。AI预审负责处理那些规则明确的部分预算科目对不对、金额有没有超限、必填项有没有漏。这些检查AI几秒钟就能做完人工做可能要几分钟而且容易漏。AI风险评估放在财务审批之前是因为财务最关心的是“这笔采购会不会出问题”。AI把供应商的历史表现、当前合作状态、市场行情这些数据综合起来给一个风险评级财务看到评级后再决定要不要深入看细节。这样财务的审批效率能提升很多。4.2 AI预审节点的详细配置预审节点的输入需要这些流程变量申请部门、采购类别、预算科目、申请金额、物料清单、期望到货日期。输出需要这些变量precheck_pass、precheck_issues、corrected_budget。提示词的核心逻辑是三条规则第一预算科目必须与采购类别匹配比如“办公用品”不能走“设备采购”的预算第二申请金额不能超过该预算科目当前可用余额第三期望到货日期不能早于当前日期加采购周期。这里有个细节预算余额需要通过MCP Tool实时查询不能写死在提示词里。我在JNPF里配置了一个MCP Server对接的是客户的预算系统暴露了一个query_budget_balance的方法。AI节点在运行时先调用这个方法拿到余额再把余额和申请金额一起送给大模型判断。# MCP Tool调用的伪代码示意 budget_info mcp_client.call( serverbudget-system, toolquery_budget_balance, params{dept: dept_code, subject: budget_subject} ) # budget_info 返回 {available: 125000, used: 75000, total: 200000}拿到余额后提示词里这样写“该预算科目当前可用余额为{{budget_info.available}}元本次申请金额为{{amount}}元。如果申请金额大于可用余额precheck_pass为falseprecheck_issues中说明超出金额。”4.3 风险评估节点的Skills挂载风险评估节点不直接写提示词而是挂载一个已经注册好的Skill。这个Skill叫“supplier_risk_assessment”输入是供应商ID、采购金额、物料类别输出是风险评级和建议。Skill内部的处理逻辑分三步。第一步调用MCP Tool查询供应商的历史数据包括近12个月的交货准时率、质量退货率、合同履约情况。第二步把这些数据和采购金额、物料类别一起送给大模型让模型按预设的评分卡打分。第三步把打分结果映射成风险等级并生成一段给审批人看的建议。评分卡的逻辑是这样的交货准时率权重40%低于90%开始扣分质量退货率权重30%高于2%开始扣分合同履约权重20%有违约记录直接扣20分采购金额权重10%金额越大风险容忍度越低。总分100分80分以上为低风险60到80为中风险60以下为高风险。这个评分卡不是拍脑袋定的是跟客户的采购总监一起梳理出来的。他说他们内部判断供应商风险主要就看这几个维度只是以前靠经验现在把它量化了。这个梳理过程很重要AI节点的判断逻辑必须跟业务方的实际决策逻辑对齐否则AI说低风险、业务方觉得高风险流程就卡住了。4.4 人工审批节点的AI辅助展示AI节点处理完的结果要在人工审批节点展示给审批人看。JNPF支持在审批页面配置自定义展示组件。我把AI预审的问题列表和风险评估的评级做成了一个卡片放在审批页面的顶部。卡片的设计有讲究。预审问题用红色标签展示每条问题后面跟一个“查看详情”的链接点开能看到具体的规则依据。风险评估用颜色区分低风险绿色、中风险黄色、高风险红色旁边附上AI给出的建议。审批人如果不同意AI的判断可以在卡片下方填写反对意见这个意见会作为流程变量记录下来用于后续优化Skill。这个“反对意见记录”的机制很关键。AI的判断不可能100%准确但每一次人工推翻AI的判断都是一次宝贵的反馈。我定期把这些反对意见导出来分析看看是提示词写得不够清楚还是评分卡的权重需要调整。迭代几轮之后AI判断的准确率会明显提升。4.5 流程变量的完整传递链路把整个流程的变量传递串起来看发起节点产生form_data包含部门、类别、金额、物料清单等AI预审节点读取form_data调用MCP查预算输出precheck_result部门审批节点展示precheck_result审批人确认后产生dept_approvalAI风险评估节点读取form_data和dept_approval挂载Skill输出risk_assessment财务审批节点展示risk_assessment审批人确认后产生finance_approval采购执行节点读取所有前面的变量生成采购订单。每个节点的输出变量都要在流程定义里显式声明不能隐式传递。JNPF的流程设计器里有个“变量映射”的界面把上游节点的输出映射到下游节点的输入。这个映射关系要仔细检查我遇到过因为变量名拼写不一致导致下游节点读不到数据的情况排查起来很费时间。5. 常见问题与排查技巧实录5.1 AI节点超时或返回空值这是最常见的问题。表现是流程走到AI节点卡住或者AI节点直接跳过、下游节点拿不到数据。原因通常有三个一是大模型接口响应慢超过了流程引擎的超时设置二是提示词太长超出了模型的上下文窗口三是MCP Tool调用失败导致AI节点拿不到必要的输入数据。排查顺序是这样的先看流程日志里AI节点的执行记录确认是超时还是报错。如果是超时把流程引擎的超时时间从默认的30秒调到60秒同时检查提示词是不是塞了太多无关内容。如果是MCP Tool调用失败去MCP Server的日志里看具体的错误信息常见的是认证过期或者参数格式不对。我自己的经验是给AI节点加一个“降级策略”。在节点配置里可以设置“AI处理失败时”的行为可以选择“跳过并继续”“转人工处理”“终止流程”。对于预审这种非关键节点我一般设成“跳过并继续”同时发一条通知给流程发起人让他知道AI预审没跑成功。对于风险评估这种关键节点设成“转人工处理”让审批人多花点时间自己判断。5.2 AI输出格式不符合预期明明提示词里写了要输出JSONAI偏偏给你返回一段带Markdown代码块的文本或者JSON里多了一些没定义的字段。这个问题在早期版本里很常见后来JNPF加了结构化输出约束之后好多了但偶尔还是会出现。我的处理办法是加一层“输出清洗”。在AI节点和下游节点之间插一个“脚本节点”用一段简单的JavaScript把AI的输出规范化。比如去掉Markdown的代码块标记、把字符串类型的数字转成数值类型、给缺失的字段填默认值。// 输出清洗脚本示例 let raw context.getVariable(ai_raw_output); // 去掉可能的Markdown代码块标记 raw raw.replace(/json/g, ).replace(//g, ).trim(); let parsed; try { parsed JSON.parse(raw); } catch (e) { // 解析失败时返回一个安全的默认值 parsed { risk_level: medium, risk_score: 50, reasons: [AI输出解析失败请人工复核], suggestion: 建议人工审核 }; } // 确保必要字段存在 parsed.risk_level parsed.risk_level || medium; parsed.risk_score Number(parsed.risk_score) || 50; context.setVariable(risk_result, parsed);这段脚本看起来简单但能挡掉80%的格式问题。剩下的20%是模型本身的理解偏差需要通过优化提示词来解决。5.3 Skills修改后流程行为异常前面提过版本管理的重要性这里展开说排查方法。如果发现某个流程的AI行为突然变了第一步是确认它引用的Skill版本有没有被改动。JNPF的流程日志里会记录每次AI节点执行时引用的Skill版本号对比一下变更前后的版本号就能定位。如果确实是Skill改动导致的最快的恢复方式是把流程的Skill引用回滚到上一个版本。然后在测试环境里复现问题确认是新版本的哪个改动引起的。我一般会在Skill的变更说明里写清楚“改了什么、为什么改、影响范围”这样回滚的时候心里有数。5.4 常见问题速查表问题现象可能原因排查方法解决措施AI节点超时模型响应慢或提示词过长查看流程日志中AI节点耗时调大超时时间精简提示词AI节点返回空MCP Tool调用失败检查MCP Server日志修复MCP连接配置降级策略输出格式错误模型未按Schema输出查看AI原始输出加输出清洗脚本强化提示词约束下游节点读不到数据变量映射错误检查变量映射配置修正变量名确认作用域Skill改动导致异常引用了新版本Skill对比流程日志中的版本号回滚Skill版本测试后重新发布审批人看不到AI结果展示组件配置错误检查审批页面配置重新配置展示组件的数据源5.5 几个我踩过的坑第一个坑是提示词里用了“尽量”“最好”这类模糊词。比如写“尽量在3天内完成审批”AI的理解是“3天左右都行”结果有时候输出“建议5天内完成”。后来全部改成“必须在3天内完成”或者“如果超过3天则标记为超时”输出就稳定了。第二个坑是MCP Tool的返回数据格式不统一。有的Tool返回的是JSON对象有的返回的是JSON字符串有的甚至返回的是XML。AI节点拿到不同格式的数据处理逻辑就要写很多分支判断。后来我定了一个规范所有MCP Tool的返回必须是JSON对象字符串类型的值必须用双引号包裹。统一之后省了很多事。第三个坑是忽略了AI节点的并发限制。大模型接口通常有QPS限制如果同时有大量流程实例走到AI节点会触发限流。JNPF的流程引擎支持配置AI节点的并发数我一般设成5到10根据实际的大模型配额来调。设太高会触发限流设太低会影响流程吞吐量。6. 这套方案还能怎么扩展6.1 从审批流程扩展到数据录入场景AI节点不一定非要用在审批流程里。数据录入场景其实更适合AI介入。比如员工在表单里填写客户信息AI可以实时校验手机号格式、自动补全行政区划、根据公司名称查询工商信息。这些操作以前要么靠前端正则校验要么靠后端接口现在可以统一用AI节点来处理。我最近在做一个合同录入的场景。员工上传合同PDFAI节点调用OCR的MCP Tool提取关键字段然后用大模型判断合同类型、识别甲乙方、提取金额和期限最后自动填充到表单里。员工只需要核对一下不用手动敲几十个字段。这个场景的难点在于OCR的准确率但即使OCR有少量错误也比完全手动录入快得多。6.2 从单点AI扩展到多Agent协作现在每个AI节点是独立工作的预审节点不管风险评估的事风险评估节点也不关心预审结果。但在实际业务里这些判断是有关联的。预审发现预算不够风险评估就应该把“预算风险”纳入考量。JNPF的流程引擎支持节点之间的变量传递所以实现多Agent协作在技术上没有障碍。关键是在设计阶段就要想清楚哪些判断应该放在一个节点里做哪些应该拆成多个节点。我的原则是“一个节点一个职责”。预审就只管合规性检查风险评估就只管供应商风险两个节点的输出在人工审批节点汇总展示。这样每个节点的提示词可以写得很聚焦维护起来也容易。6.3 从人工配置扩展到自动优化现在Skills的提示词和评分卡权重都是人工调的。未来可以做一个反馈闭环把人工审批时推翻AI判断的记录收集起来定期分析哪些场景下AI判断不准然后自动调整提示词或权重。这个方向技术上可行但需要积累足够多的反馈数据。我目前的建议是先把反馈记录机制建起来数据攒够了再考虑自动优化。6.4 一个实际扩展案例AI辅助专利检索有个做研发的客户他们内部有个专利检索的流程。以前是研发人员自己写检索式去专利数据库里查查完人工筛选。现在他们用JNPF搭了一个流程研发人员输入技术方案描述AI节点调用专利数据库的MCP Tool做语义检索返回相关专利列表然后AI对每篇专利做相关性打分和摘要最后生成一份检索报告。这个场景里AI的价值不是“替代人做判断”而是“把人从重复劳动里解放出来”。检索式怎么写、哪些专利相关、摘要怎么提炼这些以前要花半天时间现在AI几分钟就能出一版初稿研发人员只需要在初稿上做增删改。效率提升非常明显。7. 我个人的几点实操体会第一AI节点的提示词要当代码来管理。不要随手写在配置界面里就不管了要像管理代码一样管理提示词有版本号、有变更记录、有测试用例。我现在的做法是把提示词存在一个独立的文件里通过JNPF的API导入这样可以用Git做版本控制。第二不要追求AI判断100%准确。在业务流程里AI的角色是“辅助”而不是“替代”。把AI的定位定成“帮审批人省掉80%的重复劳动”而不是“帮审批人做决定”心态会好很多落地阻力也小很多。第三先从非关键流程开始试。不要一上来就把核心的财务审批流程交给AI。先找一个边缘的、出错了影响不大的流程比如内部培训申请的审批跑通了再往核心流程推广。这样即使出问题也有时间和空间去调整。第四MCP Tool的粒度要适中。太粗了AI不好用比如一个Tool叫“处理采购”AI不知道具体要传什么参数太细了调用次数太多比如查供应商信息拆成查名称、查地址、查联系人三个ToolAI要调三次。我的经验是一个Tool对应一个完整的业务动作比如“查询供应商完整档案”就是一个合适的粒度。第五定期回顾AI节点的执行日志。我每个月会花半天时间把上个月所有AI节点的执行记录导出来看一遍。重点看两类一类是AI判断和人工判断不一致的分析原因另一类是AI节点报错或超时的看看有没有共性。这个习惯帮我发现了好几个隐藏的配置问题。这套东西说到底核心不是技术有多复杂而是思路要转变。低代码平台把“搭系统”的门槛降下来了AI把“做判断”的门槛降下来了两个降下来之后真正稀缺的是“把业务逻辑翻译成AI能理解的规则”的能力。这个能力目前还得靠人靠对业务的理解和对AI边界的认知。我见过太多团队卡在这一步工具都有了就是不知道怎么把业务规则拆成AI能执行的步骤。希望这篇东西能给正在这个阶段摸索的人一点参考。