作者 | 千鸟

出品 | CSDN云计算（ID：CSDNcloud）

2021年底，CSDN面向行业开发者和高校学生开发者，展开了关于“低代码”的开发者调研活动。基于调研数据，CSDN提出了对低代码发展趋势的五大方向。在随后举行的 《CSDN 企业数字化之路——低代码发展研讨会》北京站上 CSDN 和行业大咖针对这五大方向展开深入研讨，共同输出以下对低代码的洞察观点。

观点一：低代码未来将会成为企业数字化的基础设施；观点二：全民开发，人人都可以是开发者；观点三：低代码会促进行业培养更多快速搭建数字化系统的技能型人才。

图1 “低代码”调查统计：认知度与了解意愿

图2 低代码使用人群画像

特邀嘉宾主持人：

邹欣（CSDN副总裁）

参会嘉宾：

宁伟 葡萄城 产品市场总监

朱文静 新加坡AI²LABS中国区负责人

黄荣 普元信息 北京研发中心资深顾问

汤炉鑫 中兴数字技术产品部 产品总监

曾静良 致远互联 助理总裁

骆勤 腾讯云微搭低代码技术产品专家

王潇 道一云事业三部总监，大华北区负责人

乔胜 明源云 天际开放平台解决方案总经理

李婷婷 轻流联合创始人兼CTO

蒋童 上海泛微网络科技股份有限公司咨询总监

陈晓露 行云创新 产品总监

蕾拉 钉钉高级运营专家

令九 钉钉技术专家

熊方恒 织信深圳市基石协作科技有限公司运营总监

李焕静 泛微 北方大区市场总监

费腾、郭月宁、龙腾 社区低代码KOL

图3 邹欣（嘉宾主持人）

图4 研讨会现场

“低代码”平台应该如何分类？

邹欣：CSDN前期做了一个调查，结果是“22%的人已经开始使用“低代码”，58%的人表示在一年内会去使用，70%的人群对于低代码的定义是非常模糊，91%的决策者认为他们利用了低代码之后效率提升50%以上”。这是一个全新领域，大家会从哪个角度分析和切入？

图5 骆勤（腾讯微搭）

骆勤：个人认为分类可以有两种：一种是从行业角度划分，分行业通用低代码平台和特定垂直领域的低码平台；另一种可以按可视化程度划分，实际上国内外逐渐把很多无码平台也纳入了低代码这个体系，所以又可以分低码和零码平台。

对于腾讯微搭“低代码”平台主要有三个明显特征：

（1）微搭构建在腾讯云开发基础底座上，定制能力具备了从无码、到低码以及全码三种开发模式，这是我们的扩展性优势；

（2）快速直连腾讯生态，尤其针对小程序场景，可以直接跟微信生态链路绑定，比如用微搭搭建小程序通过私有链路，来打通视频号、交易能力、支付能力等会非常顺畅；

（3）拥抱开放生态。我们现在开放生态定位很清楚，核心会把企业连接能力做好，企业客户能通过微搭“低代码”平台把内外部产品服务和数据进行打通。

费腾：我认为无论“低代码”或是“零代码”，可以按照横向和纵向两个方向去分，解决“功能性”和“领域性”的问题。

（1）“功能性”重点挖掘跨领域之间的共同特点，以功能为主形成一个个子系统进行复用；

（2）“领域性”则更加专注业务，不断深耕聚集与业务相关的知识能力，提供更便捷的垂直业务系统。

除了横向和纵向的大类外，还可以从产品功能定义去拆分，如大家所熟悉的“表单驱动”和“流程驱动”，还有“模型驱动”。

蕾拉：钉钉今年推出“低代码”聚合平台“钉钉搭”，作为“低代码”聚合平台，跟单一产品最核心区别在于“钉钉搭”是“低代码”产品聚合场，更希望搭建“低代码”生态型平台，希望把国内国际比较有代表性的“低代码”产品以及“低代码”能力融合在这个平台上，依托于云底座能力，为更多组织、有创意、有想象力、有动手能力的用户做服务。

曾静良：我这里有一个我们的客户案例，他们在数字化转型的过程中，希望能有更合适他们的大平台助力，解决各类复杂的管理流程，最后我们把他们的经验复用，形成一套“低代码”平台的分类逻辑：

（1）为OA类厂商提供的“低代码”平台。以审批流程应用为主，把制度规范、管理流程串起来；

（2）为财务、业财一体化、ERP客户提供服务的平台。直接为有需要的客户提供一套垂直业务系统，直接完成无代码式的数字化转型；

