万字长文讲透低代码 | IDCF

来源：冷技术热思考 

作者：风轻扬

按规则这篇应该叫做“数字技术名词解释—低代码”，但之前的名词解释篇都是一两天草就，这篇磨蹭了半个多月，七七八八写了过万字，于是做一把标题党。

低代码这个概念今年极火，争议也极大。有些人力捧，觉得以后“人人都是程序员”， 又有不少人嗤之以鼻，如有ERP老兵讥讽《低代码，不要以比“中台”还快的速度臭大街》，有ThoughtWorks中国某徐姓CTO怒斥《“行业毒瘤”低代码》，还有很多认为低代码是新瓶装旧酒，早已有之，或者无非就是个高级外包。可惜的是，无论支持还是鄙夷，各路专家写文都是“草就”，至今也没一篇三观正且详实的。阿朱的几篇三观是正，但行文也过于简明，可能懂的自然懂，不懂的还是不懂。

本文希望对这个当前动荡不安的领域做一点“不草就”的综合说明，想说清楚七大问题：

• 低代码和无代码（也称零代码）是什么关系？
• 怎么判断一个低代码平台是否专业？
• 国内是否有专业的低代码平台？
• 低代码是不是新瓶装旧酒？
• 低代码真的搞不定专业的企业应用吗？
• 低代码不适合开发哪些应用？
• 低代码并非银弹。

鉴于这个领域现在实在太乱，希望大家能多转发，让更多的人正确理解低代码。

一、低代码和无代码是两回事

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

低代码专指低代码应用开发平台（LCAP），是一个被业界广泛认可的概念，头部的分析机构如Forrester和Gartner都已经发布了多年低代码开发平台的报告。

如下图所示，大家可以看到这两家的报告入选的产品都很接近，特别是头部的六家简直是一模一样。这说明低代码应用开发平台已经是一个比较成熟的市场。

相反，分析机构对无代码的态度就很微妙了。虽然也有一些分析机构也提无代码开发平台的概念，如G2（当然更不用说目前混乱的国内分析机构），但Forrester和Gartner从未发布过无代码开发平台的报告。

Forrester和Gartner倒也不是说无代码是个伪概念，他们的共识是无代码这个词只是一个营销用语，主要用来突出一个工具无需编程基础，消除业务用户的恐惧。

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

— By Gartner

