TVP 尖峰对话：透过喧嚣探寻低代码的技术本我

点击查看活动精彩回顾

背负着“人人都是程序员”的期望降生，低代码作为一种早已有之却又重获新生的技术理念，迎来了市场的热捧，又遭遇了诸多的质疑。

从软件开发行业的发展脉络来看，降本增效是行业不断向前发展的过程中，一脉相承的核心诉求。而低代码的能力，也恰恰是让研发人员从机械的增删查改中脱离出来，专注于解决更有价值的问题。从这个角度看，低代码似乎前景一片光明。但在当下，在复杂业务场景面前的能力缺失，却又限制了低代码平台更进一步。

低代码，究竟是下一个十年的主流开发模式？还是技术炒作周期中昙花一现的泡沫？低代码对于开发人员究竟意味着什么，又能在开源的文化下孕生出怎样的发展？8月20日，「低代码究竟是“银弹”还是“泡沫”」TVP 低代码技术分享会火热开聊，用一场尖峰辩论和一场圆桌对话，共探低代码的过去、现在与未来。

腾讯云副总裁、腾讯前端技术委员会会长 黄俊洪的开场致辞拉开了本次活动的帷幕。在致辞中，黄俊洪分享道，低代码并非一个全新的事物，而在数字化转型的当下，其作为一个降本增效的工具也获得了广泛的应用和发展。不管是技术层面的进步，还是业务场景的应用，亦或是开源生态的构建，低代码都行驶在一个快车道里。

腾讯在今年成立了低代码开源协同Oteam，在腾讯前端技术委员会的指导下，拉通内部低代码技术构建。在对外的低代码平台能力提供、行业标准制定、开源生态构建上，腾讯也持续发力。腾讯云官方的低代码平台——腾讯云微搭，通过打通微信小程序、企业微信、腾讯会议等腾讯产品生态，帮助企业提升效能。同时，腾讯也在积极参与低代码的相关标准建设，如大湾区标准建设、信通院标准建设，并通过建立低代码开源社区、举办低代码技术交流活动等多种方式和行业各界一起，推动低代码开源生态的繁荣发展。

最后，黄俊洪表示，希望通过本次TVP交流活动，能够和行业专家碰撞思维火花，共同探讨低代码未来发展的可能性和生态建设路径。

活动伊始，便是一场火星四溅的辩论环节，辩论主题紧贴当前低代码技术发展的热点话题——《未来十年，低代码是否会占领主流开发市场》。正方“低码 38.6℃”队持“未来十年，低代码会占领主流开发市场”的观点，反方“爱码士”队持“未来十年，低代码不会占领主流开发市场”的观点。双方围绕低代码的技术趋势、行业现状等角度出发，展开了精彩的交锋。

• 正方“低码38.6℃”队：一辩 ClickPaaS CPO、腾讯云 TVP 马俊；二辩 华炎魔方创始人庄建国；三辩 Treelab CTO、腾讯云 TVP 付静；四辩 DCloud CTO、腾讯云 TVP 崔红保。

• 反方“爱码士”队：一辩 公众号“ IT 民工闲话”作者、腾讯云 TVP 史海峰；二辩 努比亚 IT 总监、腾讯云 TVP 李子坚；三辩 公众号“世民谈云计算”作者、腾讯云 TVP 刘世民；四辩 神策数据解决方案架构师、腾讯云 TVP 白德鑫。

（一）立论环节

正方一辩 马俊

首先我们应该看到，技术的发展形成社会的高度分工，社会高度分工反过来让资源治理进行有效的聚合，从而促进社会的发展，这是过去三次产业革命验证过的客观规律。这个发展演进的过程中，工匠精神很重要，所以代码很重要，但身处大工业时代的当下，工匠思维一定是服从于工程思维的。

低代码本质上就是一种软件工程的设计思想，其核心是利用参数化、组件化的方式来封装结构，用工厂化的方式来装配软件系统，改变此前软件开发从代码做起的作坊式生产方式，进而提高代码的可复用性，控制代码的质量，降低软件从业人员的门槛，缩小业务专家和技术专家的认知差异。在低代码技术的支持下，软件行业也会实现高度的分工，不仅仅是低代码供应商会发挥作用，所有的快速开发工具、扩展工具，其实都符合低代码思想，将其概念狭义化是不正确的。