（3）新型互联网厂商的低代码平台，无传统B端软件背景的厂商。

图6 曾静良（致远互联）

千鸟：作为一名开发者，我更倾向把“低代码”当做辅助开发的一个工具。比如在业务模型确定后，后端通过“低代码”平台能够自动完成数据库脚本生成、底层增删改查基础逻辑代码生成、还有相关大量同质化的WebAPI代码；前端通过“低代码”平台则直接将设计图输出为页面文件。

这些“低代码”产出的代码，直接交付给稍微懂开发的程序员，稍作调整，即可直接编译发布进入测试环节。因此从开发者角度看，“低代码”的分类，是否可以参考程序员的分类，比如面向前端的、面向后端的、或面向数据库、运维的、测试的等等。

如何评价“低代码”产品的成熟度？

邹欣： AI从学科角度已经非常成熟了，已经成为标配了。但是从来没有任何一个学科搞“低代码”专业，职业培训学校也都没有，所以它作为一个学科是不成熟的，但在工程领域，又有许多使用“低代码”的成熟应用，大家觉得应该如何评价“低代码”产品的成熟度呢？

图7 蒋童（泛微网络）

蒋童：我站在客户的角度谈一下“低代码”平台成熟度应该有的几个维度：

（1）平台界面的友好度，是否简洁方便，学习成本比较低；

（2）“低代码”平台到底可以快速构建什么场景。比如简单应用、复杂应用、业务场景能不能百分之百覆盖到；

（3）平台的延展性、集成性。可不可以单独使用，还可以跟第三方做集成，这个“低代码”平台能不能接入我的中台；

（4）安全性、易用性、可维护性、稳定性、和各个系统的适配性；

（5）价格。因为“低代码”不是一个系统，是帮助客户构建数字化落地的共建。客户的信息系统中，将来既有OA、ERP、财务等各种专业系统，同时手里还有“低代码”平台，可以按需快速构建各种轻量级或者中量级的产品。

宁伟：关于评价一个技术的成熟度，我是这样看的：如果这个技术已经存在，面临更新改善或者组合创新，那么就用传统方式去评估；如果它是全新的、颠覆性的、革命性的，自然也就需要用新的方式去评估才合适。

所以在评估“低代码”成熟度之前，第一件事情是应该确定“低代码”究竟是革命性的还是组合性的。目前的低代码产品可以分为两个大类，一类是刚才提到的 “模型驱动”，“模型驱动”相比于原来的软件开发技术应该是个组合性创新。这种低代码平台通常用于开发比较复杂的系统，所以我们对他们的成熟度要求会高一些，按照开发企业级软件的标准进行评估。

国外Gartner有一个报告，在 “企业级低代码”成熟度上定义了8个指标：（1）性能；（2）高可用性和高扩展性；（3）云服务API的集成能力；（4）灾难恢复；（5）企业级安全；（6）SLA；（7）应用运行监控；（8）厂商级的技术支持与培训。

而对于另外一种类型，也就是面向业务人员使用的“表单驱动”低代码产品来讲，需要先关注它提供的新价值是否达到预期，即帮助前台、销售等没有IT技能的人，做一些日常工作中用到的简单应用，这个时候我们不应该用传统的企业级应用开发的标准去套用。否则，我们不但是“杀鸡用牛刀”，而且还在做压制创新的事情，行业不应该往这个方向发展。所以，我认为对于不同类型的“低代码”平台产品应该有不同成熟度的判断方式。

乔胜：在评价“低代码”平台这个新生事物时，不能仅站在技术某些细节去评价是否成熟，因为大家走的路线都不一样，但是在不同领域形成合力。

我认为应该从3个层次来考虑“低代码”平台的价值：

（1）应用价值。是否能够很方便在上面构建复杂应用，解决客户或者行业、或者某个领域的需求；

（2）社会属性价值。“低代码”平台是个革命性的工具，它的目的是为了解放程序员的劳动生产力，通过这个平台到底为哪些行业解放生产力？解放了多少生产力？

（3）生态属性。在现在的企业架构环境里，往往凭一个IT团队，一个开发平台往往很难解决所有的问题，我们希望通过一个或者少数平台为企业做更多事情，比如最简单的：这个平台能够提供多少开箱即用的应用、组件和方案，能够引入多少业界先进的技术并将它们场景化落地，能够为企业带来多少技术资源。

汤炉鑫：个人认为，目前国内把“低代码”的范围放大了，我认为“低代码”成熟度应该围绕以下三点考虑：

（1）面向从业者。不懂编程的业务人员，能够根据需求，快速搭建能够很快解决业务问题的产品；