(https://appian.com/resources/resource-center/analyst-reports/gartner-quick-answer-low-code-vs-no-code-dev-tools.html)

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

(https://go.forrester.com/blogs/watch-your-language-low-code-and-no-code-are-not-the-same/)

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

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

我觉得低代码和无代码的关系有点类似于关系数据库和NoSQL。关系数据库专指一种特定的数据库，即便多家厂商的产品实现可能千差万别，但至少提供的功能很相似，都高度遵循SQL标准。

低代码开发平台虽然今天的标准化程度还没关系数据库这么高，但无论是Gartner还是Forrester都已经开始给出比较清晰的筛选标准，如要支持通用场景（如UI、逻辑和数据三层都要有）、要满足专业开发需求等，随着行业发展标准化程度肯定会进一步提高。

NoSQL则只要不是SQL都算，不管你是KV、wide-column、文档还是图，都可以叫NoSQL。NoSQL这个词热了有几年，但现在不太讲了，因为市场格局开始清晰之后，大家就不会关注过于宽泛的NoSQL，而是根据需要关注具体的类型。

我个人认为无代码这个词将来也一样会慢慢淡出，虽然现在十二个门派很是热闹，但不出几年真正有影响力的门派肯定也不多，这时大家也就不关注无代码而是直接找具体的产品了。

本文后续只专注讨论面向通用应用开发的低代码。低代码不是一个想吸引业务用户的用语，业务人员见了“代码”两个字就吓跑了，再低也没用，如果业务人员写不了100行代码的话，那10行也一样写不了。

低代码平台主要面向专业开发，这点已经是头部分析机构的共识，虽然Forrester之前走过弯路，曾经也发布过面向业务人员的低代码开发平台报告，但近两年已经不再发布了，只保留面向专业开发者的低代码报告。

用户数据也说明这一点，21CTO在《低代码开发可不低，用户仍需要与IT技术部门联手》一文中提到据某统计“只有6%的低代码开发是由业务人员完成的”，OutSystems的数据是69%的用户是专业开发，宜创科技CEO宜博也曾说低代码面临“懂技术的看不上，懂业务的学不会”的尴尬。

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

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

二、专业的低代码长啥样

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

哪个产品才是最专业的？我们可以先看为什么低代码这两三年才热起来？不是因为Salesforce这样的SaaS厂商，也不是Appian这类BPMS厂商，这轮低代码热其实主要是因为OutSystems。

OutSystems虽然也早在2001年就成立，但之前一直“猥琐发育”，2018年D融资了$3.6亿，才突然引爆市场。无论Forrester还是Gartner都把OutSystems列入领导者象限，阿朱说他最推崇的低代码平台就四个，OutSystems也是其中之一。所以，OutSystems就是专业低代码平台的代表。

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

2.1 模型驱动

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

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

（模型驱动，OutSystems）

（表单驱动）

2.2 可视化开发

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

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

（怎么抛出和处理异常）

2.3 表达式语言

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

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

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

2.4 软件工程

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

2.5 开放集成

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

2.6 脚本语言

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

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

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

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

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

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

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

比如阿里今年一直鼓吹的宜搭，宣称是“低代码”应用搭建平台，但其实是一个“表单驱动”的“无代码”平台。阿里其实是打了个擦边球，说宜搭是“搭建”平台，没说是“开发”平台，你要说他过度宣传也算不上。但“搭建”和“开发”二字的差距可大了，“搭建”的意思是基于一些成熟模块组装应用，一旦遇到既有模块不够用的时候就歇菜。

国内很多分析报告提及的产品大部分我都瞄过，但看一圈下来，个人认为也就ClickPaaS可能还够得上（我也不确定，因为ClickPaaS不开放用户手册，没深入研究），毕竟它有模型驱动和开放集成，其他的门槛都够不上。

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

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

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

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

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

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

我们就以当年最流行的Delphi为例，Delphi虽然号称“可视化编程语言”，但也就是实现了界面的可视化开发和数据库的ORM，所有的逻辑都是要用代码写的，包括怎么把数据显示在表格也都要写代码。我们说的六大标准里，头两位的模型驱动、可视化开发这些都没有。

PB也就比Delphi稍好一点，它核心的DataWindow可以无需代码做出增删改查，算是迈入模型驱动的门槛，但它不支持实体关系，模型驱动能力并不完整。同时PowerBuilder也没有可视化的逻辑开发，按今天的标准也只能在门槛徘徊。

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

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

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

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

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

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

目前业界很多人认为低代码搞不定复杂的企业应用。

如ERP老兵果总在《低代码，不要以比“中台”还快的速度臭大街》一文中认为低代码只适合用来做“简单的工作流和表单流转的应用”或“大型应用软件的功能延伸的开发”，认为“不适合开发复杂逻辑的核心业务”。然而果总并没有说为什么。

“技术领导力”在《如何用低代码搞垮一家公司？》一文中认为低代码只适合“创新探索类”、“生命周期短的”等应用。同样，也没有给出依据。

类似的言论还很多，但都有一个共性，就是只说低代码不行，不解释，而且很多时候还把话说的那个斩钉截铁。很多人还真的把自己当回事啊。

企业应用听起来高大上，但其实几十年东西了，能有多复杂呢？界面不用很时尚，不用扛百万并发，也没智能推荐啥的高级算法，其实从软件开发角度看企业应用是比较简单的。

企业应用的复杂主要是领域模型和业务流程比较复杂，但从前文我们可以看到，低代码平台在建模和逻辑方面的能力都是比较全面的，再通过脚本语言、开放集成等扩展机制，对于不方便低代码实现的地方，可以和专业代码开发协作实现。所以用低代码开发复杂应用，本质上没问题。

这也不是我一个人的观点，明道云CEO任向晖写过一篇《APaaS搞不定复杂的应用，是这样吗？》，把企业应用的复杂性分解为数据、权限、流程、算法、集成、报表等六个维度，然后逐一给出解决方案。这才是实事求是的态度。我觉得任总的分析已经比较充分，我也不再展开说了。我相信任何人但凡不带偏见，深入分析的，都会发现企业应用并没有什么复杂性是低代码一定搞不定的。

而且用低代码平台开发这类应用，还有不少独特优势，如开发人员上手快（我们的经验是个把月就能用得很溜了），开发效率高，便于业务人员和开发之间的沟通（因为逻辑大多是可视化的），不容易形成孤岛（因为专业的低代码平台默认就会根据模型生成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的发展（https://medium.com/outsystems-engineering/whats-not-new-in-outsystems-a-product-timeline-c781acd400cb#），可以看到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是面向游戏开发的，不在本文讨论范围之内）。
• 头部互联网级应用：头部互联网应用用户量巨大，为了优化性能有很多很多trick，前后台技术架构非常复杂，低代码平台的实现是比较标准的数据库 / 逻辑 / 界面三层架构，无法满足性能需求。注意这不是说所有互联网应用都不合适，只是指那些用户量特大的头部应用。
• 分析和智能化应用：分析类应用自然应该用更专业的BI工具，智能化应用也应该用更专业的机器学习平台等工具。
• 系统软件、科学计算等其他专业性很强的应用。这个不多说了，估计也没谁想用低代码来做，但多说一句，虽然这些系统的内核肯定不适合低代码开发，但界面可是很适合，我们轻舟低代码产品正是脱胎于云计算平台的界面开发。

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

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

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

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

• 开发工具只能解决软件研发的部分问题。

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

• 低代码能提升多少开发效率缺乏权威数据，不要有太高预期。
  

业界有很多对低代码开发效率的宣传，最多的是说什么提升10倍啦，这些一看就是胡扯。一些厂商和分析机构会发布提效数据，看似效果特别好，但因为前面说的无代码和低代码没分清问题，这些数据不可信。

比如阿里“宜搭”的数据说平均将应用开发成本从17.5人天提高到3.5人天，提效500%，但前面说过“宜搭”是无代码工具。无代码工具因为都是面向特定类型的应用高度优化的，提效明显很正常的，但不通用。

专业的低代码厂商如OutSystems、Mendix，反而不敢宣传提效多少倍，所以一个厂商宣传的效果越好，就越不可能是专业的低代码平台。从我们的经验看，用低代码做一些小系统确实挺快，但上了规模后还能是不是有数倍提升，我觉得也不大可能。根据我们的初步经验，我们觉得提升1到2倍是一个比较合理的预期。

• 行业典型的项目制限制了低代码的价值。

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

小结

最后做个小结：

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

对甲方来说，我认为CIO们应该从试点应用做起，通常来说要求自己的团队用低代码的阻力会很大，但可以要求乙方用低代码，降报价。

对乙方，我觉得短期很难卖平台，最好是和甲方谈个人力外包模式，避免项目制的僵化。业界说低代码是“高级外包”倒也没说错，虽然我觉得既然用的是低代码应该叫“低级外包”更合适😄。

最后的最后，我再次呼吁分析机构能够区分低代码和无代码，聚焦分析面向通用应用开发的低代码开发平台，促进这个行业的认知统一，产品的标准化，这样才能够推动行业发展。

无代码将死，低代码长存！

7月【冬哥有话说】研发效能工具专场。今晚8点，周文洋《微软DevOps工具链的 "爱恨情仇"（Azure DevOps）》，关注公众号回复“效能”可获取直播地址。