随着数字化转型的深入发展，仅中国每年的软件人才缺口就高达数百万，未来十年软件人才的供给和需求之间存在巨大的鸿沟，这个问题只能通过推广低代码的思想、利用低代码技术来解决。

根据对世界范围内IT人员和决策者的调查显示，59%受访者表示疫情带来的影响远超预期，85%IT决策者认为低代码是其不容错过的趋势，93%的IT人员表示企业将加快软件开发速度。另有数据显示，全球有77%的企业已经在使用低代码开发平台，IDC预测未来全球低代码开发者数量将以高达40.4%的年复合增长率递增。试问在用户需求推动、从业人员辛苦耕耘、资本加持之下，这种符合社会发展规律的降本增效的工程技术思想如何能不成为主流？因此，我方坚定认为，未来十年里，低代码一定会占领主流开发市场。

反方一辩 史海峰

在阐述今天的辩题之前，我方认为有必要先跟大家明确相关的概念以免混淆。第一，如果代码写得够好，只做配置变更就能实现新功能和需求，这不叫低代码，只是因为我们的成品已经是一个很好的功能集合体。第二，引用数据说明有很多企业在用或者将要用低代码，甚至只要用过Excel都算低代码的话，那今天的问题也无需讨论了，因为现在低代码已经成为了主流，但现状显然并非如此，大家仍旧没有广泛认可低代码的价值。这是我们今天辩论的基础。

我方认为未来十年低代码不会占领主流开发市场，理由主要基于两点：其一，主流开发市场不是办公自动化工具使用市场，开发工程师不是Office等办公软件的使用工程师。其二，高级语言编程是经过验证的最有效的开发方式，在人工智能的奇点还没有来临之前不会被颠覆。

如果大家从业经历足够丰富，经历过Dos系统到Windows系统，用过可视化编程软件、ESB等等，都会知道从始至终低代码都没有成为过主流开发手段。开发工具的确在持续进化，但进化的未来是低代码吗？并不见得。

低代码目前的宣传重心在于面向业务人员、IT人员而非开发者，这本身就说明了问题，因为低代码只有在一个目标很明确的场景里才有相对较好的体验，对于开发人员而言，低代码无异于隔靴搔痒。开发市场的确可以做到高度细化的分工，但编程语言是相对通用的，这对于低代码平台而言是一个挑战。

另一个非常重要的点在于，开发人员是需要保持不断成长的，对于底层原理和技术本质的理解、掌握和应用，才是一个开发人员持续进步的关键。而低代码只是一种工具，如果哪个开发人员把工作的希望寄托于工具越来越趁手，那他离被淘汰就不远了。更别说低代码在复杂业务场景和超越流程逻辑性的非功能性需求等方面存在缺陷，它的应用场景目前仍然是有限的。我们需要理解的是，开发的本质是人与机器，人与人之间交互的过程，而编程语言是交互的桥梁，所以编程语言的发展在根本上属于人类语言学问题。这么多年下来，低代码没有成为主流，高级编程语言却越来越多，这本身就说明了我方观点的正确性。

（二）攻辩环节

正方二辩 庄建国

我方观点的核心在于，如何定义低代码是首先要去解决的问题。我方认为，低代码是零代码和高代码的有机融合，在可视化的基础上，能够融入高代码进行开发。至于这是不是未来方向，这甚至无需讨论，因为所有程序员都爱可视化开发。这是第一点。

第二点，反方辩友其实在偷换概念，我们不是为了写代码才成为开发，而是为了解决实际的需求，利用代码构建程序来解决我们的需求，实现我们的目的。反方辩友认为使用Excel、Airtable只是在使用工具，而非开发，这显然是错误的。使用这些工具创建的表格，都解决了我们的业务需求。而SAP、Salesforce、华炎魔方这一类企业级低代码平台内核都有一套底层基础架构，支持可视化的方式去构建数据模型、定义报表、控制权限等，它同样是在做开发，而且解决的是非常具体的问题，这就是低代码的能力。