（2）面向业务分析师。能够通过做业务建模后，基于少量脚本类代码或者规则生产出需要的应用；

（3）面向开发者。有可视化的能力，来解决研发生产力的模式。

朱文静：我们对成熟度的理解有以下几点：

（1）用户的满足度。比如AI平台，可以通过平台实现功能全面性评价AI平台的成熟度。

（2）稳定性。比如做数据的平台，平台的稳定性则非常重要。

（3）高并发性。比如平台是否支持一家用户有1000多人同时进行数据标注，应该怎样处理这些高并发问题，这也是“低代码”平台发展过程中要处理的事情。

（4）安全性。所有平台都离不开数据安全的问题。

（5）运行速度。比如AI平台，线上提供GPU数据训练时，时间周期的长短对于用户去使用的感觉也是非常重要的。

（6）服务能力。在过程中是否有技术支持、有培训、有无代码开放平台去服务客户。

（7）性价比。一个成熟的平台，应该能够帮助客户大大的解决开发的门槛、成本和周期，并且面向不同人群提供不同的可性的价格指标。

黄荣：我们评估“低代码”产品的成熟度，是跟对象有关系的，不能拿评价杯子的标准去评价一个桌子。所以“低代码”成熟度涉及到应用全生命周期各个环节。这是一个综合性的东西，包括在开发上的便利性、运营性能、安全性等等一系列指标都是需要去考虑的。

“低代码”开发和传统开发的相同和不同是什么？

图8 千鸟（社区KOL开发者）

千鸟：怎样快速组织一个全栈能力的开发团队，我觉得应该是“低代码”与传统开发最大的区别。记得读研时，导师当时留了一个话题对我至今影响深刻。他说市面上有很多公开的API，能否直接调用公开服务做一套我们自己的应用？当时研究课题领域是WebService和标准化接口，现在移动应用如微信小程序、APP开发的最底层核心都需要调WebAPI，所以从底层开发来看，“低代码”能否有一种能力，让开发者更好生成或者解决底层逻辑的处理。一套完整系统的研发，在设计、研发、测试各个环节中有很多工作要做，小型研发团队的精力有限，“低代码”应该在传统开发之上，让开发人员更专注系统的架构和逻辑，尽可能降低代码编写的生产成本。

汤炉鑫：我认为“低代码”本质是定义一套自己的语言体系，解决如何快速编排，建立自己的生态，让相关的程序员或业务员在它上面做更多搭建和赋能。利用“低代码”开发，同样会经历需求分析到上线发布的整套过程，中间会有高级语言做支撑，研发模式没有发生变化，发生变化的是对组件化的要求更高了，同时语言层面有更高级语言去组织。

宁伟：基于中台来实现前后端分离，把后端的能力进行抽象、重组，前端编排进行快速开发，是现在企业级应用开发的大方向。我们客户中，大部分是软件公司或者大企业IT团队，他们是从纯代码开发的模式转型到到低代码，从他们给我们的反馈上看，在转型过程中，低代码开发团队仍然要和写代码的团队紧密配合，才能充分利用之前开发好的数据中台，和现有的IT资产无缝集成。那么这个结合点是什么，WebAPI可能是一个非常好的实践。这里不但需要低代码平台去对接用代码写的WebAPI，消费中台提供的数据；还需要用低代码构建出WebAPI，给纯代码写的其他模块，比如市场端的小程序，仓储端的WMS等调用，为他们提供数据和能力，这就是我们说的双向集成。

双向集成是每个“低代码”平台厂商一定要发力去解决的事情，但我们要怎么通过自动化方式，去分析对方系统，动态建立数据模型，搭建一个WebAPI并很方便的进行调试，还需要投入更多时间和精力去研究。

费腾：传统编码，程序=算法+数据结构，算法和数据结构都需要开发者去思考，使用“低代码”平台，许多算法和数据部分都被割裂了，或者说逻辑太过松散，不够内聚，对于开发者来说有种“黑盒”的不安全感，我认为现阶段它还不适合开发核心业务。我们的“低代码”平台不仅只是一个“平台”，它本身也可以作为插件或者工具，用到核心系统中里作为部分特定领域的更好实现，这样会让开发人员的意愿度、参与度更好一点。若想作为一个全局的核心平台，还是需要仔细调研和决策的。

