从低代码的骂声说起

从 Forrester 在 2014 年提出低代码和零代码的时候开始，关于低代码争吵声就一直持续到现在。至于现在的现状就是做低代码的人一面持续的鼓吹市场越来越大，低代码市值也确实在增长，而低代码的用户一边买着低代码产品，一边把抱怨低代码实在是太难用了。一边可以看到 Gartner 这些机构对低代码的乐观预测，另一边你可以在知乎搜一下“为什么程序员讨厌低代码”，然后看到无数的敌意。这些割裂的观点让我开始思考关于低代码相关的一些事。

最近一年多时间做的产品里面有低代码的功能，但是我不会说我是做低代码的，因为我也承认这个概念其实是个噱头，是割外行韭菜的一把花里胡哨却十分难用的镰刀。

看了很多低代码相关的文章，但是都是浅尝辄止，大都简述了低代码的能力和边界，没有说到本质，也没有给出解题思路。

低代码本质是做什么？提供什么价值？问题在哪里？应该朝什么方向发展？有些问题我也还没想明白，但尝试着梳理梳理。

一些观点

关于低代码，我跟两位老专家聊过几句。

一位是这么说的：“你们不要迷信低代码，不要钻这牛角尖，那种什么托拉拽画好了图又去生成代码，再运行代码，那不是脱裤子放屁多此一举吗？什么一个方块拖进来，填几个值，串起来就能运行，这种玩具有个毛用？”。

另一位我在给他讲了下产品思路之后，他问我“你们为什么不能模型即代码？”我楞了一下，因为之前也没有想过这个问题，后来我也一直在思考他所提出的问题的本质。

低代码是这么说的：

- “可以降低编程门槛，让业务人员通过托拉拽，就能编写一个应用”，如果你用过 dreamever 你就知道什么意思，或者理解为通过 PPT 写程序。

- “可以降本增效，并且完成代码的标准化，用我们的产品就不需要高级程序员了，找几个实习生快速生产出系统”，而且每个框框标准化了，看起来代码也就标准化了。

但是可以简单地提两个问题：

- 能用低代码写 linux 内核吗？或者可以帮我降低门槛让我托拉拽出一个 Windows OS 吗？

- 如果一个框框里需要覆盖 10000 种分支可能，你还愿意去开发这个框框吗？

好像以上问题涉及的场景就不在低代码的覆盖范围内了。大部分人认为目前人工开发的低代码应用是无法覆盖复杂逻辑的场景的。

chatgpt：“？”的确，AI 已经是低代码的新解，也是半个正解了。为什么说是半个，因为现在还是 ANI，而不是 AGI。如果到了 AGI 的世界，一切即代码，AGI 应该可以解决除了部分创新以外的所有事情。

关于复杂度

如果低代码的边界之一是复杂读限制，那么自然会想到人月神话里提到的“复杂度”概念，本质复杂度和偶然复杂度。软件是把真实世界逻辑抽象成计算机逻辑来求解的一种手段，本质复杂度就是指真实世界逻辑复杂度；偶然复杂度是指方法不对等偶然因素导致的搞不定因素。这里就只说本质复杂度的问题。

软件行业通过抽象来解决真实世界问题，抽象的结果就是程序，而所谓的零代码就是假定只要逻辑抽象出来，就直接运行，over，项目完成，万事大吉。能做到吗？这个假定中隐含了一个非常重要的步骤，就是目标问题的本质复杂度被消解了。

技术复杂度

知乎上对于“为什么程序员讨厌低代码”这个问题，大部分人抱怨的是低代码工具的灵活性、可扩展性、易用性等等表面问题，而在最高赞的回答里指出一些低代码工具无用的根本原因是因为它并没有消解掉问题的本质复杂度。他说低代码的本质其实是封装和抽象，其中举了一些正面的例子比如：SQL 作为一种 DSL 语言，它的良好封装使开发在操作数据库的时候不需要写复杂的数据库底层操作指令，而是通过 SQL 加 SQL 语法解析器，解决的操作数据的复杂性；比如 WindowsOS 作为操作系统，将 CPU 指令、IO 指令等封装成简易的界面操作来解决操控计算机的复杂性；比如你在 JAVA 代码去发起一个 http 请求，是有很多工具包将整个网络通讯的过程封装屏蔽，你只需要调一个 client，而不需要管协议转换、封包拆包、握手、DNS 寻址等等事情。

这个答主是技术人员，他从技术的维度出发，给出了关于技术低代码的一种解，即是把技术实现封装，把指令接口暴露给用户。

业务复杂度

那么业务复杂度呢？低代码可以消解业务复杂度吗？

