无代码将死，低代码长存

业界说低代码是“高级外包”倒也没说错，虽然我觉得既然用的是低代码应该叫“低级外包”更合适。

低代码这个概念今年极火，争议也极大。有些人力捧，觉得以后“人人都是程序员”，也有不少人嗤之以鼻，还有很多人认为低代码是新瓶装旧酒，早已有之，或者无非就是个高级外包。

本文希望对这个当前动荡不安的领域做一点“不草就”的综合说明，想说清楚七大问题： 低代码和无代码（也称零代码）是什么关系、怎么判断一个低代码平台是否专业、国内是否有专业的低代码平台、低代码是不是新瓶装旧酒、低代码真的搞不定专业的企业应用吗、低代码不适合开发哪些应用、低代码是不是银弹。

本文对低代码相关的很多迷信和错误观点都做了比较客观的分析，希望能对促进这个行业的正确认知有帮助。

低代码和无代码是两回事

第一步得把低代码和无代码分清楚，因为这俩差异巨大，但现在业界经常混为一谈，导致很多很多问题，比如双方争论但指的不是同一个事情，厂商的口径乱，行业报告的结果不能看。

低代码专指低代码应用开发平台（LCAP），是一个被业界广泛认可的概念，头部的分析机构如 Forrester 和 Gartner 都已经发布了多年低代码开发平台的报告。如下图所示，大家可以看到这两家的报告入选的产品都很接近，特别是头部的六家简直是一模一样。这说明低代码应用开发平台已经是一个比较成熟的市场。

相反，分析机构对无代码的态度就很微妙了。虽然也有一些分析机构提无代码开发平台的概念，如 G2（当然更不用说目前混乱的国内分析机构），但 Forrester 和 Gartner 从未发布过无代码开发平台的报告。Forrester 和 Gartner 倒也不是说无代码是个伪概念，他们的共识是无代码这个词只是一个营销用语，主要用来突出一个工具无需编程基础，消除业务用户的恐惧。

‘No-code’ is a marketing term, implying the tool is for non-professional developers. — By Gartner

Businesspeople hankering to deliver their own apps love the “no-code” message. Thus, “no-code” has become a marker for products aimed at empowering business users. However, customers report that even powerful low-code platforms in some cases can’t produce apps without any coding. So what does this mean for the “no-code” promise? — By Forrester

无代码这个词通常用来形容一些细分领域的开发工具，最常见的是应用搭建平台（国外一般叫 App Builder 之类），如国外的 Appy Pie、国内的宜搭、简道云等，还可以用来形容 Airtable / AppSheet 这类在线表单工具或轻流这类的工作流工具。这几类工具差别巨大，由此可见无代码是一个相当宽泛的概念。如下图所示，甚至还有人将无代码和低代码的江湖分成十二个“门派”。

但无代码的“通用”开发平台，目前看并不存在。据我看将来也不会存在，因为开发软件必然要编写逻辑，就必然要写代码，除非哪一天人工智能能做到自动写代码。

我觉得低代码和无代码的关系有点类似于关系数据库和 NoSQL。关系数据库专指一种特定的数据库，即便多家厂商的产品实现可能千差万别，但至少提供的功能很相似，都高度遵循 SQL 标准。低代码开发平台虽然今天的标准化程度还没关系数据库这么高，但无论是 Gartner 还是 Forrester 都已经开始给出比较清晰的筛选标准，如要支持通用场景（如 UI、逻辑和数据三层都要有）、要满足专业开发需求等，随着行业发展标准化程度肯定会进一步提高。NoSQL 则只要不是 SQL 都算，不管你是 KV、wide-column、文档还是图，都可以叫 NoSQL。NoSQL 这个词热了有几年，但现在不太讲了，因为市场格局开始清晰之后，大家就不会关注过于宽泛的 NoSQL，而是根据需要关注具体的类型。我个人认为 无代码这个词将来也一样会慢慢淡出，虽然现在十二个门派很是热闹，但不出几年真正有影响力的门派肯定也不多，这时大家也就不关注无代码而是直接找具体的产品了。

