在数字化浪潮席卷而来的今天，低代码平台作为一种新兴的开发工具，受到了广泛关注。然而，正如任何新兴技术一样，低代码平台也面临着诸多争议。2021年《为什么我说低代码是“行业毒瘤”？》一文便提出了对低代码平台的质疑，认为其预设使用人群局限、暗藏变革成本、并非长期发展风口，甚至质疑其为伪需求。

那篇文章是一篇采访文章，大概率是媒体为博人眼球有意为之，才为文章取了一个这么大的标题。我从受访者的回答中可以看出他说：“低代码如果定位是帮助小白来入门行业，不是帮助从业者提升效能”的话，这样是伪需求。因为当时低代码普遍形态是以无代码为主，当无法满足需要时，通过特定方式将代码以插件的形式注入平台，作为低代码平台的内置逻辑，供设计器使用。然后就大肆宣传低代码要变革研发，能做复杂场景。

我认为如果这篇文章再严谨点，把“指望这样定位的低代码平台，来做核心业务场景”的诉求，称之为伪需求，我认为是对的。这也是许多研发人员反对低代码的核心原因之一，主次搞反了，因为这种模式下研发人员变成了辅助角色，而软件工程是一门需要技术能力的学科，让没有技术能力的人主导是违反常理的。对于软件产品公司来说，产品需要迭代规划，需要多人协作，需要工程化管理。

但是即使这种形态的低代码或无代码平台，如果定位在企业辅助场景，也是有市场有空间的。它在当企业部门之间有协同需求，但没有专业软件支撑的场景，找外包开发有不划算的场景，也是起到了补充作用。比如明道云、宜搭、得帆这类平台，做辅助场景也非常好。人家也没说非要做核心场景。这些平台明确表明自己主要支持一些辅助场景，这种专注使得它们在简单场景的优化体验上做得相当出色。对于用户来说，它们提供了一个清晰、直观的选择，使他们能够快速地构建和部署应用程序，满足日常工作的需求。这种明确的定位不仅降低了用户的使用门槛，也提高了平台的使用效率。但如果像某流一样，一上来就要用无代码颠覆，革研发的命，就有点那啥了，也就前面说的“主次搞反”。

市面上，还有一类低代码平台，特别奇怪，它的定位属于不上不下的骑墙定位。以某易旗下的低代码为例，该平台定位在中等复杂度的业务上，但似乎并没有很好地把握这一定位。在实际应用中，客户可能会发现它既不像简单的无代码平台那样易于上手，也不像低代码平台那样功能全面。这种定位上的飘忽不定使得用户难以判断到底能否满足自己的需求，从而影响了平台的推广和使用。

悲观的人正确，乐观的人向前。如果文章就写到这里就没意思了。接下来介绍那本文的重点，也就是哪些号称能做复杂场景的低代码平台，比如ClickPaaS、炎黄盈动、当然也包括我们数式Oinone。这类产品必然要在技术路径选择上要跟明道云、宜搭、得帆，这些类型平台不一样。接下来我为这类平台发发声，它们绝对不是伪需求，只是难度很大：

首先，我们要澄清一个误解：低代码平台并非仅面向初级、入门人员。

实际上，随着技术的不断发展，低代码平台已经具备了高度的可配置性和扩展性，能够满足专业研发人员的复杂需求。同时，低代码平台也提供了丰富的API和集成能力，使得开发者能够轻松地与其他系统进行集成，实现业务逻辑的快速构建。因此，低代码平台并非局限于初级人员，而是能够覆盖更广泛的开发人群。

其次，关于低代码平台暗藏的变革成本问题，我们需要正视但不必过分担忧。

任何新技术的引入都会带来一定的变革成本，包括人员培训、系统迁移等方面的投入。然而，这些成本并非低代码平台所独有，而是所有新技术都需要面对的问题。关键在于我们如何平衡变革成本与潜在收益。通过合理的规划和实施策略，我们可以将变革成本控制在可接受的范围内，并充分利用低代码平台带来的效率提升和业务创新。

再者，关于低代码是否是长期发展风口的问题，就拿《为什么我说低代码是“行业毒瘤”？》这篇文章中提到的“现在程序员缺口很大，大家都在 996，加班干活，所以我们需要一个提升效能的工具”，这个没有错，我在其他文章中也反复提到：“随着企业数字化转型，企业对研发人员的需求量大幅增加，同时对他们的要求也变得更加严格和高标准”。低代码做解决这类问题痛点的核心手段，才会反复被提及。只是数字化时代的低代码需要具备面对复杂场景的能力。用一个滑稽的话做总结：“因为市面上的低代码是毒瘤，我们要自己做一个”。

