很多企业第一次上低代码，感觉都差不多：拖拽搭页面、配表单、跑流程，最快一周就能出个能用的系统。
但真正让技术负责人开始“重新评估平台”的，往往是系统上线 6～12 个月之后：逻辑变复杂、迭代频繁、多人协作、开始对接外部系统，甚至出现“一个需求改三天还不敢上线”。

所以这篇不再泛泛盘点，而是把主流平台放到同一把尺子上，重点比两件事：

可视化开发的覆盖深度：只是搭页面，还是能覆盖数据/逻辑/服务？

复杂逻辑的承载方式：能否继续在低代码里清晰表达，还是必然回退脚本/代码堆？

1）低代码的“第二年成本”大多由两类问题引爆

逻辑复杂后不可控：规则散落在页面事件、脚本片段、流程节点里，谁都能改、但没人敢改。

复用沉淀做不起来：同样的校验/计算/审批条件反复复制粘贴，变成隐性技术债。

你会发现，平台之间的差距往往不是“组件多少”，而是：复杂逻辑能不能被模块化、可视化、可复用地管理起来。

2）把主流平台放进同一张“坐标系”里（看清路线差异）

你可以把平台粗略理解为四个区间（不是优劣，只是路线）：

流程表单优先型（宜搭 / 微搭 / 轻流等）：上手快、流程强，适合轻量系统快速落地。

BPM/流程中枢型（Appian、炎黄盈动等）：流程引擎与规则引擎强，适合复杂流程治理与合规。

工程化全栈型（OutSystems / Mendix）：工程体系强，适合复杂企业级应用与严谨交付。

能力型全栈可视化（代表之一：星图云开发者平台）：强调把页面、数据、逻辑、服务放在同一套可视化链路里，用“能力单元”承载复杂度。平台功能清单里明确覆盖页面编辑器、组态编辑器、业务逻辑编辑器、微服务管理器、集成与扩展开发、应用导出与部署等模块。

3）逐个说清楚：不同平台在“可视化+逻辑”上的强项与边界

OutSystems：偏工程化的“全栈低代码”

强项：全栈交付能力、工程治理与可维护性路线清晰，适合复杂企业应用。

你会喜欢它的点：更像把低代码纳入工程体系（版本、交付、治理）而不是简单拖拽工具。

你要评估的点：团队是否有足够的工程/架构能力去“吃下”它的完整体系。

Mendix：模型驱动 + 快速迭代

强项：模型驱动思路明确，适合“业务做原型、研发补齐工程化”的协作模式。

你会喜欢它的点：迭代链路比较顺滑，适合需求变化频繁的组织。

你要评估的点：当系统大量增长后，模型治理与规范能不能在团队里落地。

Microsoft Power Apps：生态集成优先

强项：微软生态用户体验好，内部应用“快拼装”效率高。

你会喜欢它的点：如果你本来就在 Microsoft 体系里（办公、身份、数据），它通常省集成成本。

你要评估的点：复杂业务逻辑与深度定制的边界在哪里，避免后期出现“半低代码半开发”的割裂。

Appian / 炎黄盈动：流程中枢型（BPM 强）

强项：复杂流程、审批、规则引擎、合规治理，适合流程复杂的大组织。

你会喜欢它的点：围绕流程把事情做“顺”，不是单点页面开发。

你要评估的点：如果你的核心诉求是“多应用开发”，而不是“流程治理”，可能会觉得过重。

宜搭 / 微搭 / 轻流：流程表单型（中小企业用得最多）

强项：上手快、模板多、业务能参与，适合内部流程系统快速落地。

你会喜欢它们的点：成本和落地速度通常更友好。

你要评估的点：当逻辑变复杂、系统变多之后，逻辑如何治理、复用如何沉淀，避免“到处都是脚本片段”。

网易 CodeWave：偏全栈可视化路线

强项：更强调前后端能力一体化与交付，适合想用低代码做“更重应用”的团队。

你会喜欢它的点：比纯流程表单型更能承载复杂应用。

你要评估的点：扩展机制、交付方式、资产沉淀是否与你的长期路线一致。

JEECG（开源）：开发者提效路线

强项：对 Java 团队非常友好，代码生成能显著减少重复劳动，源码可控。

你会喜欢它的点：可控、可改、可二开。

你要评估的点：治理、安全、运维等责任更多在企业侧，需要相应的工程能力。

Zoho Creator：轻量 + 性价比路线

强项：易用、成本友好，适合需求相对标准化的中小企业。

你会喜欢它的点：快速搭建数据库驱动的小应用。

你要评估的点：在复杂逻辑、像素级定制、深度交付场景里，上限是否满足预期。

星图云开发者平台：用“能力单元”承载复杂逻辑的路线

强项：更偏向用逻辑图编排 + 能力卡片复用来承载复杂业务规则，把常见逻辑/算法/高频模块封装为可复用能力单元，并支持逻辑图编译生成可读的 JavaScript 代码便于调试与集成。