本文后续只专注讨论面向通用应用开发的低代码。 低代码不是一个想吸引业务用户的用语，业务人员见了“代码”两个字就吓跑了，再低也没用，如果业务人员写不了 100 行代码的话，那 10 行也一样写不了。低代码平台主要面向专业开发，这点已经是头部分析机构的共识，虽然 Forrester 之前走过弯路，曾经也发布过面向业务人员的低代码开发平台报告，但近两年已经不再发布了，只保留面向专业开发者的低代码报告。用户数据也说明这一点，据 Creatio 调查统计，“只有 6% 的低代码开发是由业务人员完成的”，而 OutSystems 的数据是 69% 的用户是专业开发，宜创科技 CEO 宜博也曾说低代码面临“懂技术的看不上，懂业务的学不会”的尴尬。

所以无代码和低代码完全不同，无代码面向业务人员，低代码面向开发人员；无代码泛指多种开发细分领域应用的工具，低代码特指一种通用开发工具；无代码不被国际头部分析机构认可，低代码被广泛认可。

现在国内很多行业专家和分析机构经常把两者混为一谈，这对技术的价值衡量、甲方的技术规划和选型都造成很大混乱，我迫切希望大家能够把低代码和无代码区分开，集中研究具备通用能力的低代码平台。

专业的低代码长啥样

现在市场上鱼龙混杂号称“低代码”的产品很多，怎么才能快速区分是不是“专业”？很简单，找一个最专业的产品来对标。

对比 OutSystems 和很多国内所谓的低代码平台，我找出了六项区分度最高的判断标准：模型驱动、可视化开发、表达式语言、软件工程、开放集成和脚本语言。

（1）模型驱动

“模型驱动”可能是最明显的区分标志，因为刚好有一个也很流行的概念叫“表单驱动”。很多人搞不清楚这两个概念，但其实这两类产品挺好区分。

首先可以看用户手册，这样不用安装试用也能看出差别。使用模型驱动的平台比如 OutSystems、Mendix 的手册会有很大一章讲怎么做数据建模和处理，包括怎么定义实体、实体间关系、主键、唯一性、索引、数据怎么访问、筛选、分组、统计等等，还提供 SQL 或类似扩展。使用表单驱动的产品则往往手册第一章就是说明怎么定义各种表单，都是各种和界面相关的控件，比如单选多选下拉框、文本日期数字等。

其次可以看界面。下图是分别是模型驱动的 OutSystems 和某表单驱动产品的相关操作界面，大家看是不是很不一样。

（模型驱动，OutSystems）

（表单驱动）

（2）可视化开发

可视化开发不是拖拉拽做个界面（这只能叫可视化设计），而是要拖拉拽写处理逻辑。看 OutSystems 这类产品的文档，你会发现很多编程语言的基本构造都有，比如顺序 / 分支 / 循环 / continue / break、输入输出参数、局部变量 / 全局变量、struct 和 list、异常等。虽然这些东西都是拖拉拽完成，看上去没有密密麻麻的一行行代码来吓人，但也足以吓退业务人员。一下几张图都来自于 OutSystems，大家可以感受一下。

（左：逻辑开发工具箱，注意有 If、Switch、For Each 流程控制；右：一个比较简单的逻辑）

（怎么抛出和处理异常）

（3）表达式语言

表达式语言有些类似 Excel 里的公式，有表达式语言才可以做一些比较复杂的计算。下图是 OutSystems 的表达式编辑器，大家可以看到有各种操作符，还有很多内置函数，比如数学函数、字符串处理函数等。

OutSystems 这个例子看起来还比较简单，但表达式语言也可以很复杂。微软是搞语言的行家，下图是个微软 Power Fx 的例子，这个表达式是要提取一个句子最后一个单词的表达式，也挺复杂吧（说实话我看了好大一阵子才看懂）。

表达式语言也有更平易近人的设计，比如我们轻舟就是用类似 Scratch 的积木块设计。两种设计功能上是等价的，积木块设计更容易上手，Power Fx 这样的设计写复杂表达式更方便。

（4）软件工程

专业的低代码平台需要提供测试、debug、版本控制等软件工程支持。开发软件都会出 bug（低代码平台基本消除了语法层面的 bug，但对语义层面的 bug 一样无能为力），需求也总是会变。所以测试、debug、版本控制这些支持也是必不可少的。OutSystems 为什么做的最好，我觉得跟它完善的 debug 支持是分不开的。下图是 OutSystems 的 debug 界面，看起来和专业 IDE 有的一拼。