汤炉鑫 ：我是做 toB 业务的，很多业务复杂度非常高，所以我们在推动这个层面时也遇到很多挑战，开发人员从技能提升和未来的发展，都觉得如果用类似“低代码”中基于模型、基于表单的方式去发展核心业务，这个不太可靠。所以我们把现有的“低代码”拆开了，“低代码”最好的核心是让业务不断做抽象，它改变原来设计系统的模式，设计任何一个系统，首先围绕“低代码”的思想去设计，这对复杂系统的扩展性一定会有帮助。

骆勤：我认为“低代码”是一种抽象维度更高的计算机语言，所以它作为一个语言是会进化的。刚有朋友提到“低代码”不适合核心业务，我觉得应该辨证的看这个事情。至于普通开发的区别前面大家讨论很多，早期传统开发需要写很多代码、走很多构建流程，而在“低代码”平台下，许多工作都做到了可视化，这种区别很像是当年DOS系统与Windows系统的区别。未来的开发工作可以从键盘迁移到鼠标，这也是我们需要去做的事情。

邹欣：刚才几位老师讲的核心点是跟“低代码”这个“低”有关系，是不是用“低代码”开发，所有的东西就低了？让开发者感觉远离他的核心业务？举个例子，我们入行用C++写代码，开发者可以按需管理内存，后来Java，C#有独立的内存管理机制，解放开发者管理内存的问题，有些人因此就会觉得在开发语言上略显low，但是java，c#也同样强大。“低代码”是把复杂性隐藏起来以后，更关注业务逻辑，但是很多开发者会不会想，我是一个手艺人，我想写code，把这个code写得越靠近机器越高大上，觉得写业务逻辑low。在“低代码”开发认知上的不同，我想也应该能算做是有别于传统开发的一个部分。

聊聊你的“低代码”产品中开发者最喜欢的3个功能？

邹欣：先抛砖引玉，这是一个买家秀，我们以前做了一个“智能表单识别”，后来很多人觉得API太难用，我们用Python把API的场景写出来，训练模型后，把模型填到程序中，它就成功了，有点像“填空式开发”，很多人觉得很好，能够更快速的落地。现有的“低代码”平台中，用户最喜欢的功能是什么呢？

蒋童：我们的客户认为产品有三个比较吸引的地方：

（1）云应用商店。里面现在有1000多种应用场景，客户也可以通过“低代码”开发平台可以把他们自己的应用场景上传，所有用户都可以通过云商店构建不同场景的应用。

（2）表单引擎。不需要懂计算机语言、不需要懂系统语言，只需导入要常用的Excel就可以构建。

（3）可视化编辑的流程引擎。通过鼠标拖拉拽，以搭积木的方式就可以快速构建各种应用场景。

宁伟：我们葡萄城最近也举办了一个研讨会，会前针对软件公司类型的客户做了份问卷调查，最受欢迎的三个功能：

（1）可视化构建WebAPI的能力。我们的活字格产品，以可视化方式，提供用户参数变量、条件判断、事务处理、访问权限的配置，以可视化方式构建自己的API。

（2）抹平现有数据库差异的数据访问能力。企业有很多不同数据库，有些软件用MySQL，有些用SQLServer，我们提供的一套机制，帮助他们完成在不用数据库中的查询、写入、事务控制等，所有这些东西都不需要写一行SQL，我们帮它做了数据库翻译工作。

（3）响应式布局的能力。类似WPF平台grid的那套方式，用“所见即所得”的方式，同时支持绝对布局和流式布局。

李婷婷：轻流是无代码开发平台，面对终端业务人员更多，客户最喜欢的是三个方面：

（1）Q系列机器人。专注表单驱动、流程驱动，它是串连人的能力。我们Q系列机器人定位是系统自动化，未来还会引入AI的方式，在信息化之上智能化；

（2）“低代码”和无代码平台。提供“开箱即用”的能力，比如一些场景模板如报销领域或工业巡检领域，先加载一套模板，在此基础上根据自己的需求做变更、优化和调整；

（3）开放集成的连接能力。很难有一个企业可以解决所有信息化诉求，这就带来所有企业都需要多套系统完成信息化过程，那就需要这些信息系统之间可以协作和沟通，轻流有一部分能力是专门去做系统集成API方面的无代码化。

乔胜：我们平台是业务开发的“低代码”平台，在不久前，我们对所有开发者进行过一次调研，大家认为喜欢的功能包括：

（1）可视化开发中的沙盒测试环境。在零代码开发中不需要切换到专门的开发环境进行打包测试，总体节省前端开发50%以上的时间；

（2）一体化自动化的DevOps云体系。全程接管了研发协同过程，除了在项目开发环境初始化时，开发者对CI/CD操作基本无感，而是将更多的精力投入到复杂业务逻辑实现中；

