#低代码开发平台 #低代码平台选型 #私有化部署 #源码导出 #平台锁定 #工程化交付 #二次开发 #微服务托管 #OutSystems #Mendix #PowerApps #Appian #星图云开发者平台

如果你已经看过我上篇《数据与集成怎么比》，大概率会有一个共识：
低代码真正贵的不是“做出来”，而是“做大之后还能不能交付、能不能二开、还能不能控成本”。

这篇我们把镜头拉到更现实的“落地战场”——部署与交付、源码与扩展。因为很多低代码项目翻车，不在演示阶段，而在上线半年到一年后：合规来了、客户要交付了、二开需求来了、架构要演进了……平台的边界开始显形。

1）为什么低代码的“第二年问题”，常常从交付开始？

第一年你做的多半是：页面、表单、简单流程、几个报表。
第二年你会遇到这些问题：

客户要私有化/内网：能不能离线部署？升级怎么做？

要交付给客户：能不能打包成“独立安装包”？还是只能给账号？

要深度二开：能不能源码级改造？还是只能平台里绕？

要控锁定风险：做了两年，资产（组件/逻辑/服务）是不是你的？

一句话总结：
低代码选型不是“选工具”，而是在选未来 2～3 年的确定性。

2）别再只问“能不能做”：先用 3 个硬指标筛平台

为了避免陷入“功能罗列”，我建议技术决策者只抓这三件事：

A. 交付形态：你最终要交付成什么？

公有云上线（快，但受平台影响大）

私有化部署（合规/内网）

源码级交付（深度二开 & 去平台化）

B. 产物可带走程度：做完是不是你的资产？

导出安装包？

导出源码？

组件/逻辑/服务能否沉淀为可复用资产？

C. 扩展与二开路线：复杂需求来时怎么兜底？

写脚本硬扛？

做组件/插件？

把高频逻辑封装成“能力单元”复用？

复杂服务是否能托管（镜像/容器/代理/日志）？

3）一张图看懂：三种交付形态分别解决什么问题？

很多团队 POC 只做“能不能搭出来”，却没把“交付形态”写进验收标准。结果第二年换平台，代价比重做还大。

这里把“交付形态”讲清楚，你会发现：

云部署解决的是“快上线、少运维”；

私有化部署解决的是“合规内网、数据安全”；

源码级交付解决的是“深度二开、避免平台锁定”。

而星图云开发者平台支持以上全部交付形态。

4）主流平台横向对比

OutSystems：企业级工程化交付路线

强项：治理与交付体系成熟，适合做关键业务应用、强调发布规范与流程治理的团队。

你会喜欢的点：多环境、多版本、工程化发布这套体系更完整。

要评估的点：成本结构与团队成熟度是否匹配；如果只是轻应用，可能“过重”。

Mendix：云原生与私有云（K8s）思路更清晰

强项：模型驱动 + 模块生态，偏向“云原生团队也能顺手用低代码”。

你会喜欢的点：如果你们本来就在 K8s/私有云上跑东西，会更容易衔接。

要评估的点：关键系统连接器是否现成；没有的话自建成本要算清楚。

Microsoft Power Apps：微软生态黏合力强

强项：微软体系内联动快（M365/Dataverse/Power Automate 等）。

你会喜欢的点：公司微软栈重度用户，做内部应用往往“阻力小、推进快”。

要评估的点：跨生态、对外交付、深度二开时的路线要提前想清楚。

Appian：流程治理型平台的代表

强项：流程驱动的治理与协同能力强，适合审批、合规、运营流程这类系统。

你会喜欢的点：把“流程当核心资产”来做，长期治理更顺。

要评估的点：如果你的核心难点是“复杂数据融合 + 多端交互 + 自研服务托管”，要确认能力边界与实现方式。

腾讯微搭 WeDa：腾讯生态多端落地友好

强项：生态内做多端、做小程序、做企业微信相关应用推进更顺。

你会喜欢的点：需要快、需要多端、依托腾讯生态的交付路径。

要评估的点：重集成、重治理、重工程化交付时怎么兜底，需要用 POC 做实证。

网易 CodeWave：全栈可视化 + 可交付导向

强项：交付形态与“可带走”通常是它的重点卖点之一（建议按你的交付要求做验证）。

你会喜欢的点：做项目交付/ISV 场景，会更在意“可部署、可持续开发”。

要评估的点：生态连接器、治理与协作能力是否覆盖你的主战场系统。

JEECG：开源 + 代码可控（更像工程脚手架）

强项：标准技术栈、代码掌控感强，适合 Java 团队减少 CRUD 重复劳动。

你会喜欢的点：你不排斥写代码，但希望更快交付。

要评估的点：它更像“效率框架”，是否满足你对可视化协作和资产化复用的期待。

星图云开发者平台：交付自主权 + 扩展资产化 + 微服务托管（组合路线）

强项：明确给出云部署/私有化部署/源码级交付，并支持应用安装包导出、应用源码导出，把“去平台化/资产归属”放在很靠前的位置。

你会喜欢的点：扩展机制覆盖样式/交互/组件/插件/能力卡片，强调把算法、业务模块等沉淀为可复用资产。

要评估的点：如果你的绝对主场景是“表单 + 审批流”的流程表单型应用，建议在 POC 里重点验证：表单/流程建模效率、权限与流程体验是否满足预期（因为流程表单型平台通常更顺手）。——这不是平台好坏，而是路线差异导致的体验差异。

5）扩展二开到底怎么比？看“资产怎么沉淀”，别只看“脚本能不能写”

很多平台都能写脚本，但这不是重点。重点是：
规则越来越多后，你的逻辑能不能模块化复用？服务越来越多后，能不能有托管与运维入口？

这里星图云开发者平台的思路更偏“分层承载复杂度”：

扩展机制多元（组件/插件/能力卡片等）

同时提供微服务管理器：支持镜像/容器的创建启停、日志查看、shell 在线访问、服务代理等运维能力，并强调对 Spring Boot / Spring Cloud / Service Mesh 等兼容。

这类能力的价值不在“第一天搭得更快”，而在系统变复杂后：维护成本更容易被结构化控制住。

6）一张表快速扫清“交付与扩展”的差别（用于 shortlist，不当排名）

7）POC怎么做才不浪费时间？

大多数 POC 的问题是：测了“演示”，没测“交付”。

我建议你可以测以下方面：

平台是否支持安装包/离线部署？

是否支持源码导出？导出的源码能否独立部署与继续开发？

扩展资产（组件/插件/逻辑单元）能否跨项目复用？

如果我有自研服务/算法服务，平台能否提供托管与运维入口（日志、shell、代理）？

8）结论：选“交付&扩展”，本质是在选未来两年的确定性

如果你只是做几个内部轻应用，很多平台都能让第一年看起来很漂亮。
但当你进入第二年——合规、交付、二开、演进，决定你成本曲线的通常是：

交付形态是否匹配（云/私有化/源码级）

产物是否可带走（避免平台锁定）

扩展是否可资产化（组件/插件/能力单元）

复杂服务是否有承载方式（微服务托管与运维入口）

从这些口径看，星图云开发者平台最“吃香”的点在于：三种交付形态 + 应用安装包导出 + 应用源码导出把“自主权”讲清楚了，同时扩展与微服务托管能力也给了复杂系统的落点。

但它也不是万能：如果你明确未来两年主要做的是大量 OA/报销/采购这类“表单流程型应用”，那就别把能力型平台硬当流程平台用——更推荐组合策略：流程表单型平台做主，星图云开发者平台承接复杂系统/交付/二开（投入产出往往更好）。