工具能否做到对底层业务逻辑的完美封装和抽象，能够让领域专家能够托拉拽就能设计出一个系统呢？如果可以，那就真正实现了零代码，实现了“模型即代码”。比如一些 OA 系统，国内有公司在做这类低代码；比如 SAP 的插件；比如面向物联网的 Thingsboard 这种低代码工具。但是他们都做不到零代码，卖给客户以后都需要二次开发；或者允许客户开发插件，插到系统上运行；或者直接开源代码，由社区共同二次开发。有时候当业务提出新需求的时候，低代码工具就是首先需要修改的东西，低代码工具先改好了，再由用户托拉拽出新功能。这种先让低代码开发人员升级工具，再由设计人员托拉拽开发业务功能的方式比传统上找个业务开发人员直接开发业务功能甚至还麻烦。

这一切似乎说明了底层商业逻辑的复杂性和业务场景的差异化特性，本身是很难做到完美的封装和抽象来使其达到一出厂即满足未来需求的可能。尤其像 ERP 系统，金融系统，电商系统等大型复杂系统场景，业务复杂度很难被完美封装。即是强如 SAP，大多时候也需要工程师到现场实施和二次开发的。

SAP 是一个支撑企业做 ERP 的工具系统，感觉上工具并没有消解 ERP 的业务复杂度，因为 ERP 的核心是管理，SAP 并没有越俎代庖去管理用户的企业，所以管理的业务复杂度完全还是在用户方。但是，SAP 的产品，或者华为 ERP 的产品却是按照一个产业的业务架构来搭建技术架构，从而实施的系统。所以它们提供的并不完全是软件产品，而更是业务架构和业务方法论。

工具是业务架构和方法论的载体，而本质上业务架构和方法论才是为用户提供的一种降低业务复杂度的方案和解法，我不控制你怎么做企业资源管理，但如果你懂我的这套知识和方法，做管理将手到擒来。

复杂度的收敛

所有的低代码工具，都将设计功能留给了用户，由分析人员做业务建模，设计人员做系统设计，低代码工具产生代码。在这种方案下，如果工具从技术上和业务上达到了完美封装底层实现的要求，总可以做到零代码了吧？业务建模和设计已经消化了开发态的复杂度，工具直接生成 jar 打到容器直接就该能跑了啊，还生成代码干什么。老专家对低代码的解释是这样的：“低代码是指减少最终的代码量，而非把写代码变成画代码，然后自动生成代码。真正能够实现低代码的途径是让业务建模或设计成果直接进入运行态，而无须在过程中通过任何方式把建模或设计成果转化为代码”。设计即运行，那不就是零代码么，这样行不行？行。只是回顾一下传统的开发方式。我记得我以前在深圳的时候，接到业务人员电话：“你来我这一下，有个需求”，然后自己分析设计开发上线一条龙。自己设计的时候即使做到很细，开发的时候真正动手的时候才会想到一些问题再去确认需求。开发是一个思考实现落地的过程。如果要实现设计好即运行，那只是把开发这个过程的成本转移到设计上，设计要完成所有的细节，所有的分支，其实还是在“画代码”，但好处是不用再生成代码了。唯一的问题是，相比于“画代码”，开发人员可能更倾向于“写代码”，于是对着“低代码”又一顿喷。

如果再退一步，我们加上几个条件：1、假设有神人团队非常牛逼，开发出了一套低代码工具，从技术上和业务上达到了完美封装底层实现的要求；2、设计人员也非常牛逼，设计即代码，托拉拽好了就能运行所有需求，但这个系统直接上线就能使用没有问题？

我大学的时候专业是软件工程，我现在都记得这门课的老师，一个穿西装的中年教授。他在讲台上说：“很不幸，你们选了一个垃圾的专业，软件工程是一个没用的专业...”，我们坐在下面一头问号，后面的话我当时就没听了。只是会想：那特么开设这个专业做什么？后来在工作中去慢慢体会将软件作为工程来看待这一举措的意义。它除了项目管理的意义之外，把软件开发通过工程科学来处理，加入分析，设计，测试，部署，维护等等措施的一个重要作用就是收敛软件的复杂度，提高正确性。

所以低代码只是开发态工具，最多到达“设计即运行”，却无法到达“设计即可用”。

关于降本增效