（5）开放集成

理论上，有了模型驱动等上述四大功能，开发一个不是太复杂的独立应用就够了，但典型的企业软件都是相互依赖和集成的，所以平台还需要具备能够调用外部 API 和开放 API 给别人的能力。平台如果没有这两方面的功能，开发出来的应用相互之间都没法连通和集成，全是技术债。我们看国外关于低代码的文章，经常会看到一个词叫 Shadow IT，说的就是这个问题。大家都胡乱的开发各种应用，还都集成不起来，将是一场大灾难。

（6）脚本语言

脚本语言就是用 Javas、Python、Java 等做扩展，这些其实就是正儿八经的专业编程语言了，但低代码平台会把工程复杂性都封装好，让开发者不需要配置部署环境，随手就可以写代码，写完一键发布马上可以运行。

其实上述标准和 Gartner 是很一致的。Gartner 在魔力象限报告里说：

An LCAP is characterized by its use of model-driven or visual development paradigms supported by expression languages and possibly ing…

里面模型驱动、可视化开发、表达式语言、脚本语言都提到了。

小结一下， 判断是不是"专业”低代码，可以重点看模型驱动、可视化开发、表达式语言、软件工程、开放集成和脚本语言等六个方面。

国内有专业的低代码平台吗？

国内看似已经有很多低代码平台，道一云之前做个一个系列测评，T 研究、海比等也都出过分析报告，但只要我们对照上述标准就不难看出，虽然低代码舆论很是喧嚣，但迄今为止应该说国内还很少有专业的低代码平台。

比如国内存在一类平台叫“应用搭建平台”，这些平台有些标称无代码，有些标称低代码，但即便某些厂商标称的是低代码，其实基本上是采取“表单驱动”的设计。“搭建”和“开发”二字之差，差距其实非常大。应用“搭建”平台这个概念，在 Gartner 这样的国际顶级分析机构的字典里是没有的，和“开发”平台不在一个量级。所以，大家如果看到“搭建”平台，要特别留意，即便标称是低代码的，也好仔细的对照标准去评估一下，一般按前一节的标准，这些平台是够不上的。

国内分析报告提及的产品我都瞄过很多，但看一圈下来，个人认为八成都够不上专业低代码开发平台的门槛，目前我比较了解的也就 ClickPaaS 和 iVX 可能还够得上（我也不确定，因为 ClickPaaS 不开放用户手册，没深入研究），毕竟它有模型驱动和开放集成。

这么混乱的状态让我们的 CIO 们可怎么办呢，这再次说明如果缺乏有效的标准筛选真正专业的低代码平台，势必低代码和无代码一锅粥，结果大家都被搞得稀里糊涂。

低代码真的是新瓶装旧酒吗？

关于低代码还有一种流行的观点是新瓶装旧酒，说二十年多年前的 Delphi、PowerBuilder（后称 PB）早就是低代码，但早就被时代淘汰了，今天的低代码也没戏。说这些话的大概率还是前辈。

要讲清楚这些问题得稍微 digg 一点历史，当年的 Delphi 和 PB 可是神一般的存在，因为相比同时代的其他技术（比如诘屈聱牙的 MFC）来说易用性好太多，这俩不知道做了不知道多少企业信息化应用。随手翻看一本《Delphi 开发典型模块大全》，里面尽是板材排料、进销存、文档管理、批发零售、房地产信息管理等案例。

这俩后来被时代淘汰，主要是因为时代变了，没跟上。互联网时代来了后，软件架构很快就从桌面端的 C / S 变成 Web 端的 B / S，再后来是移动 App。Web 应用和 App 对前后端的要求比桌面应用都要高很多，因为大家做网页或 App 都是要勾引用户主动来访问啊，不像桌面端的企业应用就算不好用你为了工作也得用。互联网的这个二十年，技术栈发展的越来越复杂，新的低代码技术只能一直慢慢酝酿。

但经过 OutSystems 等厂商经过十多年的积累，今天的低代码技术已经远胜当年的 Delphi 和 PB。今天的低代码要“低”的多，当年的 Delphi、PB 等如果按今天的标准，连入门的资格都没有。

