低代码市场前景
不知不觉，全球低代码市场已经走过了20+年的发展，对于低代码的起点事件众说纷纭，但从发展阶段划分，则观点比较一致，低代码发展分为三个重要阶段：
![]()
（1）早期探索阶段：一般我习惯将Salesforce的面世作为这个阶段的起点，从1999年到2007年左右，早期只有少数公司期望以低代码的方式为客户提供程序开发平台（这个阶段还没有机构明确提出“低代码”这个概念），比如成立于2001年的Outsystems，提出的是为技术领导者和开发人员提供快速构建和部署自己的关键业务应用程序的工具，成立于2005年的Mendix，提出为组织提供用更快、更简单的方式来驱动客户体验和运营效率的应用程序开发平台，我们创始人也是那时候成立的普元公司，提出的则是构件中国（用构件化的方式来快速组装企业软件）。（2）平稳发展阶段：这个周期历经了10年之久，上述的一些公司在这个阶段基本都是在闷头发展，并没能将低代码理念形成大规模市场推广，更多是在一些IT领先行业或客户处试点，形成标准化、敏捷化的平台能力，支撑客户复杂业务建设。也正是在这个周期里，Forrester于2014年提出了“低代码”概念：“利用很少或几乎不需要写代码就可以快速开发应用，并可以快速配置和部署的一种技术和工具。”随后2018年Gartner提出了APaaS概念，与低代码思路完全吻合，也正式将低代码推向了市场高点。（3）快速增长阶段：2018年开始，国外赛道率先发力，西门子高价收购Mendix、Outsystems宣布成功融资、微软PowerPlatform快速推广，紧接着国内大厂、创业公司陆续推出其低代码平台，越来越多的企业开始尝试以低代码技术重构数字化业务，进而探索应用开发新模式。经过近5年的高速发展，中国低代码市场来到了百花齐放的阶段，更旺盛的市场需求正在逐步在被激发，但随之而来的问题也越来越多，甚至很多人预测低代码已经来到了一个十字路口，回过头来看，其实我们产品的演进过程，也正是在这些问题背景下进行不断的抉择和调整的过程。我不太认同“全民开发”的观点，我认为至少10年内不太现实，企业现阶段引入低代码，其主要面向的还应该是科技人员而不是业务人员。但在国内，“全民开发”确实有不少支持者，如钉钉宜搭在其发布会上多次提到“人人都是低代码开发者”，其论证依据是钉钉上的低代码应用数已经超过200万，开发者中60%-70%是一线业务，但我们也必须意识到钉钉上的大部分应用，离企业核心系统还是有很大差异的，所以“全民开发”或许未来能实现，但目前要通过低代码实现专业系统，还是需要IT人员的配合，现在谈低代码公民化市场还为时尚早。另一个需要正确对待的是企业发展的问题，市场从来不缺热点概念，但市场机会和商业风险永远是并存的，就像当下造车新势力们面临的处境一样，熬着熬着一些车企突然就没了，低代码市场其实也正处于这个阶段，记得2018底的时候（那时候我们新一代低代码平台刚起步），一个同事很兴奋的跟我讲，有一家低代码公司的产品使用体验特别好，于是那时候就重点关注了这家公司（黑帕云），但2022年初，产研能力都还算靠前的黑帕云，却突然宣布退出市场（后来证明被大厂收购重组了，但大厂再推出的产品已经不那么纯粹了）。所以对于创业公司，如何避免低代码平台的同质化竞争、有自己的业务护城河是需要重点考虑的，也希望大厂不要将市场玩成纯资本运作，这样才能让国内低代码市场本身拥有更好的发展前景，为国内企业带来更优的应用探索建设模式。作为IT从业者，我们必须看到低代码的发展是积极向上的，其降低技术难度、减少代码编写、快速响应需求的目标不会变，低代码也势必会成为数据时代、中台时代的一大数字化价值利器。同时，Gartner等研究机构给出的市场诱惑也足够大，预测2024年国内市场规模会超过60亿元，且未来几年增速还会有所上升，相信届时厂商格局还会发生很大变化。
普元低代码演进原则
行至水深处，选择就会越来越多，一股脑的琐碎需求都往产品里灌，反而让产品容易迷失了主航道，而这对于规模小或业务单一的公司尤其致命。普元自2018年开启新一代低代码平台研发以来，也是经过了诸多调整重构，但一直坚持着以下几点设计理念，让产品研发过程中即使有过短暂弯路，也能最终回到正轨。
正如前面所提到的，如果低代码平台仅仅做一些简单业务，那全民开发也许并不遥远，但只有深入到企业复杂系统，才能给企业带来更大的平台价值。想要支撑这类复杂业务，低代码平台首先需采用模型驱动开发的模式，合理数据模型的设计是复杂系统成功建设的基础，再者，复杂系统通常都需要跨系统集成，低代码平台则应提供对应的服务编排能力，满足多模式的集成要求，并支持新服务的定义与发布，供上游方使用。![]()
企业引入低代码平台，肯定不想引入一个新的技术孤岛，低代码平台开发出来的应用，无论是制品管理、上线投产、还是治理运营，都应纳入到企业既有的标准管理体系中。低代码所使用的技术要保持普适性和前沿性，能够与主流客户使用的框架和版本接轨，包括对于一些基础设施或基础服务的使用（如信创环境、数据库服务、缓存服务、对象存储服务等），要做到快速适配，满足规范管理要求。现阶段的低代码平台，要做到各类复杂业务100%在线配置，显然难度很大，合理的模式则是专业开发封装组件+低代码开箱即用，通过标准化的组件扩展，将能力不断融合到低代码应用底座中。为了保持应用与底座的松耦合，对低代码底座也有更高的要求，无论是前后端能力的热插拔，还是多版本管理下的兼容性保障，都是要重点考虑的。这种在线+离线的模式，另一个好处则是团队专业分工也逐步明晰，未来每个企业都会是有IT能力的企业，但不可能每个企业都要成立很大规模的IT专业团队，让少数专业的人做更专业的事，为其他科技人员形成普适化支撑，也正是组织创新中低代码应发挥的价值。![]()
对于低代码性能的看重，跟我们早期的客户项目也有一定关系，平台初期就遇到了单页面有近300个控件+复杂布局的场景，团队也在一些业界低代码平台做了对应的性能验证，除了个别的react技术的低代码平台，基本上当时所有平台都没能达到1秒内渲染。也正是在那个时候，我们下定决心对表单设计器做了重写，将页面设计的中间模型与最终代码同时生成，最终达到了与专业代码接近的性能。除了前端表单之外，还有像前端视图、后端服务等，都需要类似的引擎处理，方能让低代码平台在性能上有所保障。如果大家关注国外低代码平台能力，可以看到像Mendix、Outsystems、AppMaker等低代码平台的发布特性上都会提到DevOps，其实低代码应用也需要管理需求、任务、代码、测试、制品、投产等一系列软件工程事宜，拿制品安全举例，因为通用服务等设计，很多低代码应用的内部风险反而更多，客户不可能因为看不到应用源码，就不关注应用安全问题，是否使用了不安全的三方依赖、是否开启了不安全的配置或端口，这些都需要有严格技术保障。其实应用和数据本就不该分家（之所以很多企业分开，主要是部门职责和专业技术的原因），应用产生高质量数据，数据支撑高质量应用建设，所以低代码的建设，从远景来看应该覆盖应用和数据两个领域，旨在将应用产生的数据价值形成回流，帮助客户快速分析和决策。考虑到商业市场的原因，普元内部的低代码产品本身还是要分开做的，但无论是后台底座还是前端UI，都遵循统一标准与体验要求，让客户亦可以一体化使用。![]()
低代码区别于零代码，还是要有一定的代码编写或IT知识作为使用基础，像日常开发中vue/html/css/groovy/正则表达式等代码片段编写、行业领域的实体关系建模、多语言国际化翻译等工作，借助AI可以大幅降低门槛，尤其在AIGC背景下，无论公有模型还是专有模型，对低代码平台都是很好的助推器，所以正如微软低代码中的AI Builder一样，低代码要与AI能力紧密集合，管理好各类场景的对应Prompt模板，在平台使用过程中不断融入智能化能力。新版本主要功能特性
普元低代码平台V8.3在整体架构上，与前序的8.2系列区别不大，这里简单说明下之前版本的结构，主要分为6大模块：
（1）云原生公共技术底座：适配各类信创环境，提供包括注册中心、配置中心、APM、网关、日志中心、DevOps等微服务架构的基础服务支撑；（2）高低代码融合的开发环境：提供离线开发工具的前后端插件，在线低代码开发门户，并将线上线下资源有序的融合组装，形成最终应用；（3）可选的专业服务引擎：包括流程引擎、调度引擎、应用联邦、报表引擎等专有引擎能力，供低代码应用选择使用；（4）统一的服务治理门户：对专业微服务应用、低代码应用统一管控，形成可配置、可观测的一体化治理能力；（5）低代码应用SDK基座：低代码应用的基础能力，亦可作为应用通用模板，提供应用快速初始化、低代码资源版本化管理、流程业务化配置等通用开发管理能力；（6）配置化的应用业务门户：提供默认的工作台、站内信、流程办理、菜单配置等实现，可按需进行定制，亦可以与用户既有业务门户标准化集成；![]()
相比于之前按月迭代的节奏，低代码V8.3版本历经半年才正式推出，期间对一些特性是否需要支持、历史版本升级影响面、关联产品能否平滑集成等做了大量评估与设计，着重在UI规范统一、底层框架升级、复杂页面支持、运行性能优化等方面发力：增加表格布局、Excel、模型容器、常用图表等标准控件，满足指标管理、数据填报、复杂单据等场景要求。在具体客户项目中扩展音频、视频、手写签名、扫码、OCR等业务控件，帮助客户形成组件积累，满足领域业务开发。对整体UI进行优化，标准化页面展示与操作方式，将在线设计与离线开发的成果进行严格的UI体验统一。新版本中还提供了自定义业务工作台、常用Widget、单应用门户等默认实现，为各类项目实施提供参考。![]()
（3）升级SpringCloud、SpringBoot版本将SpringBoot版本升级到2.7，SpringCloud版本也相应升级到2021.0.6，解决各类已发现的三方漏洞风险。同时，平台移除了netflix不再维护的组件，升级了开发工具版本及默认JDK范围，引擎运行性能也得到相应提升。删除原有的bps workspace服务，将流程管理功能迁移到统一业务门户上，增强业务配置化能力，为业务人员提供环节撤回、催办、打印、导出等配置服务，提供复杂参与者设置，如部门岗位、部门角色等复合规则，增加站内信通知渠道，增加流程实例回收站管理，优化审批意见设置、常用意见管理、过程附件管理等配套能力。![]()
拿表单设计为例，原有版本可生成对应源码预览，但不建议在线直接调整代码，防止影响设计器的反向展示。新版本支持在线上对局部区域或控件转离线设置，这样就可以在线上对页面进行特定修改，满足页面个性化需求。同样，对于后端的模型、服务等，也可以提供类似的模式，生成源码后进行更新优化。![]()
平台维护了常用prompt模板，并对接微软OpenAI、讯飞星火等大模型，在应用开发中形成智能助手。默认提供包括应用拆分推荐、实体及关系建模、前后端代码片段编写、报表图表推荐等能力，可结合客户需求快速扩展。基于XXL-Job扩展任务调度能力，除原生任务外，可分布式调度EOS在线与离线服务，重写其自带门户界面，管理微服务执行器与任务执行，在低代码平台的统一业务门户上进行配置监测。针对业务对象的操作权限、数据权限等进行优化，防止横向、纵向越权问题。增加用户密级管理，匹配数据、文件等重要资料的安全管理要求。新版本还对数据加密、掩码展示等提供了对应的实现方案，供项目实施中快速扩展使用。与普元主数据、资产等产品深度融合，如与主数据引擎打通，基于主数据模型定义，一键生成企业主数据维护流程与页面。后续低代码能力会作为普元所有产品的可选组件，与每个产品的核心模型与API打通，让每个产品都具备自定义流程、表单、服务的业务能力。产品后续展望和发展
人生如粥，熬出至味，低代码本身要走的路还长，在正确的方向上保持坚持是一件比技术、管理、创新都要难的事，切勿被单点事件或局部声音所影响。这些年在团队内部也对一些问题有过犹豫，比如是在线IDE模式还是业务功能菜单模式、页面驱动的零代码模式是否要支撑等，但好在自始至终还是坚持了上述的演进原则，一步步的将企业特性落地。
从短期目标来看，平台对常用场景开发体验还需要持续完善，丰富组件、模板、文档，降低入门门槛，对前后端技术（如SpringBoot3、Vue3等）能够保持跟随、逐步升级，同时对平台容器化、SaaS化能力进行增强，结合DevOps形成更完整的全生命周期支撑。从长期愿景来看，将低代码作为独立组件，融入到普元更多的产品方案中，同步发展数据低代码、交易低代码、重点行业零代码等，让公司所有产品具备业务可变性。同时也会于近期开放社区版，期望能够建立更好的低代码生态，共同驱动能力提升。![]()
对于寻求简化开发、加速转型的企业来说，低代码已成为这个时代的优选方案之一，让企业无需大量专业技术人员，就可以轻松地自定义应用程序。自11月以来，普元低代码最新版本已开始在银行、制造、政务等几个重要客户处试点，部分原有客户也在着手升级事宜，接下来普元仍会在信创背景下，以低代码的方式，聚焦客户专有科技平台的建设，同时支撑合作伙伴打造行业零代码方案，推进企业软件智能生产。![]()
关于作者：顾伟，普元数智研究院总经理，首席架构师，中国人工智能协会机器学习专业委员会委员，全球容器技术大会、全球软件研发行业创新峰会特约讲师。主导和推动普元微服务、研发运营一体化、主数据、企业服务总线等产品系列的版本演化和升级，精通基于SpringCloud的Netflix生态和Alibaba生态分布式解决方案，在需求结构化的描述方法、可重用体系架构的设计方法、业务可变性设计方法领域有深入的研究与实践，长期为广东农信、北京银行、九江银行等企业提供架构资产管控模型咨询与服务，参与工商银行、兴业银行、中国邮政集团等企业的数字化软件研发架构体系设计与规划。
全栈赋能信创，共创数智未来！
