本文来自微信公众号“任向晖的科技与商业论道”，作者 任向晖。

我很喜欢的一位博主陈果昨天发了一篇公众号文章《低代码，不要以比“中台”还快的速度烂大街》。愤世嫉俗的口吻总是能够吸引眼球，果不其然，等我读到的时候，阅读量已经过万了。

我的事业身家都在零代码/低代码领域了，他又是我一直很认同企业数字化专家，还专门写一篇文章来批判低代码，搞得我晚饭都没吃好。

我当然理解他的意思，也认同文章中部分的观点。很多低代码产品缺乏新意，只是可视化开发工具的延伸，很多厂商有概念炒作的嫌疑，自然让业内砖家忍不住要抄起几块砖。在陈果之前，还有一家知名IT咨询企业的 CTO 在视频号上有过类似的表达，他的口气真是不屑一顾。市场有多少低代码，就有多少“低代码是个伪命题”的评价。我也发现传统企业软件的咨询师普遍看衰低代码，而企业 IT 管理者则普遍关注低代码。点评的人是真不知道做事情的难。

我是利益相关人士，从业于低代码领域，且看好低代码未来。我不能让这些唱衰的妄断影响用户的心智，但也不会空洞地挥舞低代码的大旗。我要尽全力说明清楚低代码的本质是什么，为什么这一代产品和过去有本质不同，为什么它的发展会有益于整个企业 IT 市场，为什么烂大街并非一件坏事。

低代码/零代码的实质是什么？

陈果可能认为低代码平台的实质是代码依赖度更低的开发工具。其实并不是这样。包括明道云在内的这一代零代码/低代码（为简便起见，后面我统称低代码）平台的实质是“应用平台”（aPaaS），低代码只是它的使用特征之一。所谓应用平台，就是 DevOps（应用开发和运维体系）的对立面。应用不再需要通过原生高级语言（Java，PHP，C#等）编写，也不再需要完整的软件开发角色分工（DBA，后端开发，前段开发，交互设计，界面设计，测试等）。真正意义上的 aPaaS 是不会有 IDE 环境的，也不会有代码编译，更不会有搭建应用运行环境的繁复过程。应用通过aPaaS搭建（我避免使用开发这两字），搭建完成后，就在 aPaaS 上直接运行。

aPaaS 对用户结构的改变是不言而喻的。因为摒弃了 DevOps 过程，非软件开发人员终于可以直接参与到应用建设的过程。有人说，市场上并不缺少开发者，为什么一定要消除对他们的依赖呢？事实是市场上就是缺开发者，更缺的是能力强的应用开发者，因为他们大多数人都在科技行业从业，很少会直接助力一般行业的数字化建设。

即使有优秀的软件开发者，为了产出高质量的企业应用，依然需要很多专业环节，比如需求分析、系统架构、产品交互设计等等。这些专业过程极其费神，也非常昂贵。对于大部分的企业软件实现，这些过程大多数是草率处理或者被忽略的。

应用平台的妙处就在于把这些专业过程全部通过平台来模式化实现，虽然牺牲了一定的灵活性，但提供了高质量和高效率。我们仅仅为了一个数据详情页，是十多位产品设计和前端开发迭代数十次以后才达到理想水平的。

模式化实现企业应用到底对灵活性的牺牲大不大呢？其实并不大。大多数的企业应用都是由业务数据的增删查改操作，工作流执行和管理，以及对业务数据的分析汇报等模式组成的。这也难怪很多企业软件都长得非常类似。即便是通过原生技术栈定制开发，开发实现过程也极度相似。所以在原生开发市场，也出现了大量的开源框架，让开发者可以提高效率。

比如国内开发者常常使用 Activity 这个开源工作流框架来实现 Workflow，用 Ants 这个前端框架来快速实现企业应用的前端界面。这也难怪陈果认为低代码并没有节省多少开发的时间。但正是这种模式近似性，让 aPaaS 有了普及运用的可能。实际上，也正是因为这种灵活度的牺牲，aPaaS 可以非常专注在企业中后台应用实现上，对其他类型的应用开发心无旁骛。陈果认为低代码并不能用来开发所有的软件，这当然是对的。

至于市场上依然有一部分 aPaaS 会生成源代码，并允许用户调整源代码，甚至使用第三方编译环境，我认为这才是陈果说的“新瓶装旧酒”。它们的实质依然是开发工具，只是可视化程度高，对代码编写的依赖度小。很不幸，在这个领域最知名的厂商 Outsystems 就是这么一个模式。即使是 IDE 模式的 aPaaS 也有价值，它至少大幅缩短了开发周期，但他们还是依赖程序员，没有接受过软件开发训练的人员是很难掌握的。

