★ FEATURED ARTICLE 过去一年我至少被问过三十次低代码到底选哪个平台。问的人里有IT主管、有业务部门的数字化专员也有刚被老板布置了快速搭一个OA任务的前端开发。而每次聊到最后问题都会变成同一个谁才是低代码之王这个问题看似简单实际上很难回答。因为低代码这个词本身就藏着一个巨大陷阱——它不是一个统一的技术品类而是一群技术路线完全不同、目标用户完全不同的产品被塞进了同一个筐里。有的产品本质是Excel加强版有的产品本质是可视化代码生成器有的产品本质是数据库前台你根本没法用同一把尺子量它们。所以这篇对比我不想再做功能列表大比斗那除了引来粉丝互喷没有任何价值。我会先用一套统一的评价框架再用同一个真实场景在五类主流平台上各跑一遍最后告诉大家谁配得上王这个字以及这个王对你有没有意义。1. 先立规矩什么样的平台才有资格争低代码之王1.1 低代码对比比的不是功能数量先说说市面上最常见的错误对比方式打开官网看功能清单数一数谁家的组件多、模板多、集成多然后得出结论。这种对比毫无意义因为组件数量这东西是做给销售看的不是做给使用者看的。我见过太多项目死在组件数量之外的地方表单搭出来很漂亮但一遇到跨表数据汇总就卡壳审批流配得很顺但某个审批节点要调外部系统接口发现平台根本不支持自定义脚本开发阶段一切顺利等要交接给另一个团队维护时发现代码根本导不出来只能永远绑死在这家平台上。真正的低代码选型比的是三个底层问题第一这个平台能承载的业务复杂度上限有多高第二当平台自带功能不够用的时候你有没有逃生通道第三从第一天用到最后一天你的数据资产和代码资产到底属于谁。这三个问题才是王的试金石。1.2 我用来测出真王的五个维度基于这些年踩坑的经验我把评价维度收敛成五个每个维度下面各有几个具体考察点搭建速度一个中等复杂业务不是简单问卷也不是复杂ERP从零到能跑需要多久。考察点包括表单设计、数据录入、页面跳转、简单统计的效率。复杂度上限业务一旦涉及多表关联、条件分支、聚合计算、外部系统对接平台还撑不撑得住。这是区分玩具和工具的关键分水岭。扩展自由度平台能不能写自定义代码、接自定义脚本、调底层API。Low-code平台如果完全封死扩展能力那本质上就是租了一个格子间。治理与安全权限粒度细不细、操作日志全不全、部署环境能不能自主控制。上生产系统之前这一项直接决定生死。迁移成本表单、页面、数据、逻辑哪些东西能导出哪些东西进去就出不来。迁移成本某种程度上比购买成本更重要因为它是未来要还的债。1.3 一个贯穿五家的测试场景光说维度太抽象我这次用一个非常典型的真实需求来做实测员工入职管理应用。这个场景包含四项核心需求员工填写入职登记表包含基础信息、学历信息、紧急联系人三类子表数据表单提交后自动触发审批流HR负责人审核IT负责人分配账号部门负责人确认工位审批通过后自动给员工发一封入职确认邮件同时生成一份入职清单提供一个管理看板按部门、按月份统计入职人数能穿透到明细。这四项需求看着不复杂实际上把低代码平台的常见能力全考了一遍一对多子表建模、流程编排与分支、跨系统集成通知、聚合统计与下钻。我在五类平台上各跑了一遍下面每一章都会用到这个场景的实际结果。2. 五大平台背后的五条技术路线2.1 表格驱动派把所有业务都装进一张表表格驱动派是市面上受众最广的一类低代码产品核心交互完全围绕表格展开。你不需要先设计数据库不需要理解什么是主键和外键只需要像操作Excel一样把字段列出来、把数据填进去然后平台会自动帮你生成表单、流程和看板。这类平台的典型特征有三个第一上手极快通常十分钟内就能搭出第一个能用的应用第二内置的自动化能力很强表格变动、字段更新都能触发后续动作第三非常擅长处理轻量级的业务协作场景比如进度追踪、信息汇总、简单审批。我用入职场景测试时表格驱动派在录入登记表状态跟踪这部分的表现最好几乎没有学习成本。但它的天花板也很明显。当我把三类子表放进测试场景时表格驱动派的关联关系处理开始变得别扭——你需要手动维护多个表之间的关联字段还要靠查询引用来模拟一对多关系。流程审批如果超过三级可视化配置就开始显得拥挤。这类平台适合给业务人员做生产力工具不适合承载核心业务系统。2.2 表单流程派审批流驱动型企业应用表单流程派的代表产品大量出现在国内办公协同赛道中。这类平台的世界观是一切业务从填一张表开始表单流转和审批驱动是它的心脏。平台上预置了大量组织架构、权限、审批链路的底层能力你可以很轻松地配置出一套从发起、逐级审批、会签、到归档的完整流程。这类平台在入职场景测试里表现非常均衡。审批流配置是我见过的所有流派里最顺手的按角色指定审批人、多级条件分支、超时提醒、加签转办都是标配几乎不需要学习就能配出一个符合企业习惯的审批链。权限体系也做得很细字段级权限、数据范围权限都有。不过我在测试中也明确感受到了它的短板平台倾向于让你在它的标准业务对象框架内做事一旦业务逻辑偏离了平台预设的CRUD框架比如我需要跨应用汇总数据、需要调用外部HTTP接口做复杂数据处理时配置成本会快速上升。这类平台擅长把企业内部管理流程做得极其舒服但本质上它是流程引擎的产物不是通用的应用开发平台。2.3 模型驱动派为了复杂业务而生的重武器模型驱动派跟前面两类完全是两种物种。它的设计哲学是先定义数据模型和数据关系再由平台根据模型自动生成交互界面。换句话说表单和页面只是数据模型的外壳真正核心的是底层的数据结构设计。在我测试的五类平台里模型驱动派是唯一一个非常接近传统开发思维的低代码平台。它支持真正的实体建模、一对多/多对多关系、聚合计算字段、复杂校验规则。我做入职场景时三张子表是直接通过实体关系配置实现的后续做入职看板的统计根本不费劲因为数据模型从一开始就是正经的结构化设计。当然代价也很直接学习曲线是所有流派里最陡的。表格驱动派十分钟上手模型驱动派我花了一整天才把实体关系、页面布局、授权规则理顺。如果你是一个没有任何软件开发经验的业务人员我不建议从这里入门。但如果你是一个开发团队想找一个能让业务同学自助搭建、又不会把系统做成烂摊子的平台模型驱动派大概率是首选。2.4 代码生成派低代码只是入口源码才是终点代码生成派是一个很特殊的存在。它的形态看起来跟其他低代码平台没什么区别依然是拖拽组件、配置数据源、可视化编排逻辑。但它有一个颠覆性的差异平台最终生成的不是运行时的元数据解释器而是完整的源代码工程。这类平台在测试中给了我非常大的安全感。首先数据模型、页面结构、业务逻辑全部可以导出成一个标准工程其次你可以在平台之外对代码做任何修改甚至把生成的应用跑在自己的服务器上完全脱离原平台运行最后它解决了低代码最大的历史遗留问题——平台锁定。你不用担心平台倒闭、策略调整、价格翻倍因为代码在你手上。但要注意代码生成派把低代码的重心放在了生成而不是运行上。它带来的新问题是生成的质量决定了你后续维护的成本而质量很大程度上取决于设计器配置的规范程度。如果建模建得乱七八糟生成的代码同样乱七八糟。这类平台更适合有一定工程能力的团队把它当作开发加速器来用而不是给纯业务人员当傻瓜相机。2.5 智能对话派用自然语言重新定义搭建智能对话派是最近一年快速崛起的新物种。它核心的交互方式不是拖拽而是对话——你用自然语言描述我想要一个员工入职管理应用要包含基础信息、学历信息、紧急联系人三个部分的表单提交后走线上审批平台借助大语言模型直接生成对应的应用骨架包括数据表、页面、基础流程。这类平台在测试时给我的体验是惊艳与惊吓并存。惊艳的是从自然语言到可运行应用的转化速度确实快我描述完需求大概几十秒就生成了一个初始版本页面结构还基本靠谱惊吓的是一旦需求变得复杂比如我要改子表的某个校验规则、要调整审批分支条件时对话式的修改往往会触发连锁反应——我改了一个字段AI顺手把我的页面布局也改了而且没有版本控制帮你回退那个被顺手改的部分。所以我的判断是智能对话派现在还更适合做需求验证和原型加速它能让业务人员快速看到想法的雏形也能让开发人员省掉很多搭建页面的体力活。但要作为生产系统的核心承载它的确定性和可控性还差了不少火候。3. 核心能力横向拆解数据、流程、扩展、安全3.1 数据建模能力表结构自由度的分水岭低代码平台的真实差距往往在你看不见的数据层最先拉开。我在测试入职场景时第一件事就是看哪个平台能自然地完成一对多子表建模。这个需求在传统开发里就是建三张表加外键但在低代码平台上差异极大。表格驱动派把子表做成了明细表或者子表区块你能直观地在界面上录入多行数据但底层并没有真正意义上的实体关联后续如果要跨子表做复杂统计你会在公式配置里绕很久。表单流程派的子表能力稍微专业一些支持了主表明细的标准模式但明细表之外再嵌套层级就开始受限。模型驱动派是唯一一个完全不费力就支持多级关联的流派因为它的数据层从设计开始就是关系型的子表、关联查询、聚合计算都是原生能力。我在实际评估中会给读者一个非常具体的建议如果你的业务模型里存在超过两层的父子关系或者有大量间接关联查询尽量避开表格驱动派和表单流程派优先选择模型驱动派或代码生成派。低代码工具的复杂度上限九成由数据模型决定而不是由UI组件数量决定。3.2 流程编排能力从线性审批到条件分支流程能力是我这个入职测试里耗时差异最大的一项。五类平台的流程内核差异非常大表格驱动派内置的是自动化规则引擎适合做基于数据状态变更的触发动作但做多级审批、会签、转办这类组织行为时能力明显偏弱表单流程派的流程能力最强我基本没看文档就配完了完整的人事审批链路甚至支持了按部门维度动态指定审批人模型驱动派强在业务规则而不是审批流上它能非常严谨地表达业务逻辑但搭建审批界面和流转规则时操作成本高于表单流程派代码生成派对流程的支持取决于生成模板常规线性流程没问题复杂流转要写代码智能对话派能通过描述生成简单流程但流程分支一旦超过三个条件它就很难精准生成你想要的结果。我个人的感受是如果你所在的行业是流程密集型比如行政办公、人事审批、合同管理表单流程派是最省力的选择没有之一。流程能力是它的舒适区你没有必要在别的流派里跟它硬刚。3.3 扩展能力当Low-code不够用时的逃生舱再强大的可视化配置也总有覆盖不到的场景。我在测试中故意加了一个非标准需求审批通过后要把入职信息组装成一段JSON调用外部HR系统的接口创建员工档案。这个需求在常识里很常见但对低代码平台而言是一个非常残酷的测试。表格驱动派和表单流程派在这个测试里几乎全军覆没——它们能发送HTTP请求但只能在配置好的动作块里做固定格式的调用想对数据做动态的json组装、做异常重试几乎没有操作空间。模型驱动派的脚本能力让我眼前一亮它提供了服务端逻辑块可以写一段接近JavaScript的脚本来做数据处理但语法和调试体验与标准IDE还有明显差距。代码生成派在这个测试里是最舒服的因为本质上你在写一个正常的后端逻辑IDE、调试器、日志工具都能用上。智能对话派能生成一段脚本但生成的脚本质量不稳定你仍然需要能读懂代码的能力。我的建议是判断一个低代码平台够不够专业就看它的扩展模型是配置了事还是留了口子。如果平台完全没有脚本编写、API扩展、代码组件的能力它只适合做内部管理工具如果想承载有外部集成需求的业务系统必须把扩展自由当作一票否决项。3.4 权限与安全上生产系统前的生死线很多人选低代码平台时只盯着界面好不好看权限安全这块反而成了被忽视的暗礁。我用入职场景做了一个小小的权限测试要求部门负责人只能看本部门的入职数据HR管理员可以看全部数据且能导出Excel普通员工只能看自己的记录。这个需求在表单流程派和模型驱动派里完成得很顺畅它们都提供了角色、组织、数据范围三层权限模型字段级权限也能精确控制。表格驱动派的权限能力让我有点意外它能做到行级权限和列级权限的分离但配置起来比较繁琐。代码生成派对权限的控制最为彻底因为最终代码都是你的任何权限模型都可以实现。智能对话派在这块是最弱的它能生成简单的登录鉴权和页面可见性但复杂的组织维度数据隔离几乎是空白。我在任何场合都会反复强调一句话低代码平台做内部小工具权限差点问题不大一旦系统里有跨部门数据、客户信息、财务报表权限模型的设计直接决定了这个系统能不能用。权限弱不是不能补但补权限往往要付出比功能开发多得多的代价。4. 一张表看清五强差距场景得分与典型短板4.1 五大平台横向总览表我把这次入职场景的实际测试结果汇总成了一张表满分都为10分打分基于我个人的实际体验和客观配置过程供参考。评价维度表格驱动派表单流程派模型驱动派代码生成派智能对话派上手速度1096710业务流程支撑69876数据建模能力571086扩展自由度458107权限与安全689104数据/代码可迁移性457106生态与模板丰富度98665综合得分44515458444.2 每个平台的得分体感再详细说说这个分数是怎么来的。表格驱动派的上手速度和生态丰富度确实无敌套用模板几分钟就能做出一个看得过去的管理应用。但它的扣分点集中在复杂业务支撑上我在配置入职审批链时折腾了很久最后只能用变通方案绕过这种上限不够用的感受是综合分上不去的核心原因。表单流程派在流程上给了我很大的惊喜几乎所有的审批动作都能在图形化界面里拖出来。它的主要扣分点是数据模型灵活度不够当我在统计看板里要跨三张子表做聚合时平台提供的公式能力明显心有余力不足。模型驱动派是越用越香的类型开始配置实体关系时稍显繁琐但一旦模型建好后面做页面、做看板、做权限都变得非常顺滑。它的代价是组织内必须有一个略懂数据建模的人来当架构师否则普通业务人员很容易把模型建成一锅粥。代码生成派在这份表里的得分最高但要强调这是一次理想状态的得分。因为代码生成派的能力上限完全取决于生成代码的质量和团队的工程水平如果你所在团队没有能接手代码的人它的所有优势都发挥不出来反而比纯配置型的平台更难驾驭。智能对话派在搭建速度上跟表格驱动派并列第一但在生产交付所需的确定性、权限、迁移能力上短板明显。它现在的定位更适合做陪练和加速器而不是主战坦克。4.3 谁配得上低代码之王根据这份测试结果我给出的结论是模型驱动派和代码生成派最有资格争这个王字。模型驱动派胜在平衡之王它的学习曲线可以接受业务复杂度承载上限高权限体系完整生态也在逐步完善。它像是一把能应对大多数场景的瑞士军刀虽然不是每一种情况下最优但几乎没有明显的短板。代码生成派胜在终极之王它的能力上限是所有流派里最高的因为它本质上并没有把你锁死在平台上——当平台满足不了你的需求时你可以打开IDE继续写。它的唯一问题是对使用者的工程能力要求极高市面上的代码生成产品也良莠不齐生成质量差的会让你还债还到崩溃。至于表格驱动派和表单流程派我看到很多企业把它们当核心业务系统用最后往往都要走一条先用着再迁移的回头路。它们很适合做部门级工具但不适合承载企业级应用。智能对话派现在还谈不上称王但它代表了一个值得注意的方向。接下来的两到三年里随着AI生成结果的可控性变强它很可能会颠覆掉前面所有门派的上手成本结构——那一天到来的时候低代码之王的宝座恐怕要重新排一次。5. 选型建议与避坑经验别让王害了你5.1 按团队结构选型而不是按功能选型我已经记不清有多少人拿着上面那张对比表来问我哪个综合分高就选哪个这是一个非常危险的误区。综合得分高只代表那个平台在测试场景里表现好不代表它适合你的团队。我给出一套更务实的选型思路团队全是业务人员、没有专业开发优先表格驱动派或表单流程派选一个上手快、模板多的别追求复杂度上限因为你根本用不到上限反而你真正需要的是快速交付工具的能力团队里有1-2名懂数据模型的IT人员优先模型驱动派让这个人承担低代码架构师的角色其他人负责拖拽搭建和流程配置这个搭配最容易出效果团队本身就是开发团队优先代码生成派低代码最合理的用法是让开发者从重复造轮子中解放出来而不是让开发者成为一个新配置语言的专家正处于业务探索期、需求不明确可以用智能对话派做原型验证等需求边界清晰了再落到正式平台。我见过太多因为表格驱动派模板多所以企业选它做ERP的案例最后无一例外都卡在数据模型不够灵活上推倒重来损失巨大。选型的第一原则从来不是功能完善而是团队结构匹配。5.2 从试用第一天就要测试的四个问题很多团队试用低代码平台时习惯性从做一个演示小Demo开始这样根本测不出问题。我给一个更苛刻的试用清单建议你在交付决策前务必测完导出测试把搭建好的应用导出然后在一个全新环境里重新导入全程记录哪些东西丢了、哪些关系断了、哪些逻辑需要重新配置。这一步能解决数据到底属于谁的疑问。异常数据测试故意输入超长文本、特殊字符、空值、重复提交看看平台的校验机制和错误提示到底靠不靠谱。低代码系统的数据质量往往取决于这一层。并发测试叫上十几个同事同时录入、同时点击审批通过观察平台是否卡顿、数据是否会覆盖。不用搞复杂的压测工具一个大家一起点就能暴露很多问题。人员交接测试让搭建者旁边坐着另一个人只看文档不看原文件独立完成一个小模块的搭建。如果新手上手成本实在太高这个项目迟早会变成英雄单人项目。这四个问题看似苛刻但我实际测下来发现几乎每个低代码平台的候选者都会在某个问题上露馅。提前在试用期发现好过在项目交付后暴雷。5.3 我对低代码之王的最终结论在我写这篇对比之前我以为低代码之王会是一个明确的、有唯一答案的问题。真正把五个流派都跑完一遍之后我反而倾向于认为不存在一个对所有组织都最优的低代码之王但存在一个最适合你的低代码之王。如果你要的是业务人员也能轻松上手的王表格驱动派的王座没有人能动摇如果你要的是流程审批丝般顺滑的王表单流程派当之无愧如果你要的是能承载复杂核心业务的王模型驱动派是最稳妥的选择如果你要的是彻底摆脱平台锁定的王代码生成派是唯一的答案。我个人的实际操作体会是做了这次全面对比之后我在自己团队里采取了一个混合策略——日常的部门级协作工具用表格驱动派快速搭建核心业务系统沉淀到模型驱动派上碰到平台能力边界就通过代码生成派的扩展能力打补丁。真正适合你业务的那个王从来不是一个简单的选择题而是你对团队能力、业务复杂性、长期成本三者权衡之后的一个综合判断题。最后分享一个小建议与其在网上看一百篇XX平台测评软文不如把你手上最真实的一个小业务场景拿出来在候选平台上亲手搭一遍不追求最快搭完只追求把你日常会遇到的字段关联、流程审批、权限隔离、数据统计都试一遍半天时间就能拿到比任何测评都准确的答案。低代码这东西用起来比看起来诚实得多。
阅读完成 · 觉得有帮助？