今天开车路过宜家，想到大型软件市场其实很像装潢市场，以前装修都是家装公司，接了全包的单子之后自己找材料，找师傅手工基装，找师傅手搓家具，最后完成全套装潢。各家的核心竞争力都是好工匠，比的是人，比如多找几个做了 10 多年柜子的师傅，甚至是去欧洲做过家具的师傅，你的单子就是要多点。工匠之间也有鄙视链，且每一个工匠都觉得只有自己的作品最优秀。直到后来山那边来了家搅局的，叫宜家，生意爆棚，用户买账。本地企业都来围观，本地工匠也来围观。大家发现宜家有点不一样，家具这块不是靠人上门量尺寸，听需求，全程手搓，而是标准产品化。工匠们凑近仔细一看：这些桌椅板凳样式很简单，材料很一般，手艺更一般，价格低廉，啥玩意儿，呸！

但从宜家的财报来看，却是成交量巨大，且施工周期很短。家具都是一套零件，简单一拼完事，而不是上门现切木板现刷漆。

大型软件市场也差不多，内包的，外包的，或者买产品。只是由于业务场景的差异化很大，而软件界最不缺的就是工匠，所以绝大多数还是自己招师傅手搓系统，并坚信只有自己手搓出来的还是最好最适合的。

宜家对于“低施工”交了一份答卷：

• 首先用标准化替代定制化的手段减少了用户的选择，通过搭建了一些样品房来给出成套的解决方案 demo，给用户展示用标准家具产品来做整体方案的可行性，并为用户降低了家装设计难度即业务复杂度；

• 然后用高压板、实木板、可选图案贴纸等产品预制，很大程度地减少了制造的价格和时间成本；

• 最后通过优化家具的安装接口，简化安装难度，提升用户体验，为用户降低了家装实施难度，很大的提高了安装效率。

但是相应的，问题也很明显，如果用户是高端家装，或者室内场景很复杂，宜家就不适合，而宜家也没有投入很多去大力兼容这些 edge cases。

当然，家具形制的复杂度跟软件相比还是过于简单了，产品经理不会提出一个柜子一会儿可能是 U 型，一会儿可能是 Z 形并在支撑轴上围绕 20 根斐波那契数列间距的三维螺旋平行装饰并可绘制自定义图案等等需求。

而 ToC+ToB 的用户基数和住房刚需量也允许了宜家用明确的市场定位和用户定位给出它的“低代码”解法。

总结

所谓“低代码”，核心不在代码量，如果作为 IT 从业者，不关注产品能力本质上解决什么问题，而是仅仅将“降低代码量”作为一种产品价值，那才是 low。

那“pro-code 强代码”又是在做什么，它是跟低代码的思路相反吗？不是，其实是解决不同层面的问题的概念。“低代码”一般封装实现暴露设计接口，是面向设计的设计类工具；“强代码”比如 IDE，是面向实现，面向代码的，封装的操作系统指令、运行环境、文本展示能力等等属于代码类工具。

做工具类产品（不管低不低代码），我之前写 PPT 写过很多价值，解决了好多好多的痛点问题，现在归纳一下，其实也就是消解复杂度和降本增效两个价值。消解复杂度一部分其实也属于降本增效，但还有一部分是增加可行性，因为有些东西如果没有工具可能玩不下去，或者至少没法创新。而比如数据资产管理其实是算在降本增效里。

所以工具类产品的解题思路大致也就是两类：

• 一类是解决复杂度。极端的例子比如光刻机，因为不是找一百万个人拿锤子、钉子和硅晶圆就能搞出芯片的。

• 一类是降本增效。降本增效这件事可大可小，有的可以省个三毛五毛，有的可以掀起工业革命。

那么自然地，工具要想有价值，至少思路是在技术/业务复杂度或者降本增效两方面，不然都是空了吹；其次产品力咋样，就要看封装和抽象的功力了，网上被骂体验的大多就是没有做好开闭，不能快速而良好的扩展；最后则是体验和生态，UI/UX 设计，提供运行环境，调试能力等等。

后记

想写这个话题的原因是做了一年多相关产品，在经过那些 996，那些五花八门的奇葩需求，那些无穷无尽的定制扩展，那些做了的觉得毫无意义，那些觉得有意义的不被接受，那些不是初衷地强行杂糅进系统，那些“懂不懂设计理论”的质疑之后，就很想思考出个结果：MD 搞这玩意究竟价值是啥？做出来究竟解决的啥问题？是坚守标准化还是接受定制化？究竟怎么开闭？代码很多但实际就做了这么个事情的产品，后续能怎么发展？往哪发展？

可能总结出来之后答案很简单，AI 一秒就能回答出来，写了半天写了个寂寞，就好像走进宜家看了看，觉得不就是这么搞吗？我也会。但实际上要往前走，可能还是走三步想一想退两步再走。只能说所得可能在底层思考这个过程本身吧。

如果能看到这，那真是要握个手，希望能带来一些思考，感谢！