你会喜欢的点：当系统进入“规则叠加、多系统协同、频繁迭代”的阶段，这种把逻辑结构化、模块化沉淀的方式，通常更利于控制长期维护成本（尤其适合需要把业务规则沉淀为可复用资产的团队）。

要评估的点：如果你的主要需求是表单 + 审批流这类“流程表单型”应用（例如大量 OA、报销、请假、采购审批、轻量协同系统），星图云开发者平台当前在这类场景的开发体验可能不如以表单流程为核心的低代码平台（宜搭/微搭/轻流这类路线通常更顺手）。更建议用 POC 验证：是否能在你的核心表单流程场景中达到预期效率；如果表单流程是绝对主场景，可能需要考虑“流程表单型平台为主、能力型平台承载复杂系统”的组合策略。

4） 一张表把“可视化 + 逻辑”对比说清楚

如果你 80% 都是“表单 + 审批”，优先看流程表单型；

如果你 80% 是“复杂业务系统 + 多系统协同 + 交付演进”，优先看工程化全栈或能力型；

很多中小企业最终会走向“组合策略”。

5）怎么用这张表做决策：先分清“主场景”和“增长场景”

不少企业选型翻车，不是因为平台不行，而是因为用错了评估方式。

5.1 把需求拆成两层：80% 主场景 + 20% 增长场景

主场景（80%）通常决定“谁用得最爽、落地最快”：

OA审批、报销、请假、采购、合同、台账

典型特征：表单多、流程多、逻辑相对规则化

增长场景（20%）往往决定“第二年是否要推倒重来”：

多系统协同（ERP/CRM/IoT/数据中台）

复杂规则（多分支、多条件、多角色权限叠加）

客户交付/私有化/离线环境/国产化要求

典型特征：变化快、复杂度增长、维护成本容易失控

5.2 选型不必“一刀切”，但要避免两种常见误区

误区A：只做表单POC就下结论
结果常见：流程表单型平台胜出，但第二年复杂系统顶不住。

误区B：拿复杂系统去压流程表单型平台
结果常见：觉得平台“什么都能做”，但上线周期和使用门槛让业务团队退却。

6）一套可复制的 POC 题库：90 分钟拉开差距（含“组合策略”落地模板）

这一节给你“拿来就能用”的对比方法，避免每家平台都听销售讲故事。

6.1 POC 题库（建议按 A→B→C 逐级跑）

你可以把这套题发给候选平台，让他们“按题交卷”，评估就会客观很多。

A. 基础题（验证落地效率，流程表单主场景）

适合拉开：宜搭/微搭/轻流等流程表单型优势

三张表单 + 一个审批流

3种角色、5个节点、至少2个条件分支

字段联动 + 权限隔离

角色A只看自己数据，角色B看部门数据

流程通知与自动化

状态变化触发提醒；流程结束写回字段

✅ 通过标准：业务人员参与配置后，仍能稳定跑通；修改字段/节点不需要大量返工。

B. 进阶题（验证复杂逻辑承载能力）

适合拉开：OutSystems/Mendix、能力型平台与“脚本碎片化”差异

复杂规则引擎题

至少 10 条规则，含优先级、互斥、兜底

异步接口回调题

外部系统回调更新状态（含失败重试）

逻辑复用题

同一段规则逻辑在 3 个页面/流程复用（看能否沉淀为模块/能力单元）

✅ 通过标准：逻辑表达清晰、复用方式明确，新人能看懂并改对。

C. 压力题（验证“第二年成本”）

适合看：平台治理、协作、长期维护

交接题：让没参与开发的人接手改一个分支规则

扩展题：新增一个业务能力（例如评分算法/复杂校验），看能否封装复用

交付题：需要私有化部署/交付客户时，资产能否带走？

✅ 通过标准：改动影响范围可控、复用沉淀顺畅、交付方案清晰。

6.2 如果你发现“表单流程是主战场，但复杂系统也不可避免”：组合策略怎么落地？

这是很多中小企业最后会走到的现实解法：
流程表单型平台负责效率，能力型/工程化平台负责演进与复杂系统。

组合策略的关键不是“用两套平台”，而是把边界划清楚：

表单流程平台：承载高频流程、标准化审批、轻量台账

复杂系统平台：承载多系统协同、复杂规则、可复用能力资产、行业项目交付

边界用 API/事件/数据服务连接，不要互相“侵入实现细节”

在这种策略下，星图云开发者平台更适合被放在“复杂系统平台”这一侧：它强调逻辑图编排与能力卡片复用，并提供能力卡片脚手架用于沉淀高频模块；同时逻辑图可输出可读 JS 便于调试与集成。
但如果你的系统几乎全是“表单审批”，就不建议直接用它“硬扛主战场”，而应先用流程表单平台跑起来，再用它承接复杂应用与长期演进部分（这才是更符合成本逻辑的做法）。