低代码不是玩具

人总有望文生义的认知偏见。说是“零代码”，“低代码”，那必定就是简单的工具。简单的工具就只能打造简单的应用，这是毫无道理的武断。Photoshop 和 After Effects 能够创造出的华彩无比的影像作品和动画，你从来没听说过要写代码；能不能写代码从来不是评价软件工具先进性的指标。过去没有，以后也不会有。尤其当应用平台已经脱身于开发工具市场之外，它提供的就是一个搭建应用的应用，至于能够设计和搭建出什么样的应用，主要依赖的是用户的创作能力，而不是工具本身能够决定的。

如果真的像陈果说的，低代码产品只可以用来完成简单的工作流和表单流转的应用，那我们不必大费周章。在 aPaaS 之外，已经有很多轻量级的 SaaS 工具可以做到了。而且，传统的 OA 套件也都能够创建自定义的业务对象和流程，根本轮不到 aPaaS 来替补。

实际上，今天的 aPaaS 能够承载的业务复杂度是可以相当高的。明道云在金融业的 ISV 伙伴已经复刻出类似于 BMC Remedy 这样的 ITSM 套件，虽然没有覆盖 100% 的业务环节，但把其中个性化程度高的流程部分解决得非常好；我们在税务科技领域的合作伙伴普华永道，完整地提供房地产行业的税务精算系统；可口可乐亚太技术中心利用明道云搭建了实验室数据管理系统，我们在交通运输的标杆客户佛山地铁和北京地铁都已经将 aPaaS 用在了非常高频的设备管理、安全管理等环节上。佛山铁路投资集团甚至专门建立了零代码实验室，让项目专家直接上手设计和搭建应用。这些事实陈果可能不知道，但是我必须让潜在用户群体知道。我们明明做了一个弹跳杆，却被业内砖家说成是垫脚石，这是有失公允的。

当然，我也承认，现代 aPaaS 产品有一个建立用户信任的过程。在这个阶段，很多用户选择将 aPaaS 用在一些局部的简单环节，先进行成熟度和可靠性验证，这是完全可以理解的。但这个过渡现象不是我们产品的标尺。

低代码不是软件业革命，So What？

陈果指出低代码并非软件业的革命，这玩意早就有了。完全正确，第一代应用平台产品诞生在上个世纪末，距离现在已经 20 多年了。是革命，也早就革命完了。我们 To B 创业者追求并非是革命机会，而是渐进的改进机会。渐进的改进，幅度大一些，持久一些，才是创造商业价值的有力途径。革命期的IT产品几乎必然是低性能的，残破不全的，只能够服务先锋性客户的。陈果先生想必非常熟悉 Gartner 的 Hype 曲线（技术成熟度曲线），aPaaS 品类早已过了那个过山车的顶峰，今天正在走进“寻常企业家”。所以 Gartner 开始把 aPaaS 作为魔力象限的研究范围。

当一个市场开始渐进改进之时，正是它开始走向成熟的时点。这时候，先发优势和后发优势都有效。aPaaS 的前身——快速开发工具（RAD）身上的缺陷开始被消除，产品能力越来越强，用户体验越来越好，有效的商业模式也开始被探索出来。在这样的市场中，创业企业不必再承受过大的不确定性风险，看好增长的市场机遇。尤其是低代码市场还没有明显的领先企业，创业者和投资人当然都卯足了劲。这也是为什么过去两年中，新出现的低代码产品比较多的原因。

不仅有这四十多家创业公司参与，阿里和腾讯都推出了自己的低代码产品。如果不是革命，只是改进，那么为什么整个市场会投入如此大的关注呢？归根结底还是因为市场大，需求旺盛。

aPaaS 可以满足不同层次的市场需求。首先它肯定能够完胜传统定制开发，即便一个项目不是 100% 能够依靠 aPaaS 实现，也可以将 aPaaS 作为主要的基石，额外做一些扩展开发即可。仅仅定制开发一项，能够覆盖的市场规模就极为惊人。在中国广泛存在的区域性软件服务企业中，大部分从事的都是定制开发服务。过去，这些需求被散乱的开发人天所满足，未来，aPaaS 将成为主要的交付基石。