当下市面上正在销售的所有软件产品，都会有一个低代码化的过程，因为传统开发模式下产出的解决方案，无法满足客户的个性化需求。而当客户个性化需求涌现时，软件提供商不可能用通用的方式去实现客户各异的个性化需求，而客户也不大可能追加大量预算去定制开发模块，未来的场景下客户根据软件提供商的低代码平台对解决方案进行二次开发将成为主流。

我抛出几个问题大家可以思考一下：可视化是不是大家更喜欢的开发方式，为什么未来十年我们不朝这个方向去努力？开发效率是不是大家共同的追求，可视化可以提高一次开发和二次开发的效率，为什么不朝这个方向努力？低代码有如此高的社会关注度，国内外大厂都已经跑步进入低代码领域，为什么大家会认为未来十年技术不会再有突飞猛进的进步？为什么我们要停留在现在的阶段去看十年以后的开发市场？

反方二辩 李子坚

庄建国老师把低代码定义为零代码+高代码，这个范围扩得太大了。20年前诞生的领域驱动设计（DDD）的开发方法论，强调封装业务模型，也能减少定制的开发量。如果按照庄老师的定义，DDD也被囊括其中，这个范围显然过于庞大。

庄老师提出的几个问题，有一些我持相同观点，但这并不代表当前主流的开发方法就排斥可视化，也不代表低代码在提高开发效率同时带来的新的问题我们就可以忽视，仅仅只靠效率，并不能成为开发范式的主流。

从开发场景的角度看，低代码在前端应用、流程性应用的细分领域有不错表现，但它替代不了所有的软件编程工种和场景，比如数据分析、大数据、中间件、嵌入式、工具类的平台系统等等。以我所在的企业为例，有用到大概三种低代码工具，整体开发人员占比和应用规模来看也就20%左右的比例，原因一方面是有些应用场景目前还没有合适的低代码工具，另一方面则是现有的低代码平台无法满足具体的场景需求，这已经能够说明很多问题。

其次，从系统架构看，低代码应用很难独立存在，开发运行必须要依托业务平台、业务框架和底座，否则低代码应用就是无源之水。很多低代码工具的宣传口号是乐高式编程，但如果没有乐高积木，何来乐高式编程呢？如果说低代码工具会培育一批低代码程序员，那么同样会促使PaaS平台、SaaS平台和企业中台的开发群体的发展壮大。

作为一名软件开发的管理者，从项目管理角度来看，低代码的应用并不适合于大规模软件工程的项目实践。当前低代码应用偏碎片化，就像业务人员手里的一大堆Excel表格，虽然积累了很多业务逻辑和数据，但无法在企业内部共享、复用和管理。十年前很多企业就开发了成百上千的部门级应用，都相当于在前期低代码工具地基上起的楼，却很难整合，以至于年久失修被放弃，这就是前车之鉴。

最后，重申一下我方观点，软件开发发展了数十年，虽然开发工具在不断进化，但是核心的开发思想、开发理念一直没有发生改变。十年时间对于低代码来说依然太短，尚不足以冲击目前主流开发工具和开发方法的主导地位，更有可能是作为在细分领域提高开发效率的好帮手而存在。

正方三辩 付静

正方几位辩友的发言中都有提到，研发人员不愿意做CRM开发，害怕荒废Java技术；开发人员不喜欢拖拉拽，害怕自己因此失去了赖以生存的技能，所以导致低代码不会占领开发市场。这个其实是有混淆逻辑，如果我们回到几十年前工业时代，工厂工人也不喜欢流水线自动化系统，但历史如何大家也都看到了。如果低代码平台能够以更低的价格、更高的效率实现业务的诉求，企业的选择其实很明确，这并不以开发人员的喜好为转移。外包制、高代码定制化的市场红利在逐渐消失，SaaS也好，低代码平台也好，关注的都是复用性、经济性、可靠性和后期的快速迭代性。

前面大家交流关注的焦点都在互联网行业，在计算机系统和架构的层面看到了低代码的很多不足，看到了当前 IT 从业者可能的抵触。但也请大家将目光从互联网行业抽离出来，关注一下传统行业这个在中国经济体量中非常重要的一环，当我们真正走进这些行业、企业中去，才会发现信息孤岛效应有多严重，数据的汇总、加工效率有多低。从这个角度上去看，在传统行业，低代码平台将代替他们今天所用的软件，成为提效的关键。

