低代码真的有前景吗

[southcat996]

我们主管一人借助 Vibe Coding 开发了一套低代码平台，目前主要功能如下：

逻辑引擎：支持设置入参、出参，通过拖拽循环、JS 、SQL 节点以及分支节点来编写业务逻辑。 页面快速生成：选择数据表后可快速进行联表生成页面，再结合逻辑引擎和自定义表单，配置各类编辑、弹窗等交互事件。 自定义页面：直接用 HTML/CSS/JS 三件套编写页面，通过逻辑引擎获取数据并完成页面渲染。

在内部人事管理系统上，这套平台确实显著提升了效率，也让产品能够深度参与开发。但当我们把同样的模式应用到考试系统以及业务逻辑更复杂的场景时，问题开始显现。 我在参与过程中明显感觉到，这种开发方式与自己以往的编码习惯差异很大。逻辑引擎实现的业务逻辑处于黑盒与白盒之间，既不够透明，也难以像传统代码那样灵活调试和维护。 因此我想请教：这种低代码模式真的有长期前景吗？有必要继续大力推进下去吗？

[nullEDYT]

目前想到的优点 低代码能固化项目架构 AI 去开发的话 不会跑偏

[southcat996]

@meteor957 被折磨坏了，我用了两天就觉得是垃圾奈何劝不动人家

[southcat996]

@keenkiller AI 搓低代码，然后低代码里面放上 AI 让 AI 再生成业务，感觉纯纯脱裤子放屁

[southcat996]

@JYii 我现在是不参与推进了，我手里有别的稳定的项目，但是后续他们想把所有的项目全部转向低代码

[shaozelin030405]

没有意义，低代码就是换个场景推倒重来。都处理成 schema ，让 ai 全权根据 schema 和需求，创建页面就好。还有，低代码稍微动一下就是 shi 一样的东西

[southcat996]

@supuwoerc 还真别说，我们这套低代码还集成了 BI 了

[supuwoerc]

@southcat996 #106 真的是 19 年的东西，老古董中的老古董了🐶

[exbein]

低代码有他自己的适用场景，搭建活动页面这种 toc 的简单页面比较好用，运营市场很快就能上手，可以减少很多零碎小页面的开发成本，而且平台接入前端基建，长期且稳定，偶尔有新业务可以小迭代一下即可。
搭这种内部管理系统还是算了吧，直接 ai 上手就能改，确实属于脱裤子放屁。

[ukipoi]

1. 可以长期运行,只要业务足够简单,跑个几年完全没问题
2. 只要不出问题,一切都很美好
3. 一旦业务复杂,那就是开发的噩梦.一个写代码可以玩出花的需求,可能就要绕地球一圈才能实现

[lujiaosama]

@supuwoerc 大屏是指 BI 吧，为啥没有，跟业务关系更大吧，跟 AI 不 AI 的没啥关系。

[a0210077]

内部用低代码平台纯纯浪费资源，企业想减少开发人员参与以节省成本
原来开发流程：同事提新需求 > 开发人员干活发布 > 同事用新版本
低代码开发流程：同事提新需求 > 非开发人员拼页面写逻辑发布 > 同事用新版本

实际上同事提新需求一般都是低代码平台做不到的，然后又会让开发人员写个新组件，再培训外部人员，然后回去再调整。最后写了一堆特殊组件，通用的没几个，各个系统有各自的版本，成本更高

[fbiljh999]

看领域, ue 不还在用蓝图

[yiiiiiiiiiiiiii]

不行吧，它解决不了业务需求的真正难点。

[None123]

纯纯脱裤子放屁 +1

[NewYear]

低代码很好用啊。
但是你要搞清楚，你们主管实现的时候，是非常匹配当时的一些场景，就比如你说人事管理。
也就是他的目的达到了，效果也达到了。

那你现在要放到其他场景用，那就开发相应的“控件”啊。
想要一招鲜吃遍天是行不通的。

因为低代码平台、无代码平台，本身是熟悉场景后，定制出来的“封装品”，它本身封装了很多特定场景的概念本身，所以根本不可能通用所有场景。

[lanxisama]

低代码不是十年前的玩意了？

[NewYear]

如果你要通用，灵活。
那你就用传统代码就好了，没问题的。

但是如果公司上层要强推，那你就整理好要封装成哪些“控件”“模块”，然后在上面操作。


你提到“考试系统”不适用，那明显不可能，只可能是没有设计相对应的“控件”。
业务逻辑更复杂的场景，也是可以开发对应的“控件”。

