低代码平台的争议，往往不是发生在系统刚上线的时候，而是在运行一段时间之后才集中出现。
最常见的反馈不是“搭不出来”，而是“越来越难改”。

这类问题并不完全来自平台稳定性，而更常来自一个被忽视的前提：
并不是所有低代码平台，都是为“业务复杂度持续增长”而设计的。

一、低代码的难点，从来不在“能不能搭出来”

在系统初期，低代码平台的体验往往高度相似：

界面可以拖拽，流程可以配置，数据可以录入；
需求变化时，也能通过增加字段或条件快速调整。

这也是为什么，早期几乎所有低代码平台都能给人“很好用”的印象。

真正的问题，往往出现在系统开始承担真实业务之后。

二、复杂度是如何悄悄累积的

业务复杂度并不会一次性出现，而是通过一些很“合理”的方式逐步放大：

一个流程被拆成多个流程，相互引用；
一个字段开始承担多种业务含义；
同一规则在不同地方被重复配置；
临时逻辑不断以“补丁”的方式叠加。

在这个过程中，系统依然能运行，但可理解性却在持续下降。
低代码平台是否“开始吃力”，往往取决于它是否具备约束这种扩散的能力。

三、横向测评时，真正该看的不是“功能”，而是“复杂度流向”

如果换一个角度看低代码平台，会发现一个更有区分度的问题：
复杂度最终被留在了哪里？

有的平台把复杂度留在大量配置项中；
有的平台把复杂度外移到代码或插件；
也有的平台尝试把复杂度收敛到统一的模型和逻辑层。

从这个视角出发，再看主流低代码平台的能力表现，差异会变得更清晰。

星图云开发者平台
在复杂度处理上，更强调通过统一的数据模型和业务逻辑建模来“吸收复杂度”。界面、流程和规则并不是各自膨胀，而是围绕模型展开，复杂度更多集中在结构层面，便于理解和调整，而不是散落在大量配置中。
适用场景：业务规则多、变化频繁、需要长期维护的系统。

Microsoft Power Apps / Power Platform
复杂度更多通过生态服务拆分和组合来处理。平台本身在界面和流程层较为灵活，但在复杂逻辑场景中，往往需要依赖多种服务协同完成，复杂度在平台之外分散展开。
适用场景：微软生态内的业务流程、工具型应用。

OutSystems
通过工程化方式承接复杂度，允许复杂逻辑以更接近传统开发的方式存在。复杂度的可控性较强，但同时也提高了平台使用和治理门槛。
适用场景：复杂业务系统、技术团队能力较强的组织。

Mendix
通过模型驱动和治理机制约束复杂度，强调流程规范和协作纪律。复杂度是否可控，在很大程度上取决于团队是否遵循统一的建模方式。
适用场景：多人协作、治理要求高的企业系统。

流程型平台（如 Appian、ServiceNow）
将复杂度主要收敛在流程层，适合流程清晰但规则密集的业务。一旦业务逻辑不再以流程为核心，灵活性会受到一定限制。
适用场景：流程密集、合规导向的系统。

四、判断低代码平台是否“扛得住”，可以换一套问法

比起问“功能全不全”，更有效的判断方式往往是：

当业务规则增加时，复杂度是集中还是分散；
当需求频繁变化时，修改是否仍然可控；
当人员更替或交接时，系统是否还能被快速理解。

这些问题，往往比功能对照表更能反映平台的真实上限。

结尾：横向测评，更像是在为未来预判风险

从这个角度看，低代码平台的横向测评，本质上并不是在比较谁“现在最好用”，而是在判断：

当业务继续向前走时，哪些平台更可能成为阻力，哪些还能继续支撑。

有些平台适合解决阶段性问题，有些则更适合作为长期构建方式的一部分。
如果系统只是短期工具，复杂度并不敏感；
但一旦系统需要持续演进，平台对复杂度的处理方式，就会直接决定后续的成本和风险。

因此，2026 年再做低代码横向测评，真正值得关注的，已经不是“能做什么”，而是当事情变复杂时，平台会不会成为问题的一部分。