我们就以当年最流行的 Delphi 为例，Delphi 虽然号称“可视化编程语言”，但也就是实现了界面的可视化开发和数据库的 ORM，所有的逻辑都是要用代码写的，包括怎么把数据显示在表格也都要写代码。我们说的六大标准里，头两位的模型驱动、可视化开发这些都没有。PB 也就比 Delphi 稍好一点，它核心的 DataWindow 可以无需代码做出增删改查，算是迈入模型驱动的门槛，但它不支持实体关系，模型驱动能力并不完整。同时 PowerBuilder 也没有可视化的逻辑开发，按今天的标准也只能在门槛徘徊。

贴两张老图让大家感受一下当年炸子鸡—Delphi。

（Delphi 的主界面，实现了用户界面的可视化设计）

（Delphi 的逻辑实现界面，得写代码）

士别三日当刮目相看，何况十多年。今天的低代码并不是新瓶装旧酒，而是新瓶新酒，里外都是新的。说新瓶是因为低代码这个概念是新的，说新酒是因为今日的 OutSystems 等专业低代码产品的能力已经远超二十年前 PC 时代的 Delphi 和 PB。

我想说低代码是新瓶装旧酒的人啊，看到特斯拉也会说新瓶装旧酒，不还是汽车吗，看到 iPhone 也会说新瓶装旧酒，不就是个手机吗，我就打打电话，发发短信。这些人啊，可能也不因为别的，可能就是因为年纪太大了。

关于低代码从 DOS 时代至今的发展脉络，阿朱在 《低代码都快烂大街了，还有人在为低代码吵架》 一文有详细介绍，感兴趣的可以看看。

低代码能开发复杂的企业应用吗？

目前业界很多人认为低代码搞不定复杂的企业应用。有人认为低代码只适合用来做“简单的工作流和表单流转的应用”或“大型应用软件的功能延伸的开发”，而“不适合开发复杂逻辑的核心业务”，但并没有说为什么。也有人认为低代码只适合“创新探索类”、“生命周期短的”等应用，但同样没有给出依据。类似的言论还很多，但都有一个共性，就是只说低代码不行，不解释，而且很多时候还把话说得斩钉截铁。

企业应用听起来高大上，但其实几十年东西了，能有多复杂呢？界面不用很时尚，不用扛百万并发，也没智能推荐啥的高级算法，其实从软件开发角度看企业应用是比较简单的。企业应用复杂主要是领域模型和业务流程比较复杂，但从前文我们可以看到，低代码平台在建模和逻辑方面的能力都是比较全面的，再通过脚本语言、开放集成等扩展机制，对于不方便低代码实现的地方，可以和专业代码开发协作实现。所以用低代码开发复杂应用，本质上没问题。

曾有文章把企业应用的复杂性分解为数据、权限、流程、算法、集成、报表等六个维度，然后逐一给出解决方案。这才是实事求是的态度。我相信任何人但凡不带偏见，深入分析的，都会发现企业应用并没有什么复杂性是低代码一定搞不定的。

而且用低代码平台开发这类应用，还有不少独特优势，如开发人员上手快（我们的经验是个把月就能用的很溜了），开发效率高，便于业务人员和开发之间的沟通（因为逻辑大多是可视化的），不容易形成孤岛（因为专业的低代码平台默认就会根据模型生成 API）。OutSystems 在其网站上特意强调：

OutSystems is well-equipped to build ERP and similar large, complex systems with the desired performance and scalability.

OutSystems 也有一些这方面的案例，做供应链、CRM、ERP 的都有。OutSystems 成立于 2001 年，那时候不开发企业应用开发什么呢？

但可能很多人会说，OutSystems 作为厂商当然这么宣扬，但目前用低代码开发复杂企业应用确实不多啊。没错，但我认为这只是时间问题。

首先，低代码技术达到成熟状态的时间并不长，即便是 OutSystems。OutSystems 虽然都成立 20 年了，但低代码表面看似简单，其实是一个相当复杂的技术体系，背后涉及核心的编程语言层面的设计，比如 DSL、类型系统、泛型等等，还有怎么 diff、debug、undo，都不容易。另外低代码平台还需要不断追赶这 20 年变化极大的技术环境。20 年前是 C / S、.Net，后来流行 B / S、Java，再后来又得搞 App，操作系统从 Windows 变成 Linux，现在又面临从 SOA 到微服务的转型。