反方辩友提到低代码只能落脚在细分市场，缺乏行业标准，很难统一。这个问题我可以举一个深度学习的例子。人工智能发展初期，编程非常枯燥甚至痛苦，大家也不清楚未来的标准会是什么样，但现在再看，深度学习在谷歌内部已经完全UI化，最强大的深度学习模型也开源了，这也才花费了十年左右的时间。低代码的深度比深度学习要浅一些，只是一个传统行业业务建模的问题，而这些碎片化的问题一定会被低代码组件化、标准化。

我们再从软件开发的历史回顾一下，汇编语言占据市场那么多年，现在归为沉寂。C语言是主流的编程语言之一，却也不是第一或者不可或缺的一个部分。如果不抠字眼地看，低代码平台未来十年一定会成为主流，毫无疑问。

反方三辩 刘世民

我先反驳一下正方辩友的一些观点。首先，正方一直在扩大低代码的边界。实际上，即便把零代码拉进低代码的范畴，也帮不上多少忙，因为对方辩友曾经说过“零代码解决不了80%业务场景的需求”。其次，针对“不懂低代码，就不懂数字化”的观点，我认为这过于拔高了低代码的价值，低代码和数字化并非强关联关系，前者只是后者实现过程中的一个手段，传统行业例如银行业做数字化转型首先做的是扩大研发人员的规模，而不是去建立低代码平台。其三，对方辩友有意忽略了企业应用开发的复杂性和“主流”这个关键词，企业应用种类众多，包括办公类、业务类和平台类等等。目前及将来，低代码平台更多的还只是在办公类应用领域发挥价值，而无法满足业务类和平台类应用的需求。其四，对方辩友提到了很多来自咨询公司的数据，而这些咨询公司的数据受众是创业公司，而非普适性的公司，并不能照搬到所有的企业里。

而关于“程序员的喜好对低代码平台不重要”这个观点，我个人并不认同。一方面，数字化时代，程序员的重要性远超从前，传统行业数字化转型所依赖的关键就是程序员。另一方面，程序员作为低代码平台的最终用户，如果他们对低代码平台不满意，宁愿自己去写代码解决问题，这恰恰说明这类平台的用户对产品的不认可、不买账。

此外，对方辩友提到的AI案例，恰恰说明了我方观点的正确性，就是时间并不能解决一切问题。上个世纪50年代AI就已出现，至今仍只在语音识别、图像识别等方面有所成就，这就证明了时间并不能解决一切问题，还得依赖研发人员的努力和需求的变化来推动——低代码同样如此。现在低代码平台的众多局限性，并不会随着时间的推移而自动消失。

最后，我再重申我方观点：未来十年，低代码无法占据主流开发市场。第一，低代码平台用户是开发人员，如果用户都不喜欢，低代码平台如何推广？第二，厂商宣传中的业务人员利用低代码平台做开发，这只是美好的想象，实际上业务人员更重要的工作在于业务而非开发。第三，连AI到目前都没有实现与人对话，拖拉拽、组件式的低代码平台更不可能实现应用自动化开发；最后，当前计算机专业仍旧是顶流，市场需求是最真实的体现。

一言以蔽之，低代码平台是一种可视化编程工具，可以作为高级语言开发的辅助，但却无法取而代之并成为主流。我们希望也愿意看到低代码平台能在某些领域中发挥越来越大的价值，同时也叮嘱一句，与其梦想成为主流，不如脚踏实地占领一城。

正方攻辩小结 马俊

首先响应一下对方辩友的发言，作为低代码行业从业者检讨一下，发现大家对于低代码事物本身，对于开发这个词，对当前低代码发展阶段的理解有些片面。第一，可视化是低代码的一个特征，但非全部，组件化、源数据驱动、组合式应用等等，都需要低代码来支持。第二，开发软件并非程序员这一工种的职能，软件工程的过程中，程序员只是其中的一个环节，除此之外还有应用架构师、算法工程师、数据科学家等等的参与。不能因为程序员本身不喜欢低代码技术就否认低代码的趋势和未来。

