1. 项目概述从“伪AI”泡沫到架构务实最近两年如果你关注过企业级软件或者开发者工具领域一定被“AI低代码”这个概念刷过屏。一时间仿佛所有的低代码平台都争先恐后地给自己贴上AI的标签从“智能表单生成”到“AI辅助建模”再到“自然语言生成应用”宣传语一个比一个炫酷。但作为一线的开发者和技术决策者我们心里都清楚这里面有多少是货真价实的技术突破有多少是营销驱动的“伪AI”泡沫。很多所谓的AI功能不过是把一些简单的规则引擎、模板匹配或者对现有开源模型的浅层封装包装成了颠覆性的黑科技。我所在的团队在过去三年里深度使用并参与定制了一款名为JNPF的低代码平台。从最初的狂热追捧AI概念到后来被各种不成熟的“智能”功能拖累项目进度我们经历了一个完整的“祛魅”过程。最终我们决定回归本质在JNPF最新的v7.0架构蓝图中彻底进行了一场“去伪存真”的架构重构。这场重构的核心不是堆砌更多华而不实的AI噱头而是通过三次关键的解耦让平台回归稳定、高效与灵活。今天我就想结合我们的实战经历聊聊“伪AI”退潮后一个务实的低代码平台架构应该是什么样子以及这三次解耦如何从根本上提升了我们的交付能力和开发体验。这不是一篇吹捧某个平台的文章而是一个踩过坑的团队关于架构选型与工程实践的真诚复盘。2. 第一次解耦业务逻辑与AI能力的分离在v7.0之前我们的架构深受“紧耦合”之苦。当时的思路是为了体现平台的“智能”我们将一些初级的AI能力比如基于关键词的字段类型猜测、简单的代码片段推荐直接硬编码到了核心的业务流程引擎和表单设计器中。这导致了几个严重的问题。2.1 “智能”变“智障”紧耦合带来的困境最典型的例子是表单字段的自动识别功能。设计器希望用户拖入一个“金额”字段时平台能“智能地”为其配置好“货币”格式、校验规则甚至关联的汇率计算逻辑。这个想法很好但实现上我们将一个外部的自然语言处理NLP服务调用直接写死在了表单渲染的核心链路里。结果就是稳定性灾难当那个NLP服务因为网络波动或模型升级出现响应缓慢或失败时整个表单设计器的保存和渲染操作都会卡住或报错。用户看到的不是“智能识别失败请手动配置”而是整个页面白屏或一个晦涩的“系统内部错误”。灵活性归零不同客户对“金额”的理解完全不同。有的需要人民币、美元双币种有的只需要整数有的需要支持小数点后六位金融场景。我们硬编码的“智能”逻辑无法适应这些差异反而成了定制开发的绊脚石。要改就得动核心代码。性能瓶颈每一个字段的拖拽、每一次表单的预览都可能触发一次远程AI服务调用。在复杂页面中这带来了巨大的延迟完全违背了低代码“快速可视化”的初衷。这让我们意识到把处于探索阶段、成功率并非100%的AI能力与要求高稳定、高可用的核心业务逻辑捆绑在一起是一个架构上的严重失误。AI应该是“锦上添花”的增强选项而不是“雪中送炭”的核心依赖。2.2 v7.0的架构应对定义清晰的AI服务边界在v7.0的架构设计中我们做的第一个重大决定就是实施业务逻辑与AI能力的物理与逻辑解耦。物理解耦体现在部署上。我们将所有AI相关的能力如NLP识别、图像OCR、文档理解、代码生成建议剥离出来构建成独立的AI能力中台微服务。这个服务集群拥有独立的资源池、弹性伸缩策略和容错机制。即使它全部宕机核心的表单设计、流程引擎、数据模型等业务功能依然可以正常运行只是会暂时失去“智能推荐”这类增强特性回归到传统的手动配置模式。这保证了核心业务的SLA服务等级协议。逻辑解耦则通过一套清晰的**“能力网关”和“降级策略”** 来实现。核心业务模块不再直接调用AI服务而是通过一个统一的网关接口。这个网关接口背后我们设计了完善的策略熔断机制当AI服务连续失败达到阈值网关会自动熔断后续请求直接返回空结果或默认值避免拖垮业务线程。异步调用与结果缓存对于非实时必要的AI功能如代码辅助生成采用异步消息队列。用户触发后平台立刻返回“处理中”后台异步调用AI服务完成后通过通知或下次刷新展示结果。同时对常见的识别结果如“姓名”、“电话”等字段类型进行缓存避免重复调用。插件化接入网关定义了标准的输入输出协议。无论是接入 OpenAI 的 GPT、百度的文心一言还是部署在内部的私有模型只要符合协议都可以作为AI能力的提供方。这使得我们可以根据客户的数据安全要求、成本预算灵活切换或组合不同的AI引擎。实操心得这次解耦最关键的收获是心态的转变。我们不再追求“全自动的魔法”而是定位为“增强效率的助手”。在表单设计场景我们现在会提供一个“智能识别”按钮点击后才会触发AI分析并明确将识别结果作为“推荐项”高亮显示用户可以一键采纳也可以完全忽略手动调整。将控制权交还给用户反而获得了更好的口碑。3. 第二次解耦数据模型与渲染引擎的分离低代码平台的核心价值之一是“一次建模多处使用”。但在早期版本中我们的数据模型定义数据结构、关系、约束和前端渲染引擎如何展示和交互绑定得非常紧密。一个典型的痛点是我们在PC端设计了一个包含复杂联动逻辑的表单到了移动端却发现渲染性能极差或者某些组件根本不支持需要几乎重做一遍逻辑。3.1 渲染绑定的代价多端适配之痛之前的架构可以简化为后端数据模型 - 生成特定的前端组件树描述 - 前端渲染引擎直接解析渲染。这里的“特定的前端组件树描述”是问题所在。它深度耦合了当时PC端Web框架比如React的技术栈和组件库。当我们需要支持移动端H5、小程序甚至桌面客户端时面临两个选择为每个终端写一套渲染引擎成本极高且业务逻辑如字段校验、联动规则需要在多套引擎中重复实现和维护极易产生不一致。让同一套渲染引擎去适配不同终端结果就是做出各种妥协要么牺牲PC端的体验要么让移动端显得笨重不堪。这本质上是因为数据模型业务关心的“是什么”和视图渲染用户感知的“怎么显”没有分离。数据模型中掺杂了过多用于特定渲染的“视图逻辑”。3.2 引入“视图模型”层实现真正的多端一致在v7.0架构中我们引入了关键的“视图模型View Model”层实现了数据模型与渲染引擎的彻底解耦。整个流程变成了领域模型纯粹的实体定义如“订单Order”包含字段id, sn订单号 amount金额 customerId客户ID。它只关心业务数据本身。视图模型这是一个中间抽象层。它定义的是“在某个特定业务场景下数据应该如何被呈现和交互”。例如“订单创建视图模型”会描述sn字段需要一个文本框标签显示为“订单编号”且有唯一性校验amount字段需要一个货币输入框标签为“金额”且必须大于0customerId字段需要一个弹出式的客户选择器组件。关键在于视图模型不指定具体的UI组件如是用Ant Design的Input还是Element UI的El-input它只描述组件的类型“text_input”, “currency_input”, “popup_selector”和通用的行为规则。渲染引擎每个终端PC Web、移动H5、微信小程序拥有自己的渲染引擎。这些引擎的职责是将通用的“视图模型”翻译成自己技术栈下的具体UI组件和代码。PC引擎可能将“popup_selector”翻译成基于Ant Design的ModalTable而小程序引擎则将其翻译为picker组件。通过这次解耦带来了巨大收益多端体验统一业务逻辑定义在视图模型中的校验、联动只需编写一次各端渲染引擎负责以原生体验实现它。移动端的交互可以完全遵循移动端的设计规范而不是PC端的缩水版。前端技术栈自由客户或实施团队如果对默认的React渲染引擎不满意可以基于视图模型协议自己开发一套基于Vue或Solid.js的渲染引擎而不需要触碰后端的领域模型和业务逻辑。动态主题与定制更换UI主题、调整组件库变得非常容易因为只需要更换或调整对应渲染引擎的“翻译规则”即可。踩坑记录定义“视图模型”的抽象层级是这个环节最难的。抽象得太高如只定义“输入框”会导致渲染引擎实现时缺乏足够的约束体验不一致抽象得太低如定义“使用Ant Design的Input组件并设置bordered属性为false”就又回到了紧耦合的老路。我们最终参考了类似JSON Schema的理念定义了一套包含数据类型、UI提示、校验规则、事件钩子的DSL领域特定语言在实践中取得了较好的平衡。4. 第三次解耦流程引擎与业务规则的分离低代码平台的另一个核心是工作流引擎。过去我们的流程引擎强大但笨重因为大量的业务判断逻辑都以“硬编码”或“脚本片段”的形式直接写在了流程的节点配置里。例如一个采购审批流程中“金额大于10万需要总监审批”这个规则可能直接以一段Groovy脚本的形式挂在流程的“路由决策”节点上。4.1 “硬编码”规则的维护噩梦这种做法在项目初期很快捷但随着业务变化它迅速变成了维护的噩梦变更困难业务规则散落在成百上千个流程定义中。当“总监审批阈值从10万调到20万”时开发人员需要找出所有相关的流程进行修改测试和上线风险极高。无法复用同样的“金额大于X需Y角色审批”规则在报销流程、合同流程中反复出现却需要重复编写和配置。业务人员无法理解流程图上嵌入的脚本代码对业务分析师来说是黑盒他们无法直接验证或调整规则必须依赖开发人员违背了低代码“业务主导”的初衷。4.2 构建独立的业务规则引擎在v7.0中我们实施了第三次关键解耦将业务规则从流程引擎中剥离形成独立的“业务规则引擎”。这个规则引擎的核心是一个规则库和规则执行器。规则库用于存储和管理独立的业务规则。每条规则有唯一的标识、描述、输入参数和输出结果。规则可以用多种方式定义决策表最适合像审批阈值这种条件组合清晰的场景。业务人员可以在界面上像填Excel一样配置。 | 条件订单金额 | 条件客户等级 | 结果所需审批人 | | :--- | :--- | :--- | | 100,000 | 任何 | 总监 | | 50,000 且 100,000 | VIP | 经理 | | 50,000 且 100,000 | 普通 | 总监 | | 50,000 | 任何 | 自动通过 |规则脚本对于更复杂的逻辑仍然支持Groovy等脚本语言但它们现在被封装成一条可复用的规则。模型调用甚至可以封装调用一次AI模型服务如用于风险评分作为一条规则。流程引擎的改造流程引擎中的决策节点、任务分配节点不再直接包含逻辑而是引用规则库中的某条或某组规则。节点配置变成了“请执行规则RULE_APPROVAL_LEVEL传入参数{amount: $form.amount, customerLevel: $form.customerLevel}并根据返回结果approverRole来决定路由方向或指派审批人。”这次解耦带来了架构上的清晰度和业务上的灵活性单一职责流程引擎只关心“流转”顺序、并行、分支、合并业务规则引擎只关心“决策”根据条件计算出一个结果。两者通过清晰的接口协作。规则集中管理所有业务规则有了统一的“家”。修改、停用、启用、版本管理都变得非常方便。可以直观地分析规则之间的冲突和覆盖。业务友好简单的规则如决策表可以直接由业务人员维护。复杂的规则由开发人员封装好后业务人员可以在流程中像搭积木一样引用它们真正实现了业务逻辑的可视化编排。高效测试与模拟规则引擎可以独立于具体流程进行测试。我们可以构造各种输入参数批量验证规则输出的正确性。在流程上线前还可以进行完整的规则模拟运行。5. 解耦之后的架构全景与开发体验完成这三次解耦后JNPF v7.0的架构从原先一个臃肿的“单体巨兽”演变成一个清晰的分层协同体系。我们可以用下图来概括其核心思想[ 外部AI服务/模型 ] --- [ AI能力网关 ] --- [ 核心应用层 ] (可选增强) (熔断/降级/路由) (表单/流程/报表设计器) | v [ 业务规则引擎 ] -------- [ 视图模型层 ] -------- [ 领域模型层 ] (决策表/脚本) (读写) (场景化UI描述DSL) (读写) (实体/关系/约束) | v [ 数据持久层 ] (数据库/缓存) | v [ PC渲染引擎 ] [ 移动端渲染引擎 ] [ 小程序渲染引擎 ] ... (多端适配) (Vue/React) (Uni-app/Taro) (原生语法)这个架构下开发一个典型业务应用如采购审批系统的体验发生了根本变化领域建模首先在“领域模型层”定义“采购单”、“供应商”、“商品”等核心实体及其关系。这个过程是纯粹的业务数据结构设计不涉及任何UI。视图编排在“视图模型层”为“采购单创建”、“采购单审批”等场景创建视图模型。通过拖拽方式将模型字段与抽象的UI组件类型绑定并设置校验、联动规则。此时可以点击“智能辅助”按钮触发AI服务让平台推荐可能的字段分组或校验规则作为参考。规则定义在“业务规则引擎”中创建“采购金额审批规则”、“供应商黑名单规则”等。使用决策表或脚本定义其逻辑。流程设计在流程设计器中绘制审批流程图。在决策节点直接下拉选择引用前面定义好的“采购金额审批规则”。流程引擎只负责驱动不关心规则细节。多端发布发布应用时选择需要适配的终端PC、移动H5。平台会自动根据同一份“视图模型”调用对应的渲染引擎生成各自终端的代码和配置。业务人员在不同设备上看到的是体验最佳、且逻辑完全一致的界面。6. 总结务实架构是低代码穿越周期的基石回顾从拥抱“伪AI”概念到实施v7.0三次解耦的历程我的核心体会是在技术领域尤其是面向企业的生产力工具稳健可靠的架构远比炫酷超前的概念更重要。AI是强大的助推器但它必须被放置在正确的位置——作为一个可插拔、可降级的增强服务而不是系统的核心支柱。这三次解耦业务与AI、数据与视图、流程与规则本质上都是在做同一件事降低系统的熵提高各部分的自治性和组合性。它让我们的平台从一个大泥球变成了一个由高内聚、低耦合模块组成的乐高积木城堡。每一个模块都可以独立进化、替换、扩展。对于正在选型或开发低代码平台的团队我的建议是不要被“全智能”、“零代码”这样的口号迷惑。先去审视它的架构是否清晰核心的引擎表单、流程、数据是否稳定高效扩展机制是否灵活。一个在架构上深思熟虑的平台即使初期AI能力不强也能通过清晰的接口快速集成未来更强大的AI而一个架构混乱、靠概念堆砌的平台即使现在功能眼花缭乱也注定在未来的维护和扩展中举步维艰。JNPF v7.0的这次架构演进就是我们对此交出的答卷。它或许不完美但指向了一条更务实、更可持续的低代码发展路径。