企业内部搭低代码平台，别急着选产品，我先帮你理清四条技术路线

企业内部搭低代码平台，别急着选产品，我先帮你理清四条技术路线

导语

最近两年，几乎每家大厂都在搞低代码——阿里有 LowCodeEngine、百度有 Amis、华为有 TinyEngine，市面上还有几十款商业化产品。但大多数团队一上来就问「哪个平台好用」，选了半天发现落地困难。问题不在产品，在于没想清楚技术路线。这篇文章从前端工程化角度，把企业自建低代码平台的四条技术路线拆清楚，附带选型判断标准和实战案例。

路线一：基于开源引擎二次开发

这是目前大厂最主流的选择。

以阿里巴巴的 LowCodeEngine 为例，它提供了一个最小内核的设计器框架，包含入料、编排、渲染、出码四大核心能力。你基于它搭建低代码平台，只需要做三件事：

1. 接入物料：把你们团队的组件库按照《低代码引擎物料协议规范》接入，设计器里就能拖拽使用

2. 配置设置器：为每个组件配置属性面板，控制暴露哪些参数

3. 开发插件：按需扩展，比如代码导出、版本对比、一键部署

import { init, skeleton } from '@alilc/lowcode-engine';



init(document.getElementById('lce'), {

  // 配置物料

  components: [

    // 你的业务组件列表

  ],

  // 配置插件

  plugins: [

    'CodeEditorPlugin',

    'VersionPlugin'

  ]

});



skeleton.add({

  area: 'topArea',

  type: 'Widget',

  name: 'deployBtn',

  content: DeployButton,

  contentProps: {

    action: 'deployToProd'

  }

});

优势：灵活性高，完全可控，已支撑阿里内部 100+ 个低代码平台。

劣势：需要前端团队投入人力维护，接入门槛不低。

判断标准：如果你的团队有 3 人以上的专职前端，且有多个业务线需要覆盖，走这条路收益最高。

路线二：基于 JSON Schema 配置生成

这条路的核心思路是「不用设计器，只用配置」。

百度的 Amis 是典型代表——通过 JSON 配置直接生成页面，内置 100+ 组件，数据获取、表单提交、权限控制全在 JSON 里完成。

{

  "type": "page",

  "title": "工单审批",

  "body": [

    {

      "type": "form",

      "api": "post:/api/orders/approve",

      "body": [

        {

          "type": "select",

          "name": "status",

          "label": "审批结果",

          "options": [

            {"label": "通过", "value": "approved"},

            {"label": "驳回", "value": "rejected"}

          ]

        },

        {

          "type": "textarea",

          "name": "comment",

          "label": "审批意见"

        }

      ]

    }

  ]

}

运营同学或者后端同学改 JSON，前端只负责维护模板和组件扩展。

优势：开发量极小，一个 JSON 文件就是一个页面，适合后台 CRUD 场景。

劣势：页面样式和交互能力受限，复杂联动逻辑写 JSON 很痛苦。

判断标准：如果你的场景是 80% 的管理后台页面（表格+表单），而且不想投入设计器开发，Amis 是最快的路。

路线三：自研表单引擎 + 页面编排器

如果你不满足于现成框架，想要更高的定制度，可以走这条路——自研表单引擎 + 可视化页面编排。

表单引擎方面，阿里的 Formily 是目前前端生态里最成熟的方案。它的核心能力是 JSON Schema 驱动的响应式表单：

import { createForm } from '@formily/core';

import { FormProvider, Field } from '@formily/react';



const form = createForm({

  effects: () => {

    // 字段联动

    form.setFieldState('city', (state) => {

      state.visible = form.values.country === 'China';

    });

  }

});



// 通过 JSON Schema 描述表单

const schema = {

  type: 'object',

  properties: {

    name: { type: 'string', title: '姓名', required: true },

    age: { type: 'number', title: '年龄' },

    country: { type: 'string', title: '国家', enum: ['China', 'US'] },

    city: { type: 'string', title: '城市' }

  }

};

页面编排器则可以用 GrapesJS 或基于 react-dnd 自研拖拽布局。

这套组合的优势是极致可控，适合业务逻辑复杂的企业场景。

判断标准：你们的审批流/表单规则有 100+ 种变体，且每种变体都需要动态配置，走这条路线值。

路线四：直接用商业化平台

如果你们团队前端人力吃紧，或者只是想先验证低代码能不能跑通，直接用商业化平台：

• 钉钉氚云/宜搭：与钉钉生态深度集成，适合全员数字化场景
• 金现代轻骑兵：支持源码生成，适合国企/央企信创场景
• 织信 Informat：私有化部署灵活，适合中大型企业
• 网易 CodeWave：全栈可视化，支持导出源码

商业化平台的特点是开箱即用，但面临「平台锁定」风险——应用跑起来后，想迁移出来基本不可能。

判断标准：如果你只是想快速验证低代码能不能解决某个具体问题，先买商业平台跑 3 个月，再决定要不要自建。

四路线横向对比

我踩过的坑

最后分享几个真实踩过的坑，希望能帮你绕过去：

坑一：一上来就想做设计器。

设计器是低代码平台最耗时的模块，没有之一。如果不是核心需求，先用 Amis/LowCodeEngine 的方案，别自己写拖拽引擎。

坑二：物料体系没标准化就开工。

不管你走哪条路线，先把组件协议定好——属性定义、事件回调、数据源绑定方式。协议没定，后面物料多了根本管不住。

坑三：忽略了提效衡量。

低代码平台本身不产生价值，能不能提升业务交付效率才是关键。上线前先定好指标：页面搭建时间从 X 天降到 Y 天、非技术人员可自行维护的页面占比。

收尾

企业自建低代码平台，技术选型不是第一步，想清楚「你这要解决什么问题」才是。从四条路线里挑一条你最匹配的，先跑 MVP 再迭代，而不是一开始就奔着「万能平台」去。

下一步：用一张表把你的业务场景、团队规模、技术储备列出来，对照上面的判断标准打勾，5 分钟内你就能找到自己的路线。