我个人在2008年加入Salesforce，一直工作到2017年出来到ClickPaaS做低代码，对Salesforce了解很深，很多类似于AI、区块链等新技术，都有在 Salesforce 应用，它恰恰起到了应用新技术、结合低代码来适配数字化的作用。所以我坚持我的观点，不理解、不懂低代码就是不懂数字化。

对于十年的时间够不够，同样可以拿Salesforce举例，1999年成立的 Salesforce，在2008年就拿下了华为的大客户，这已经很具备代表性了。国外的金融行业已经开始广泛地应用低代码平台，一些金融科技的应用场景和趋势使用低代码开发非常合适。我方同样承认，技术需要时间去解决问题，稳定性、成熟性、性能等等都需要时间，但十年时间已经足够走很多路。

开发人员需要剥离纯粹的码农思维，不能一直关注代码实现，更需要引入工程思维，无论是做组件还是做架构都是要价值的，在低代码的世界中码农一样有很大的价值。低代码和高代码本质上就是可以高度融合的，前者的愿景也并非替代后者。

最后，我想说十年磨一剑，我们要有这个耐心。Salesforce的成功用了十年，我们的十年为什么就不能做出更优秀的低代码工具呢？

反方攻辩小结 史海峰

我还是坚持此前提出的问题，低代码的概念既然扩得这么大了，我们还需要等十年吗？这个问题对方辩友一直没有给出正面的回复，所以我们在讨论一个问题之前，需要明确的是大家心里要有一个共识，一个看起来很大，没有特别清晰标准、偏概念性的东西，很难获得普遍接受和认可，这就是问题所在。

从开发的角度看，写代码并不是核心，需求分析、设计、调试是一整个生产过程，而且不是只有研发工程师才写代码，运维、测试、架构师都会写、能写代码。开发的核心是实现功能解决问题，这不代表拖拉拽或引用组件，或封装，而是说开发人员用语言性的媒介跟人、跟机器做交互。

前几年AI编程的新闻引发过大家对AI会不会替代开发人员这一问题的讨论。但实际上到目前为止，AI在编程这件事上依旧只能打辅助。如果有一天AI发展到可以突破图灵测试，给它一个眼神它就能体会什么意思的时候，或许整个人类也不需要再做开发的工作了。

随着数字化的进一步渗透，低代码产品作为数字化工具的进化方向，在特定场景可以提供操作更加友好、门槛更低的使用体验，能够提升工作效率，创造的价值足以覆盖制造和维护工具的成本，低代码就有商业化的空间。但只要是开发还是人在做，以此为职业，目前没有超越语言形式的更好选择。我们一定要再次强调，未来十年内主流的开发市场不会被低代码所占领。

（三）结辩环节

反方四辩 白德鑫

我们所理解的低代码开发，其实是场景化的开发。它能在某个特定场景下解决某一个问题，但对于通用型、产业化的场景，差距仍旧十分明显。对企业来说，业务场景的复杂、反复就注定了低代码平台无法成为主流，只能在OA系统等内部流程管理方面做到有效应用。

对于产业分工这件事，开发人员的角色已经越来越清晰，而这些开发角色之所以成为主流是因为分工的定义已经明确，但对于低代码开发的角色和功能的定义，目前大家也并不清楚。如果未来十年内低代码要成为主流，那首先请解决这个角色定义的问题。

另外一方面，从市场的角度看，低代码也未必就能脱颖而出。的确当前市场都在谈论低代码，但企业应用的复杂性要求开发人员的专业性，可视化低代码开发的手段能否做到足够专业，这些都需要市场供给端和消费端来看结果。此外，市场环境下的企业IT投资，系统建设都是垂直烟囱式的建设，各个系统间可能是孤立的，打破信息孤岛也需要开发人员的能力，未来十年我们能否靠低代码解决这些问题，答案显然是不太可行的，这也是低代码难以覆盖主流开发市场的一大原因。

今天的讨论折射出大家对低代码的定义是不清晰的，它的边界、应用场景没有明确化和定义化，由此带来对开发行为的逻辑也没有完全区别清楚，我们是通过低代码满足核心需求，还是满足独立某一个场景的需求，这是我们判断它是否是主流的一个依据。

