25 遭遇程咬金，低代码技术会被AI大模型替代吗？
你好，我是陈旭。
这一讲的标题等价于：身为低代码架构或开发的你，你的工（fàn）作（wǎn），会被AI大模型取代吗？在去年大模型展示了它的实力之后，几乎各行各业的人都在扪心自问。
我们都知道AIGC的含义，其中C是Content（内容）的首字母，但在低代码领域，我更愿意将C解释为Code（代码）。在这里，Code是Content的子集，这就是大模型技术落地到低代码技术领域，或者说大模型落地到研发领域时，它的价值的具体化表现。低代码技术的输出也是Code，大模型技术也可以输出Code，在这个角度看，将这两者的关系定义为竞对关系是没问题的！所以，身处低代码领域的你我，更应该感到危机，不仅要深入思考这讲的这个问题，还要想办法让低代码技术和大模型“化敌为友”，从而借助大模型，让低代码技术变得更加强大，而不是相互替代。
阿里巴巴CEO张勇先生在去年4月曾说过：面向AI时代，所有产品都值得用大模型重做一次。第一次听到这句话的时候，我深不以为然，但随着我在日常研发全流程中，在广度和深度上深入使用大模型，我越发觉得，确实是“所有产品都值得用大模型重做一次”。在我深耕的低代码领域，当然也“值得用大模型重做一次”。
低代码技术是如何解决实际问题的？
在开始之前，我们来再次思考一下，低代码技术是如何解决实际问题的？这个问题我们曾经思考了无数遍，但是这次，我们要从低代码技术的强项和弱点的角度来思考这个问题。
可视化编辑+所见即所得组合拳是低代码技术最常用的手段，也是它吸引人的地方。可视化是手段，所见即所得是结果，两者相互配合，形成了低代码技术的杀手锏。
可视化编辑技术的常用形式有：
- 将原来要用代码编辑的地方改为表单的形式。
- 枚举类型配置项都采用下拉选择的形式。
- 根据相关参数联动、自动填写和自动筛选。
- 配置过程及时校验，提前报错，减少试错次数。
下面两个图是同一个功能的两种实现方式，第一个图是直接代码编辑的方式。
第二个图是可视化配置的方式。
放在一起对比，就很容易看出可视化配置的优势了。
所见即所得的形式很多，前文可视化配置过程中实时联动及时报错，是其中的一种，但更主要的形式是，配置完成之后，立即显示最终结果，从而完成快速迭代，比如下面这个录屏就很好地展示了编辑器在编辑 App 界面的时候，每一次用户的鼠标和键盘操作之后，都可以快速将最终结果显示出来的效果。
到现在，我们说的都是低代码技术的杀手锏和优势技术，但我们今天不是要自我陶醉，而是要看清楚低代码技术的优势和弱势。
我们继续思考。现在来对“实际问题”做一些分类。
就拿Awade输出的数以百计的App的经验来说，开发一个实际App，主要做两个动作：实现App的描述性任务和逻辑性任务，这两种任务会同时出现在同一个App中，虽比重各不一样，但极少只有其一的。
其中Awade是我司研发的低代码平台，请你稍微记住这个词，下面我就不再提醒。
描述性任务主要涉及信息的展示和界面的设计，它们关注的是数据的表示和用户与系统的交互方式，常见的有数据展示、用户界面、样式和布局。而逻辑性任务主要涉及应用的业务逻辑和数据处理，是系统动态运作的核心，一般有数据处理和计算、业务流程管理、条件和规则、集成和连接等。
一句话总结低代码技术的优弱势，那就是：传统低代码技术非常擅长处理描述性任务，但不适合用于处理逻辑性任务。
逻辑编排、流程编排、规则设置、数据处理，这些任务的灵活性往往非常高，除非业务系统已经有非常好的抽象，否则这些任务面对的问题基本都是不可预测的。在这个情况下，采用可视化技术来解决这些任务，要不然就会让操作过程变得极其复杂和反人类，要不然就必须放弃可用性来换取易用性。无论哪种情况，在应用眼里，低代码在这里就是表现得很差。
说到这里，就不得不提一下低代码技术的不可能三角，如下图。
这个不可能三角表达的是开发效率、易用性、可定制化这三者最多只能拥有其二，而必须放弃第三个，三者不可兼得。
随着低代码编辑器功能越来越强大，其使用效率和易用性逐渐螺旋下降，越来越复杂的编辑器意味着学习曲线越来越陡峭，用户的学习周期和试错次数越来越长、越来越多，总体来说，其效率将越来越低。传统低代码编辑器的易用性和功能丰富程度（即复杂度），大概定性地呈下面这样的关系。
大模型给低代码带来了什么？
传统低代码技术在处理逻辑性任务时表现很差的原因，归根结底，还是因为我们的工具箱里只有可视化一个工具。说实话，我在低代码领域深耕6年，这个问题几乎就困扰了我6年，我无时无刻不在苦苦思索这个问题的出路。有句话说得好，当你手里拿着锤子，那满世界就都是钉子。走了许多弯路，但无一可以有效治愈我的痛点。
直到去年7月的一天，我打开了ChatGPT的网站。之后的故事可能和你的一样，日常研发全流程都基本都被大模型渗透，既有广度又有深度。我很快意识到，大模型就是我想要的那颗钉子。
为啥呢？
因为大模型带来了将自然语言作为输入手段的可能性！自然语言可以用于处理逻辑性任务，从而弥补可视化手段的不足。自然语言处理逻辑任务的方式有很多，处理的方式与所用的NLU（自然语言理解）的能力有非常大的关系，这里的NLU就是LLM（大语言模型）的核心能力之一。低NLU能力下，必须要用自然语言按步骤描述解决问题的逻辑，在高NLU能力下，可能只需要简单描述业务目标就可以了。这部分以后我们还会展开，这里就此打住。
但，自然语言不是处理逻辑任务的完美手段，因为它：
- 逻辑不严谨，不仅常常不能自恰，甚至还前后矛盾，或者表述有歧义。
- 效率低，往往需要长篇累牍才能相对严谨地描述一个逻辑。
- 非结构化非标准化，自然语言常常过于随意和自由，缺乏统一的标准。
是的，自然语言问题很多，但是它却有一个碾压性的优势：几乎人人生而具备这个技能。低代码的核心目标之一是将软件开发的门槛降低到人人都可以掌握的程度，没有其他任何手段比自然语言更契合低代码技术的这个目标了。自然语言可以也必须成为低代码技术的解决方案之一！
自然语言不仅适合用于处理逻辑任务，还可以用于处理描述性任务，替代一部分可视化编辑方式。自然语言有无可比拟的灵活性，利用这个灵活性，可以避免开发许多流程类或者表单类的可视化界面。比如这样一句话，“明天上午10点我要到新街口和小明吃饭”，就包含了许多信息，假设你要开发一个表单来采集等量信息，大概需要的是一个这样的界面。
虽然现在的前端技术开发这样的界面，对于一个熟练的码农来说，一两个小时就足够了，但是，加上后端开发API，数据库DAO，前后端联调，前期UX介入，后期QA要测试&验收，全流程走下来，半天能走完流程算非常高效，协作不好的话，花个两天也不是不可能。
一个较成熟的低代码编辑器，这样的表单是数以百计的。这么多表单，形式各异，各有各的用处，只能一个功能点开发一个表单来应对。
如果采用NLU的方式来采集这些信息，则前端只要开发一个人机对话框，后端做好NLU和实体提取，基本上就可以承担大多数表单的职能了，这也意味着开发这些表单的工作量可以砍掉。按照Awade的经验，我们有大概60%70%的工作量投入在这类工作上，假设NLU只替代掉一半的界面，那也可以节约将近1215人一年的工作量！真香！
当然，自然语言也不是处理描述性任务的完美手段，因为它的效率比可视化方式要低，在特定场合下效率更是比可视化方式低得多。这也就是我前面给出只能替代掉一半可视化配置界面的比例的原因。
而且还可能会有学习成本。你可能会奇怪，为啥自然语言还有学习成本？很简单，当用户面对一个光秃秃的自然语言输入框的时候，他很可能都不知道要说啥。此时，就需要有针对性的指引和提示，对用户来说，这就是学习成本。当然了，说基于自然语言替代可视化配置有学习成本，那实在是鸡蛋里挑骨头，可视化配置界面设计得不好，也一样难用和反人类的。
这点短板相比于能节约天量的工作量来说，实在是微不足道啊。
根据前面我们说到的传统低代码编辑器的易用性和功能丰富程度（即复杂度），大概定性地呈下面这样的关系。
围绕自然语言来做交互设计的话，我们惊讶地发现，我们可以做到在保持功能数量不变的情况下，减少可视化配置界面数量，从用户角度看，那就等于界面变得简单简洁了，等效于在上图的x轴上往左挪了，因此，低代码编辑器的整体易用性也就提升了。或者换个角度来说，围绕自然语言来做交互设计的话，随着功能丰富程度的提升，低代码编辑器的易用性下降得非常缓慢，几乎保持不变。定性示意图如下。
快速做一个小结，自然语言给我们带来了3个重要价值。
- 它是处理逻辑性任务的合适手段。
- 它可以替代一部分可视化编辑方式，显著降低低代码平台可视化配置的开发工作量。
- 它提升了低代码编辑器的整体易用性。
说到现在，你还犹豫啥呢？抓紧一起来将自然语言武装到我们的低代码平台上吧！
可视化方式仍是小甜甜，还是成了牛夫人？
这个问题要分两个情况讨论。
- 如果你现在才开始从零构建低代码平台，那么，可视化方式就是牛夫人。
也就是说，此时应该围绕以自然语言为中心来设计大多数的交互，可视化只是在自然语言低效，或者某些业务逻辑单一且变化小的领域里打打辅助。
- 如果你和我一样，手里拿着一个成熟的低代码平台，那么可视化方式当然还是小甜甜。
也就是说，我们没有必要，实际上也不太可能把已有的可视化配置方式全部废弃，围绕自然语言重新开始，自然语言再好也只能作为辅助手段，不过，再演进个一两年，难保自然语言方式不能成为主要方式。
无论如何，可视化方式是一种人见人爱的方式，它有高效、简单、所见即所得的优势，可视化方式不应被抛弃。小孩子才做选择，成年人当然是全都要了。与其考虑用谁替代谁，还不如多花一些脑筋想想如何融合这两个工具，充分发挥他们各自的优势，而避免它们的弱势。这也是我们接下来若干讲的主要内容了。
小结
今天这一讲我们回顾了低代码技术是如何解决问题的，在回顾这个问题的过程中，我们发现我们的工具箱里只有可视化这一个工具，我们尝试用这个工具来解决各种各样的问题，有的问题解决的效果很好，有的问题解决的效果不好，无论如何都无法令人满意，这实际上就是低代码技术至今一直受到质疑的地方。
通过总结，我们发现，那些解决效果好的任务，基本都是描述性的，比如数据展示、用户界面、样式和布局等这些任务，可视化技术就可以很好地应对，但是对于那些侧重逻辑方面的任务，可视化技术的表现则令人不满——做得简单了无法解决实际问题，能有效解决实际逻辑任务时，又必须将自身设计得非常复杂，这又背离了低代码技术低门槛这一重要的价值点，依然被诟病。
大模型拉开了AIGC的时代，AI可以很好地生成代码，而我们的低代码技术的目的也是要生成代码（或由代码驱动而来的业务），我们似乎可以得出结论：大模型是我们的竞争对手！但是，经过我们的仔细分析，发现大模型不仅不是我们的对手，而且还是我们的帮手，我们的工具箱里不再只有可视化这个工具，现在还多了自然语言这个工具，这个工具是我们人人生而就有的，它可以解决可视化技术的许多问题，甚至可以在一定程度上替代可视化技术，成为新低代码架构舞台中心最亮的仔。
你还记得咱在开篇词讨论的那个问题吗？——低代码还是银弹吗？
当然是！
在大模型出来之前，低代码架构师们的工具箱里只有可视化一个武器，但已不妨碍他们将低代码玩得风生水起，虽然质疑声不断，但从2019年至今热度不减。现在大模型带来了自然语言这个新工具，恰好可以解决可视化手段的内秉性缺陷。这两者的组合，将让低代码技术带着智能化的翅膀，再次起飞。
思考题
大模型给我们带来的价值，除了前文提到的可以处理逻辑任务，替代可视化编辑方式之外，你觉得它还有哪些价值？提示，你可以结合自然语言的特点来思考这个问题。
第二个问题，自然语言的短板，除了低效、不严谨、容易前后矛盾之外，还有哪些短板呢？希望你能将你的答案留言在评论区里，多多分享。
我是陈旭，我们下一讲再见。
- Demon.Lee 👍（0） 💬（0）
非常期待老师的后续分享：低代码与AI大模型结合后，具体如何落地～
2024-09-12