其次，aPaaS 平台可以积累各种行业应用的数据模型和解决方案，通过高水平的抽象后，它也能够替代一部分专有性要求较低的行业软件产品。我们在服务实践中发现，像制造、工程、专业服务等领域，所谓的行业应用产品都可以被aPaaS替代，因为他们大多是半成品，真正要落地到每家企业，还是要做比较多的实施工作，这本质上和 aPaaS 的实现投入是一样的。而 aPaaS 还能够提供额外的灵活度。

第三，很多企业都有了“中台”的理念。当业务规模成长到一定阶段时，企业希望能够从各个应用或子系统中抽取关键业务对象数据，从而实现企业范畴内的数据一致性和共享性。aPaaS 真是特别适合干这个工作。通过一些简单的集成开发，汇入数据到 aPaaS 上，再通过 aPaaS 所提供的 API 对外进行服务。买一套 aPaaS，基本就拥有了一个数据中台的实质。这对规模以上企业是有很强吸引力的。你可以说数据中台的建设需要很多专业技术栈，但是对绝大多数行业来说，aPaaS 的内置能力就已经够了八九成了，剩下的一些细节完全可以靠补充和扩展来解决。我们的一个跨境电商客户，每天 40 万左右的订单和运单，每个单据都有三到四个工作流要实时触发，完全运行在我们的云平台上。

低代码产品的确在增多。多归多，相比较其他领域，LCAP 或 aPaaS 市场的进入门槛依然比较高。我看到 2020 年发布的最长的一个厂商列表也不过 40 多家（这其中很多依然是快速开发工具的性质）。但是在同期，CRM 产品可能有数百家，就连生产执行系统（MES）产品和厂商都有这么多。相比较各自的市场容量，aPaaS 的竞争远没有到烂大街的地步。

我们想成为最烂的那个

我其实是多么希望低代码烂大街啊。什么叫烂大街？就是人尽皆知呗。川菜烂大街，广东菜烂大街，火锅烂大街，那是因为它们都是餐饮业的主流。低代码之于企业软件，烂大街的一天就是成为主流的一天。所以，我们明道云就想成为烂大街上最烂的那个，火锅店中的海底捞。

问题是，成为海底捞真的不容易。海底捞在餐饮业依靠独特的服务理念赢取了顾客口碑，在企业软件行业，这把钥匙是什么呢？我想了二十年也没得到确定的唯一答案。但是对于 aPaaS 来说，我觉得最重要的可能是“易用性”。

易用性是打开营销获客、产品价值、渠道拓展和客户服务四个魔盒的通用钥匙。解决一个问题，就等于同时解决了四个问题。尤其是像 aPaaS 这样的复杂产品，易用性显得难能可贵。去年，国内出现了好几家完全模仿 Airtable 的产品，我想他们都看中的是 Airtable 的易用性。

陈果认为 aPaaS 面向“公民开发者”是不现实的。我认为不仅现实，而且太重要了。企业的数字化问题凭什么都要程序员解决？如果真的是这样，那几十年来的 Excel 高手们都是干什么的？理解业务，熟悉业务，掌握数字化工具，是越来越多企业内部寻求的人才对象。aPaaS 服务的就是这样一群专业用户，通过他们可以间接服务到各行各业的企业。这样的人才当然不是烂大街，但是总归比受过专业训练的程序员多得多，更重要的是他们同时是需求的提出者和满足者，省却的沟通和协作成本是惊人的。陈果先生担心低代码产品离不开专业用户的使用，这是对的，但是不要忽视这个庞大群体的存在。

所以，我们相信并坚决地服务非开发人员掌握 aPaaS 产品，把产品的易用性永远放在首要位置。一个再强大的产品，如果难以掌握，是不可能烂大街的。相反，把一个复杂产品做得容易理解，容易上手，容易解决问题，真的是一件特别有成就感的事情。我们在产品设计评审时，最常见的挑战就是功能的可理解性，而不是功能的多寡。如果我们自己内部都不能达成统一理解的，就绝对不会发布给客户。

我们自信把明道云的功能和易用性平衡得很好。市场也给了我们积极的回应。在产品推出后的 19 个月中，我们的客户上至中国人民银行这样的国家机构，下到几十人的电商团队都可以很好地运用。接下来，我们要做一个更让自己烂大街的动作。通过这篇文章，我想预告给大家，明道云将在今年春节前推出“免费版”，让人人都可以成为应用开发者的口号真正落实。好的产品，就应该放下门槛，让更多人可以接触到。

海底捞很厉害，能够免费吃的海底捞更厉害。欢迎大家下个月到免费的明道云来吃火锅。