未来十年，随着企业数字化转型浪潮的到来，低代码能否替代企业现有的IT投资？能否打通与整合孤岛式的IT系统？我方认为现状并不乐观。综上，未来十年内，低代码可能会流行，但并不会占领主流开发市场，我们还是要通过开发去解决需求和性能问题。

正方四辩 崔红保

未来十年，数字化转型升级是大势所趋，必将催生井喷式的需求，至少产生十倍于当下的软件开发需求。这个需求如何解决，最简单的方法是补充更多软件工程师人才，但这个培养成本和难度都非常高，无法从根本上解决人才缺口的问题。引入自动化工具，改革当前开发模式，是可预见的解决方案，这些都与低代码的目标一脉相承。

我方认为，所有少编码、快交付的框架、工具、平台都可以称为低代码，我们应该从更高维度去看低代码的发展与应用。现存低代码的问题基于当前时间点，但我们研究的话题是“未来十年”，从计算机发展的历史看，十年时间足够低代码解决很多问题。即便是当下，低代码也在传统行业内挖掘出了大量应用场景，它的潜力十分可观。

对方辩友提出的低代码现存的标准规范问题、信息孤岛效应问题等等，在现有传统开发模式下同样存在，这些问题的解决应该是基于数据驱动去实现，而非要求低代码厂商具备同样的实现规范。

有关于低代码与开发人员的关系问题，业界有过争议，低代码对于开发人员而言，是为了将他们从增删查改的重复性、机械化工作中解放出来；对于业务人员，低代码是使用工具，而非代码编辑器。纵观人类历史，任何一个行业都在逐步由刀耕火种的人工操作进化成机器自动操作，科技的发展历史，就是逐步减少人类手工操作的历史。农业、工业如此，软件开发行业，亦会如此。未来，工程师手工编码的工作一定会越来越少，而减少的工作，就是通过低代码实现的。

低代码的占领主流，不代表它就要占到70%-80%，Java语言是主流的企业级编程语言，请问它的占比超过70%了吗？显然没有。主流是一个被广泛接受的概念，从长远的发展角度看，低代码成为主流几乎是一种必然。

我们不应站在不缺人力财力的大公司平台位置上，对低代码现状进行单纯的批评和抵触，大家更应该从真正普适的中小型企业、广大的传统行业中去看看数字化转型现状，这个时候大家才会发现低代码的普惠价值。最后一句话总结，用技术普惠众生，让数字世界更繁荣，应该是我辈技术人的目标和追求，智慧的技术人不仅明察当前，还要预见未来。通过我们对低代码的系列分析，我方认为未来十年，低代码会占据主流开发市场，谢谢大家！

这场从行业现状入手，立足于技术、应用与生态的精彩辩论落下了帷幕，在全场观众与TVP专家的共同见证下，正方“低码38.6℃”队获得了最终胜利，正方四辩 DCloud CTO、腾讯云 TVP 崔红保荣膺本场最佳辩手。

本场辩论赛主持人腾讯低代码技术专家、前 TechParty 组委主席 揭光发按捺不住内心的激动，作为一名有着多年经验的低代码行业从业者，他也在低代码的定义理解、低代码和高代码的关系等方面分享了自己的真知灼见，为与会者提供了值得参考的补充视角。

激烈的辩论赛结束后，进入了同样精彩的圆桌环节，ClickPaaS CPO、腾讯云 TVP 马俊；精鲲科技 CTO、腾讯云 TVP 葛丁佳；作业帮基础架构负责人、腾讯云 TVP 董晓聪；腾讯低代码 Oteam PMC 逻辑编排负责人 陈玉云，以及腾讯低代码技术专家、前 TechParty 组委主席 揭光发，围绕低代码的应用、演进与碰撞等方向，畅聊了低代码的变革与未来。

（一）低代码，杀手级应用何在？

马俊：无论是低代码还是高代码，最终目的都是开发出应用。低代码的优势在于：软件生命周期管理中的灵活性优势，代表领域就是敏态应用，代表形态是 CRM。CRM在企业应用中需要大量的人力维护和管理，这些未来都可以交给低代码去实现，得益于低代码平台的灵活性和弹性。除了敏态应用以外，快速、阶段性的应用也适合利用低代码系统来开发，即低代码适合应用于在使用需求上会不断发生迭代变化的场景。未来如果出现杀手级应用，除了前面的这些场景之外，包括办公、行政等偏运营的方向都很有可能。未来数字化运营方向可能会是低代码杀手级应用诞生的摇篮。