（3）平台中提供了一系列的标准应用模板,实践了基于应用级模板的开放性，极大地节省了项目交付的工作量。

朱文静：我们在产品诞生就基于公司内部团队在AI应用开发时候的痛点去开发的，因此AI应用开发者在做AI开发时，只要看到Slick的界面，就可以清晰地从业务逻辑去开发AI产品。

对开发者来说最喜欢的几个功能是：

（1）模型的Pipeline，几个AI模型叠加，可以把各种不同模型的功能组合在一起，比一个个模型的开发会效率提高非常多。

（2）AI模型开发插件，包括数据预处理，自动标注等等功能，这对AI开发来讲可以以无代码的方式进行使用。

（3）AI模型的下载。用户在我们平台开发完成的AI模型，我们支持H5预览，或者API、SDK等方式部署，支持直接外部调用开发，同时也允许用户把模型下载下来，独立应用在其他业务场景当中。

王潇：我们提供各种门户，道一云是企业微信最大的一家第三方，我们的客户非常喜欢的几个“低代码”场景：

（1）业务型数据中台。比如使用我们提供的平台，直接替代CMOA、客服、后端的管理等非常核心的业务。

（2）灵活的扩展性。我们的客户企业，每年都在发展、在变化，业务调整和组织架构变化每年一次，这写变化都能通过我们的“低代码”平台很好的切换，不会因为业务调整造成线上服务的延迟。

讲讲“低代码”平台业务最有效的产品，杀手锏级的应用？

图9 宁伟（葡萄城）

宁伟：葡萄城活字格“低代码”平台目前应用比较广，产品最有应用前景的领域有两个分类：

（1）工业互联网落地。工业互联网时代大量传感器产生了海量的数据和基于这些数据的分析结果，需要有大量的协同管理和数据需要处理，用原来的开发，不仅成本高，而且时间也较慢，利用“低代码”实现数据和现有管理系统、现有管理流程之间的对接，则可以很方便完成这些工业互联网软件的应用落地。

（2）在企业ERP系统上的应用。很多企业上ERP，都是20年前的事情，企业内部有OA系统、ERP系统、行业软件，而且现有的数据是打不通的，通过“低代码”重构一个全新的数字化平台。这个平台对接ERP等系统，并且支持更低成本的扩展应用开发，可以很方便解决旧版系统和现在的业务无法兼容导致的许多问题，充分发挥原有IT资产的价值。

朱文静：我们最有优势的一个业务场景是本身企业对于自己的AI模型有非常强迭代需求的场景。传统企业利用AI方式进行模型迭代的话，由于会面对数据处理工具不规范，模型管理和部署运维繁杂等问题，它的周期和成本非常高，所以在这个过程中使用我们Slick平台可以更快进行模型迭代和迁移学习。比如一些智能硬件的检测，人肉眼是没有办法看见的东西，这完全可以使用我们的平台，打造出的检测模型，迭代部分就可以变成非常轻量级的工作。

李婷婷：关于“低代码”、无代码在实际应用场景的这个问题，我们有一个制造业客户十几个工厂都在用，每个工厂成立兴趣小组，每个小组是来自人事、行政、生产、车间等各个部门的人，他们定期学习这个工具，然后头脑风暴有哪些场景可以信息化、流程化、规则化，是一种“全民开发”的概念。

我们认为轻流无代码平台更擅长做：

（1）长尾需求和知识产权管理。这种受众小、低频的场景是更适合用“低代码”、无代码去快速开发的。

（2）一些快速变化的新的业务。疫情前后，商业模式在变更、应用模式在变更，在快速发展变化过程中，尤其一些新业务启动时，要求非常快速投入市场，需要有很快的信息系统支撑，有了“低代码”、无代码，更多新业务就可以通过这个平台快速响应，并且在过程中可以随时调整和优化。

骆勤：其实“低代码”也很适合做一些简单、很普惠的事情，比如今年的河南大雨时，应急团队用2个小时就完成了一个互助应用的开发，效果也很好，这在平时很难做到，低代码很适合这种应急场景。

邹欣：“低代码”通过四两拨千斤的方式，在许多应用场景是真正解决了用户痛点。对我们的启示：我们无需考虑“低代码”解决的是何种问题，即便很少有人用的功能，如果这个功能解决好，相信“低代码”以后的机会也是特别大的。

2022年初，CSDN就接力展开了关于“低代码”开发者应用体验的第二季调研活动。随后即将在广州、杭州、成都、西安、武汉组织研讨会，期待您的参与！