OutSystems 的主任工程师 Tiago Simões 曾介绍过 20 年来 OutSystems 的发展，可以看到 OutSystems 一边一直到补功能，直到 2014 年的 9.0 版本支持数据聚合处理才算比较完整，另一边一直在努力追赶技术趋势，直到 2016 年的 10.0 版本一口气推出 Client-Side Logic、Local Storage、异步、Reactive 等功能才算对移动 App 有较好的支持。这玩意是不做不知道，一做吓一跳，我们是做了轻舟低代码才知道这个东西很难。

更重要的可能是非技术因素。大部分企业对 CRM、ERP 的定制需求还没那么高，相比用低代码从头开发来说，采用 Saleforce、SAP 这样的套装软件实施，再做一些二次开发是更合适的选择。这也解释了为什么 Saleforce、ServiceNow 这样的 SaaS 巨头都有自己的低代码平台，而西门子会收购 Mendix。另外 ERP 这样的企业软件实施强依赖咨询经验，这不是低代码能解决的，而业界有经验的咨询顾问显然更熟悉 SAP 这样的产品，也没有意愿改变。专业程序员对低代码抵触也非常大，好不容易练就一身武艺，用了低代码好像都没用了？业界越是宣传用低代码开发快多少倍，开发团队可能越抵触。

总之，业界流行说低代码不能做 CRM、ERP 这类复杂的企业应用，这一说法很多人讲，但都没有根据。从技术原理出发，低代码最适合做的恰恰就是企业应用。目前用低代码做复杂企业级应用的 case 还不是很多，是因为低代码技术也就刚成熟不久、定制需求还不够强（套装软件能满足）或者行业不愿做，并不能说明它做不了。

低代码不适合开发哪些类型的应用

很多专家啊，不但错误的认为低代码搞不定复杂企业应用，还在低代码适合哪些类型的应用上也说错了。

主流低代码平台真正不太擅长的，是那些有各种特殊要求的应用，比如：

• 对算法和复杂数据结构要求比较高的：我想不会有人想到用低代码平台去刷 LeetCode 题、打 ACM 比赛的吧。这里有个细微的地方是要区分是业务逻辑比较复杂还是算法逻辑比较复杂，业务逻辑复杂对低代码来说不是问题，算法逻辑复杂才是问题。那啥叫业务逻辑复杂呢，就是业务人员总之是说的清楚，或者是能理解的；啥叫算法逻辑复杂呢，就是业务人员只能给个目标，具体怎么实现是不管的，就算解释也是一脸闷逼的听不懂的。
• 对界面要求特别高的：比如游戏或抖音、云音乐这样的社交娱乐型的应用。低代码平台可不擅长做酷炫的界面。（也有一些特定类型的低代码平台如 App Onboard 是面向游戏开发的，iVX 前端能力比较强，但都比较小众，不在本文讨论范围之内）
• 头部互联网级应用：头部互联网应用用户量巨大，为了优化性能有很多很多 trick，前后台技术架构非常复杂，低代码平台的实现是比较标准的数据库 / 逻辑 / 界面三层架构，无法满足性能需求。注意这不是说所有互联网应用都不合适，只是指那些用户量特大的头部应用。
• 分析和智能化应用：分析类应用自然应该用更专业的 BI 工具，智能化应用也应该用更专业的机器学习平台等工具。
• 系统软件、科学计算等其他专业性很强的应用。这个不多说了，估计也没谁想用低代码来做，但多说一句，虽然这些系统的内核肯定不适合低代码开发，但界面可是很适合，我们轻舟低代码产品正是脱胎于云计算平台的界面开发。

现在大家应该可以发现很多业界流行的观点说低代码适合这个那个的其实也都是错的，比如：