葛丁佳：低代码应用场景一般可以分为以下几类：新兴行业，纯长在SaaS之上，面向业务运营人员为主；应用开发类，一般用来快速开发跨多平台（PC/移动）的微应用；组织内部门协作工作流类；技术类工具，如自动化、数据集成等场景。使用对象也大体分为三类：专业的研发人员、非研发技术人员、业务人员。低代码更多解决的是对业务、技术能力的抽象，缩短业务人员和 IT 人员之间的理解鸿沟，让他们跨越层级去使用一些场景。因此，从我们的实践总结来看，低代码更多的应用机会可能在于连接的能力，整合、编排的能力。比如像超级自动化这样相对较新的概念，以创造业务价值的方式来快速整合各个领域的能力，形成合力。

董晓聪：目前我观察到低代码的应用场景更多基于可视化操作，只需加少量代码就可以快速生成新的应用。在低代码出现之前，CMS、CRM、BI、BPM 这些工具也都有类似的趋势。目前主流的低代码底层模型本质上还是在做信息流的封装，然后覆盖越来越多的场景，但也随之带来个性化场景成本攀高的问题。我的观点是信息流场景上不会突然出现杀手级应用，低代码未来杀手级应用的颠覆更多是在于走出单一的信息流场景，结合现实和场景赋能整个产业，才能真正脱颖而出。

陈玉云：我所理解的低代码是使用少量代码或零代码去生产应用的方案的概括，它不是一个特定的技术点，也已经应用在很多行业中。从To C的视角看，低代码的理念在很多流行应用中都有所体现，比如重大事件时的腾讯文档在线的多人协作，比如QQ空间拖拉拽装扮的方式，比如微信小程序等等。低代码和产品结合，让用户获得高度灵活的定制能力，既能够使用产品，也能在产品里进行创造，就可能成为一个行业的生态，所以我的理解是杀手级应用可能会以低代码开发工具以外的形式出现。

揭光发：杀手级应用要解决的是普适性的问题，因此我们可以从这个角度去思考，在To C领域，文档、笔记类的应用场景受众多，需求大，机会也更大。而在To B领域，我认为企业通讯、企业IM是一个比较大的流量入口，未来很有可能会演化出一个杀手级的低代码平台。

（二）低代码与开源如何共生？

马俊：低代码和开源天生是一对好拍档。无论低代码和开源，其本质都是为开发人员提供赋能工具，帮助开发人员更容易地开展工作。开源是通过提供框架让大家复用，低代码是通过组件的方式让大家复用，且无论是哪一种方式，都要基于业内人员的协同，二者的目标、实现路径高度一致。

Gartner提出未来的应用都是组合式的，它会把应用的开发分成三个不同角色——装配者、聚合者、建设者。无论是组件还是最终的软件，本质上都可以通过开源的方式来写，但在组合式应用的愿景中，它只是一个可以被复用的组件。组件可以是很小的前端组件，也可以是很大的人工智能应用。在这种模式下，开源跟低代码形成了完美的天作之合。从我个人角度看，未来代码和开源社区高度融合在一起，将真正形成软件开发行业的变革契机，通过工程化的方式生产软件，而非作坊式的开发和生产。

葛丁佳：我的逻辑跟马老师是一致的，在我们看来其实就是框架和组件这两层。框架在低代码里属于编排，可以做条件规则、逻辑的拖拉拽。组件则有灵活的拓展性。以一个自动化的低代码平台为例，组件可以建立一种范式、提供一些开源组件的接入标准，引入社区开发者一起共建，然后一起拓展组件的种类，使平台通过不断扩充的组件编排出各种能适用于不同场景、从而形成生态。我们也有做一些实践，把自己的工具和框架、插件能力开源出来，让大家可以按照一些规范去开发适合自己场景的组件，服务自己的同时也为开源社区做出了贡献。