无非就是封装越深，越省事。
复杂逻辑本身就复杂，编写会更慢。

凡事有利有弊，但要灵活变通。

[sjzcxc]

@fengpan567 我觉得也是，他这主管的认知，还停留在 10 年前。

[onionKnight888]

21 年公司强烈推内部的低代码平台，现在还在当时的项目填坑

[pony2335]

必死

[lm930129]

@Sundayz #81 就如果你接触过 OA 系统的话，那都是低代码的。要记住低代码不等于无代码。

[kemistep]

AI 低代码还行，纯低代码早过时了

[Sundayz]

@lm930129 低代码不等于无代码，既然如此更是被 AI 踩在脚下了

[hxy100]

无论是低代码还是 Vibe Coding ，本质上都是人想要偷懒的的不同形式，取决于你想用哪种方式偷懒，低代码不花 Token （平台搭好以后就几乎不花），但无法应对复杂的业务变化，Vibe Coding 需要花 Token ，但灵活度更高，无所不能，所以该怎么选，其实是是看你的业务需求以及你想用哪种方式偷懒。

PS：另外，我个人不同意 2026 年了，低代码一文不值的说法。毕竟 AI 无论如何都是要花钱的，而且要持续花的钱 100%比低代码要多，这个是事实。

[southcat996]

@hxy100 我们是在低代码上继续花 Token ，之前低代码做好之后 AI 介入不进去，导致开发进度慢很多，现在又要接入 AI 去继续花 Token

[southcat996]

@NewYear 就是无限制的封装，我们的项目很杂，上了低代码之后我感觉复杂的逻辑会更加难以维护，而且开发过程中很反我之前的开发逻辑，所有的逻辑都被封进了一套 BPMN 的流程图里面

[southcat996]

@a0210077 我们没有外部人员吧，都是客户提需求做好成品交付，低代码是为了让我们的产品同时能参与进软件的开发中，简单的 crud 就让他们配，复杂点的就让开发去配。。

[MelodYi]

低代码是为了让人编码变容易。现在完全就是被 ai 编码完爆了，没意义。
要不然就是做成 0 代码，仅配置。 要不就是 ai 编码。

[a0210077]

@southcat996 #127 我以为做低代码内部用的系统，原来是给内部用的低代码开发工具。决策层思路清奇，建议留一个接口让产品直接输入配置文件，然后一键出页面，这样产品也能用 AI 加速开发

[sumonian]

固定场景还是有用就是了

[cgpiao]

还有专门的低代码平台，不都是企业级软件内置的吗

[southcat996]

@a0210077 我觉得那不如直接给产品装 claudecode 了，直接说话把代码写出来

[gwkoooo]

@a2to 说到点子上了,用了他的这套东西,人家的位子稳了

[southcat996]

@a2to 老板觉得很好啊 下面的开发苦不堪言

[southcat996]

@gwkoooo 人家三年前就持股了，之前去别的地方帮忙配捷搭，回来说这不好那不好，然后突然就自己折腾了一个低代码

[Newb1e]

@southcat996 赶紧物色下家，老登不知悔改，一意孤行。

[Newb1e]

@gibber 为什么不能呢？不如提取一套公共服务能力，然后加上定制化组件。反正我觉得对于个人发展来说，用低代码平台开发就是限制自己。

[a0210077]

@southcat996 #132 这不是上面坚持搞低代码平台嘛，老板也觉得好，只能开个口子方便大家用咯

[specialweiyu]

我穿越了吗🙃

[southcat996]

@a0210077 哎 真的很难用这个

[southcat996]

@Newb1e 比较佛系吧，在这其实干的还行，手里的项目没个一两年完结不了还不太想走

[gibber]

@Newb1e 不能什么？你回复的哪一层

[onceyoung]

前几年我就在搞低代码，AI 出来之后，我自己的判断就是：低代码已死

[binhsu]

技术角度，已经死了
职场底层牛马角度：如果你们已经实现了这套东西，还能苟活一段时间，毕竟还要有人擦屁股。还在立项阶段的话，趁早跑路吧。这种项目最大受益人是项目发起人或控制人，跟着能喝汤，但对未来发展没有任何好处。

所以做的不是技术、产品，是职场、饭碗。

[tudou527]

低代码是为了节省成本，AI 起来后直接把成本打到了地板上

[southcat996]

@binhsu 我也是这个看法，我对现在公司发展也挺悲观的，干完手里的项目就准备开始找了