误区一：低代码技术是近几年才出现的技术
实际上低代码技术从上个世纪80年代就开始出现了。当时的低代码技术是以CASE（即计算机软件工程）面貌出现的，CASE技术的理念是：集成一套实现方法和相关工具，实现系统分析、设计、代码生成、系统维护的IT系统全生命周期的方法，关注业务流程、业务对象、业务规则的描述和管理，80%以上的代码自动生成。那个时候典型的CASE产品包括：Oracle CASEDesigner、GeneXus等。
随后低代码技术便经历了CASE->RAD（快速应用开发平台）->LowCode（低代码技术）->MXDP（多体验低代码开发平台）的演变过程。目前国际上最受关注的低代码技术是MXDP技术，这是一种开发工具，主要用于帮助开发者以更高的效率、更快的速度，开发出跨平台的软件系统。现实中，MXDP不仅是前端的开发工具，为了提升开发效率，通常还会提供后端到前端（BFF）集成套件，一站式完成系统开发工作。与传统的LowCode技术相比，MXDP更专注于为前端提供跨平台特性，同时在前后端自由定制方面提出了更高的要求。典型的MXDP产品有：Outsystems、Mendix、SAP、GeneXus等。
误区二：低代码平台是前端框架的拓展
从前一个话题的讨论我们知道：低代码技术关注的是整个软件应用的快速自动生成，而前端开发仅仅是软件的一个有机组成部分。合格的低代码平台不仅仅能够解决前端应用的快速开发，更需要解决应用中的复杂业务模型的定义、前后端集成、与第三方系统的集成、系统整体运行效率、应用跨平台运行等问题。
误区三：低代码平台只能开发简单应用
我们知道低代码技术的理念是通过系统分析、可视化设计、代码自动生成技术来实现各种不同软件应用的快速开发，这里的软件应用从来不限于简单应用。为此无数IT精英不断奋斗了几十年，并将继续为此奋斗下去。著名的多体验低代平台GeneXus从事低代码技术的研发已经超过了30年。也许正是由于它的简单拖拽和配置就能够迅速生成各种简单的应用并使得国民参与编程成为可能，才造成了低代码平台只能开发简单应用的错觉。从另外一个角度说，那些只能开发简单应用的“低代码平台”不能算作真正的低代码平台，建议客户在选型时擦亮眼睛。
误区四：低代码平台没有BUGS
诚然由于机器自动生成代码机制在一定程度上避免了一直困扰传统开发人员所犯的低级错误引起的BUGS，使得软件质量得到了较大的提升。但是，我们知道低代码平台本身也是由软件开发人员采用传统开发技术编写的，因此平台本身的代码质量无法避免人为错误带来的BUGS，平台需要大量的验证和完善以使平台逐步成熟。另外，在使用平台进行可视化建模过程中也会存在操作不规范，违反或超出平台约定和控制边界的情况。这就需要平台具有一定的智能性，包括提醒、自动修复、优化等功能，这样才能够保证所生成的应用在业务处理逻辑和系统运行效率等方面达到设计目标。
合格的低代码平台应该能够在保障平台本身代码质量及生成应用的代码质量两个层面进行予以最大重视和保证。并且能够提供各种手段来帮助平台使用者控制软件质量。例如：智能分析提醒引擎、模型分析报告、模型及代码级运行调试跟踪器（Debuger）、网络运行安全分析工具等。例如：GeneXus除了提供上述辅助工具外，还提供了支持DevOps的CI/CD自动化流程、知识矩阵、自动化测试集成等工具。Mendix在平台上提供了能够支持敏捷团队开发的项目管理功能。
误区五：全民编程
低代码技术的火热也将一个新术语引入了大众的视野：“国民编程/全民编程”，网络上相关话题讨论非常热闹。这种火热也难免给广大“吃瓜群众”带入一种误区：有了低代码平台普通人都能够参与软件的开发，今后不需要专业的软件开发人员了。利用低代码平台，普通人员可以参与软件的开发这一事实的确存在，尤其是那些简单的审批流程应用、数据收集类应用等非常适合相关领域的业务人员直接参与开发。由于业务人员对于需求的理解最直接，他们的直接参与消除了费时的将业务语言向IT语言转换的步骤，应用上线的周期大大缩短。
除了上述简单应用外，企业还存在大量的复杂核心应用，这些应用的流程环节更长、业务规则更复杂、需要更多的跨部门的协同。针对这些应用的开发需要顶层设计、对全局业务的理解和把控和系统化与专业化的实现方法。我们知道业务人员由于其所处的岗位限制，他们对自己所直接关联的局部业务领域（也称流程片段）非常熟悉，但他们对于全局的了解是有很大的缺陷。因此这类应用的开发并不适合业务人员的直接参与开发，他们的最佳角色应该是“产品经理”。
误区六：软件公司不需要使用低代码平台
由于担心受低代码平台技术的限制而无法满足客户的定制化开发要求，同时也受到技术人员对于低代码技术的偏见带来的抵制，软件公司对于低代码技术往往采取忽视的态度。
但在IT技术飞速发展的今天，各种新技术、新理念层出不穷。软件公司要想跟上IT技术发展的步伐就必须维持一个拥有各种专业人才的庞大团队，这会给企业带来巨大的管理负担和运营成本。特别是那些应用类软件开发商来说，能够低成本、高质量、快速交付是公司所追求的首要目标。这些公司希望不必花大量的投入在新技术研发上面，但是同时又希望能够低成本、快速利用各种新技术。这样才能够使得公司在日益激烈的竞争环境中占得先机。因此，软件公司（尤其是应用类软件公司）对于低代码平台也是有很多需求的。
软件公司在选择低代码平台时，建议选择那些综合实力强、面向专业开发人员、采用代码生成技术的平台。特别是那些能够持续提供FutureProof保障的平台商，因为这将是软件公司在未来激烈市场竞争中低成本获取技术优势的保障。而基于云架构的低代码平台可能不是软件公司的选择。
误区七：低代码平台会降低专业开发人员的作用
低代码平台利用自动化编程技术实现了很多传统程序员的重复、繁琐的手工编码工作，这不免使得许多专业开发人员认为低代码技术会降低其作用，甚至担心低代码技术会取代程序员的地位。
实际上这种担心是没有必要的。我们知道任何一个软件都是先从业务语言转换成IT语言，然后又通过架构设计、系统详细设计变成指导程序员进行开发的语言，最终通过程序员的劳动变成真正的软件这样一个过程。其中前两个环节是软件是否满足客户业务需求的关键环节，如果需求理解错误或系统设计不当，即使代码水平再高也不是客户所期望的。因此一个好的开发人员除了应该关注IT技术本身外，更应该关注对于业务的理解和对系统整体架构的把握，这样他才能够走得更远，有更好的发展前景。
反观低代码平台都是基于可视化模型驱动的开发方法，这种可视化的技术特别适合于与最终客户的业务专家进行业务沟通和设计。掌握好低代码技术对于开发人员来说是另一种能力的提升，并且是更高层次的提升。
误区八：低代码平台只能运行在“云端”
随着互联网头部企业加入低代码市场的竞争使得低代码市场处于白热化状态，互联网公司基于其云架构特点在产品宣传中不遗余力地鼓吹基于云架构低代码平台的好处，似乎低代码平台只能在云端运行。诚然“云端”有很多优势，例如：入门快、启动投资小、免运维等。这使得那些审批流应用、信息收集、信息维护等软件生命周期短的简单应用非常适合运行在“云端”。
但是企业中还存在大量的业务流程长、业务规则复杂、运行环境复杂、软件生命周期长的复杂核心应用，这些应用很难在一个技术架构共享的公有云环境中很好的运行。
首先，承载企业价值链的核心应用必须能够有效地支撑企业核心业务的有机运营。体现企业灵魂和竞争力的不是企业所拥有的设备或厂房，而是其端到端的流程体系。云平台很难同时满足所有企业客户构建个性化流程体系的要求；
其次，核心应用承载企业的核心敏感业务数据，同时在运行时需要与其它相关业务系统进行频繁的实时交互。很难想象企业愿意将这些核心应用放到公有云上运行；再者，在IT技术飞速发展的今天，新技术不断涌现，任何技术落后的软件都会失去竞争力。云平台商很难在保证平台上所有应用的运行不受影响的同时无缝地引入所必须的新技术；
最后是平台商的存活期，任何企业客户都不愿看到由于平台商的消失而使得其核心业务无法正常运营。
因此，这时企业需要能够生产源代码、并提供私有化部署能力的低代码平台来开发与运维其核心应用。