董晓聪：我是从低代码在商业化和开源之间的平衡来看这个问题的。开源给软件行业带来了巨大的价值，十年前的企业需要租机房，造中间件的轮子，现在只需要通过云原生的能力，就可以在稳定性、成本、效率和安全等方面取得较高水平。当前的低代码平台主要是商业化企业在做，乍一看低代码行业的开源和商业化是泾渭分明的两个方向，但其实从我个人角度看，参考开源商业化的模式或许能给低代码的商业化带来更多价值——通过开源让更多开发者参与进来，完善场景，共建生态，再充分利用云服务的能力，打造更广义上的云原生商业和生态模式，也许更有期待。

陈玉云：目前市面上的低代码产品都有各自侧重的领域，其之所以能够提效，是因为把领域耦合进了平台，通过集成专业领域的业务逻辑然后复用使其高效，这也是其存在差异的原因。如果没有统一标准，未来肯定会出现更多问题，协作上也会多有不便。我们目前在建设一个对外开源的引擎框架，帮助想搭建低代码平台的人实现更快速的搭建。除了最核心基础组件的开发，我们也在参与大湾区、信通院等相关标准的建设，这样也许能给行业带来一些新的价值。 

揭光发：开放代码其实只是开源的一个表象，开源现在更多是一种商业模式。就像数据库一样，低代码也算是基建类的软件产品，通过开源的方式让大家能够使用，也是给开发者提供信心。国内国外也有很多低代码领域的开源产品获得了大额融资，这也是开源跟低代码看得见的协同关系，从商业的角度看，开源的方式能给低代码、开发者、市场带来更多信心。

（三）低代码会和程序员“抢饭碗”吗？

马俊：我个人认为一个面向未来的，有追求的，愿意学习和适配发展的程序员应该是能够接受低代码的，在这个过程中最重要的是要去拥抱变革而非拒绝变革，不断地往上走，成长为一个架构师、数据工程师，或是算法设计师等等，跳出当前能力范围之内的“舒适区”，会更有利于个人长期的发展。

葛丁佳：我也赞同这一观点，程序员应该做难而正确的事情。在低代码本身发展领域来看，低代码已经在不少领域和细分场景帮助程序员把部分重复的工作抽象化了，未来更多的发展方向我认为一个是当前的低代码还能否从技术本身再去抽象，变成多流合一的场景；第二个是低代码平台的健壮性和兼容性的扩充，能否持续满足更多的业务需求，在这个过程中，我们不仅是做垂直领域深度的能力开发，还需要关注业务上快速敏捷化的交付，比如开发一些业务组件的低代码，让业务人员能直接使用这些组件来提升业务敏捷性。这些都是我认为未来程序员可以与低代码“共舞”的方向。

董晓聪：低代码平台代替的更多是简单流程的处理，这并非开发工作的核心。在我看来，低代码长期以来对软件领域和整个行业产生的是正向、积极的影响。开发者在低代码时代应该如何自处？我认为可以做这样的转型：一方面应该更多关注能够体现个人及岗位价值的事情；另一方面，通过熟悉并掌握低代码平台来提升自己的生产效率。通过各场景低代码平台的普及，软件工程师可以更高效地助力产业数字化转型。

陈玉云：总的来说，低代码掀起了一个新的开发浪潮，但它并不是要取代程序员，而是补充、创造了更多的可能性。正如网约车平台给出行行业创造了更多的工作岗位，传统的出租车司机虽然多了竞争对手，但他们也可以直接通过软件接单受益。同理，低代码降低了研发的门槛，让更多人可以参与其中，其实是催生了一个新的生态系统。

揭光发：在我看来，低代码和高代码是相辅相成的关系，低代码是帮助业务团队更快速高效地去做项目，但现实的情况是有很多公司并没有严格区分业务团队和研发团队，二者通常融合在一起，因此会认为低代码会对团队造成冲击，产生抵触情绪，这是低代码面临的一个挑战。

当云计算刚出现时，质疑的声音从未停止，可随着时间的发展，云计算已经成为了数字世界里，水和电一样的“基础设施”。

低代码在当前所走过的路，与当年的云计算何其相似。有人说低代码是新瓶装老酒，也有人说低代码能改变未来的软件开发生态，但未来究竟如何，终归需要人去趟出来，这就是TVP发起本次技术分享会的初衷所在。

用科技影响世界，让技术普惠大家，下一期TVP技术分享会，静候你的光临！