最后，我想强调的是，低代码平台并非伪需求，而是企业数字化转型过程中的重要工具。对于许多企业来说，快速构建和迭代应用程序是提升竞争力的关键。而低代码平台正是能够满足这一需求的工具之一。

19年出来创业时，我希望把低代码带进企业核心场景，推出低代码加中台理念，通过低代码平台把只是停留在理念层面的中台概念固化到技术平台中，甚至提出了没有低代码加持的中台厂商都是在刷流氓，在收割大家的智商税。在我眼里中台代表：核心业务场景、互联网技术，低代码是：新的工程化输出。我们只是用低代码的方式输出，互联网技术与业务的最佳实践。 针对复杂场景的低代码平台，如果没有把低代码平台作为核心的战略定力，是做不出来的，国外的Mendix和Odoo分别做了6年和8年才崭露头角，在中国软件公司太浮躁，能把一点做深做透的太少，市场规模是他们的第一追求。但软件行业一定是厚积薄发的行业，但凡有点名头的企业基本5年以上，数式Oinone坚信低代码平台会从辅助场景走向核心场景，坚信所有软件公司都需要具备这样的能力，我们专注低代码平台，把场景交给伙伴，恪守边界，努力为行业带来一点改变。

那企业或者软件公司如何选型能支撑复杂场景的低代码平台呢？我总结了以下三点，供大家思考：

1. 确保咱们各类场景情况能被实现

a. 找自己场景中的一个特定页面或字段交互，是低代码平台原本不支持的，去验证低代码平台在交互层面没有限制

b. 找自己场景中的一个特定逻辑，最好涉及对接第三方能力比如引入第三方开源组件，去验证低代码在逻辑层面没有限制

c. 是否改变研发习惯，适应成本有多高？

2. 验证咱们各位纬度效率有提升

a. 针对项目或产品研发过程中涉及的核心角色是否有提效

i. 后端研发是否提效，具体表现在哪些方面？难度降低还是效率提升？

ii. 前端研发是否提效，具体表现在哪些方面？难度降低还是效率提升？

iii. 跟外部系统集成是否提效？

iv. 跟业务无关的通用能力是否有足够支撑？

v. 针对测试，质量是否提升？测试工作量或回归量是否有提升？

vi. 验证低代码扩展能力，无需额外设计。任何研发人员写的逻辑都具备高度扩展能力

b. 引入低代码平台，对研发流程有没有改变，是否有提效

i. 后端研发、前端研发、测试之间协同效率是否有提升？

ii. 业务研发与通用能力研发之间协同效率是否有提升？

3. 证明低代码平台符合咱们公司未来发展的要求

a. 公司的行业特性如何跟低代码平台结合

i. 是否能遵循公司UI规范，涉及主题、布局、UI规范、logo等各种细节

ii. 行业组件扩充：能否基于低代码扩充属于自有的行业组件，在设计器中增加自有组件如页面、图表等

b. 促进销售

i. 迅速完成业务需求的概念验证（POC），以快速响应市场变化和客户需求。

c. 公司产品化发展

i. 研发专注标品，研发扩展包实现个性化，能否做到实施客户时不需要改标品？

ii. 研发专注标品 ，非研发无代码个性化实施，能否做到实施客户时不需要改标品？

iii. 标品升级带来的新特性，是否可以无缝给到每个客户？

最后推荐下自己的低代码产品数式Oinone，我们强调的低无一体的技术路线，一定能给您耳目一新的感觉。

首先，数式Oinone屏蔽了互联网架构带来的复杂性。针对专业研发和公民研发提供不同的两种方式：一种是面向公民研发的无代码设计器，另一种面向专业研发的低代码研发框架。数式Oinone都是以元数据为基础，两种方式都是在产生元数据，通过使用代码来描述元数据，可以无缝地与代码衔接，并在不改变研发习惯的情况下降低门槛、提高效率，并进行工程化管理。

低无一体不仅仅是指两种模式的结合，还包括两种模式的融合应用方式。具体来说，这种融合应用方式可以分为两种情况：

1、当开发核心产品时，主要采用低代码开发，无代码设计器作为辅助。这种方式可以提高开发效率和代码质量，同时保证产品的快速迭代和升级。

2、当需要满足个性化或非产品支持的需求时，主要采用无代码设计器，低代码作为辅助。这种方式可以快速地满足客户需求，并且避免对产品的核心代码产生影响。

简单来说，低代码模式适用于产品的迭代升级，而无代码设计器则适用于满足个性化和非产品支撑的额外需求。低代码和无代码模式在整个软件生命周期中都有各自的价值，在不同场景下可以相互融合，发挥最大的优势。

想进一步了解数式Oinone给软件公司带来怎样的效率提升，请看：多层次深度对比，一文看清数式Oinone带来的效率提升

想进一步了解笔者对中台的思考，请看：浅谈企业IT架构的十年困局