网上关于低代码的争论已久，每次有厂家宣传自己的产品多好用，或者提问低代码平台好不好用的问题时，底下都是唱衰一片，很少能有正面的评价。

这样的现象不难看到，从低代码诞生之初，这种舆论和怒火几乎就没有停止。为什么程序员和组织者不能接受低代码，是因为低代码“降本增效”的愿景阻碍了公司的发展前途吗？

情况恰恰相反，现在低代码平台正是因为没有实现最初“提效”的承诺，才导致如今不温不火的局面，甚至到了草木皆兵的时刻，要理解这样的原因，我们必须先看看现在市面上的低代码平台都有什么特点。

低代码平台的困境

将现在的低代码平台进行主流分类，可以分成 3 种：

1.针对业务人员使用，也就是所谓的零代码。无需任何专业开发者介入，由几个 Saas 拼成的。

通常的适用场景就是 BI/工作流/表单/在线表格，主要给业务人员使用，有权限和人员管理等。（例如明道、简道、宜搭...名字后带”云“的大多是这种模式）

2.针对企业推出的内部开发框架，需要开发者，整体需要安装到企业内部。

不对个人开发者开放，无法生成单独应用代码并独立部署的；（例如：Zoho、Power Platform、活字格、轻流...）

3.需要部分研发人员，能生成代码和框架，将应用导出并部署到其他平台或服务器上的，但业务人员没法用（如 Mendix、iVX、轻舟、灵犀、odoo、无远、牛刀...）

我们可以分点来讨论下，为什么现在的低代码平台在推广过程中会受到这么大的阻碍。

1.程序黑盒

低代码的优势在于高度集成和抽象的组件模板，但所谓成也萧何、败也萧何。

因为高度封装的功能模块不可视，在开发时一旦遇到 Bug、性能等问题，由于不清楚低代码内部的实现逻辑，问题排查无从下手，代码调试要反复切换界面，开发人员只能等官方人员的调试和修改，自己是没有任何办法修理 bug 的。

大部分的低代码平台实际上并不具备语言属性，更像是一个为企业定制好的产品，因为无法生成代码，内部逻辑又不能进行整修，一旦低代码平台出现什么事故，或者跑路不干了，就意味着在低代码平台上付出的所有心血都付之一炬，没有任何讨还的可能。

这意味着把自己的命悬在别人的刀下，哪怕能换得一些效率的提升（能不能提升可能还得打一个问号），损失的却是自己的所有主动权，甚至命脉。因此，作为一个技术的高管，是不敢贸然采用这种方案的。

2.不信任，和开发者自身的实力下降

低代码平台通过拖拽的方式生成应用，但不生成代码，这意味着程序员对这个东西是陌生的，哪怕在日新月异的互联网技术人群中，学习新东西是一直要保持的习惯，但对于一种“根本不生成代码”的平台，他们天生就怀着抵触心理，而且是水平越高的程序员，抵触就越严重；

一方面，这意味着放弃他们的强项，踏入一个完全未知的陌生领域，跟所有人在一个水平线上“同台竞技”，另一方面，长期使用低代码，或是不生成代码的产品开发，必然造成专业能力的退化，这意味丢掉饭碗、丧失竞争力，没有程序员会在这样的情况下选择相信一个低代码平台

3.功能不完备

据 Gartner 统计，当前，国内 LCAP（低代码应用开发平台）渗透率尚不足 5%。

首要的问题就在于，供应端的功能供给不足，由于部分行业的场景复杂，表单驱动型和基于 BPM 的低代码产品不能够满足要求，这也是市面现存的低代码平台最核心的痛点：开发能力不足。

如果说一个低代码平台真能实现 5 倍 10 倍开发效率的提升，在增效的前提下引用灵活的代码接口处理定制化的需求，哪怕是冒着以上两种风险，在这样的利益诱导下，很多公司也会选择铤而走险。

但低代码平台自身的能力不足，就意味着一切美梦都只是泡影，只要生产力的需求没有提上来，低代码再怎么宣传和推广也是无济于事，B 端 C 端用户们会用使用体验做出自己的选择，目前的局面就是这种解释的最好反映。

通过上面的论述，我们可以发现，不生成代码的低代码平台，本身可能就是个伪命题。

我个人对不生成代码的平台很难抱有认同，就是这个原因，而在能生成代码的平台中，国外有 Mendix、Outsystems 做得比较成熟和完备。

国内有网易的 Codewave （但只面对企业）、牛刀（功能缺失严重，架构也比较老）、iVX（相对较好）、odoo（前端后端不分，成本高）等等，以后我会出一篇更详细的讨论生成代码式的低代码平台点评，欢迎大家关注捧个场。