• 说低代码适合“简单的工作流和表单流转的应用”：事实上专业的低代码并不见得特别适合这类应用，比如 Gartner 就说 OutSystems 这方面的支持还不太好。其实最适合这类应用的反而是那些“表单驱动”的产品，这些产品并非专业的低代码平台。专业的低代码平台搞这些也不是完全不行，但属于大炮打蚊子，性价比不高。
• 说低代码适合“生命周期短的应用”：事实上如果你用 OutSystems 这样“最专业”的低代码平台去做营销活动页这样“生命周期短的应用”，你肯定会欲哭无泪。为什么？因为营销活动页对界面的要求很高。
• 说低代码适合“创新型应用”：有篇文章按 Gartner 的方法把应用分成基础设施型（如 ERP）、差异化型（如 CRM）和创新型应用，说前两类应用低代码就别碰了，都是传统 IT 的菜，低代码就搞搞创新型应用，这个说法也不对。互联网 App 算典型的创新型应用吧，上面已经说过这个低代码搞不定。

低代码不是银弹，不要过度神化

上面我们说低代码很适合开发典型的企业应用，优点明显，如开发人员上手快、开发效率高、增进沟通和集成等，但也不要认为低代码是银弹，用了什么问题都解决了。原因主要有以下三个方面。

1）开发工具只能解决软件研发的部分问题。作为开发工具，低代码可以加快在需求比较明确时的软件交付，也可以在大方向比较明确但具体需求不明时加快软件的迭代更新。但企业应用和企业的经营管理方式、业务方向、业务流程、组织架构密切相关，和人密切相关，这些方面如果有问题，软件都不知道怎么做，这都不是开发工具所能解决，该请咨询还是得请咨询。低代码就像特种兵，当兵作战能力是强，但如果将帅不行，战略战术拉垮，也打不了胜战。

2）低代码能提升多少开发效率缺乏权威数据，不要有太高预期。业界有很多对低代码开发效率的宣传，最多的是说什么提升 10 倍啦，这些一看就是胡扯。一些厂商和分析机构会发布提效数据，看似效果特别好，但因为前面说的无代码和低代码没分清，这些数据不可信。无代码工具因为都是面向特定类型的应用高度优化的，提效明显很正常的，但不通用。专业的低代码厂商如 OutSystems、Mendix，反而不敢宣传提效多少倍，所以一个厂商宣传的效果越好，就越不可能是专业的低代码平台。从我们的经验看，用低代码做一些小系统确实挺快，但上了规模后还能是不是有数倍提升，我觉得也不大可能。

3）行业典型的项目制限制了低代码的价值。低代码平台因为可视化、效率高，最适合业务和开发密切沟通合作，快速迭代。但当前甲乙方之间典型的项目制要求双方提前签订详细的合同和 SOW，这就把本来可以敏捷开发的生生打回到瀑布模式，这样低代码快速迭代的价值就很难体现。项目制存在太久，不是一时半会改的了的。

小结

最后做个小结：

• 无代码和低代码不是一个层次的概念。低代码是以 OutSystems、Mendix 等产品为代表，主要面向专业开发的通用应用开发平台；无代码则是一个营销用语，用于形容很多种面向业务人员的工具，如应用搭建、在线表单、工作流等。不存在无代码的通用应用开发平台。
• 要判断一个低代码平台是否专业，可以重点看模型驱动、可视化开发、表达式语言、软件工程、开放集成和脚本语言等六个方面。对照这些标准，不难看出迄今为止应该说国内还很少有专业的低代码平台，虽然舆论甚是喧嚣。
• 业界关于低代码适用场景的观点大多数都是错的。比如业界很多人讲低代码搞不定复杂的企业级应用，但都毫无根据。从技术原理出发，低代码其实最适合做的就是企业应用，即便是 CRM、ERP 这样复杂的应用；业界认为低代码适合做“简单的工作流和表单流转的应用”、“生命周期短的应用”、“创新型应用”等观点也都是错的，这些应用很多恰恰不适合低代码。
• 低代码不适合做的应用是对算法、界面、性能、分析和智能化等专业性要求高的应用。
• 低代码对企业应用开发价值明显，但也不是银弹，不要过度神化。

对甲方来说，我认为 CIO 们应该从试点应用做起，通常来说要求自己的团队用低代码的阻力会很大，但可以要求乙方用低代码，降报价。对乙方，我觉得短期很难卖平台，最好是和甲方谈个人力外包模式，避免项目制的僵化。业界说低代码是“高级外包”倒也没说错，虽然我觉得既然用的是低代码应该叫“低级外包”更合适。

最后的最后，我再次呼吁分析机构能够区分低代码和无代码，聚焦分析面向通用应用开发的低代码开发平台，让产出的报告具备参考价值。