2026 谈低代码产品

如果你的老板正在逼你使用“低代码产品”。或者，
他打算让你开发一个低代码产品。
但你又很反感，那可以将这篇文章发给你的老板，说不定可以改变他的想法。

1. 什么是低代码产品

每个人心里所想的低代码产品，其实从未统一过。

在前端眼里，低代码产品就是一个通过拖拉拽做前端的工具，
但多数商用的前端页不会是纯静态，至少需要从后端服务器拉取一些数据并填充进来。

好在多数低代码产品都支持简单的调用接口和填充数据。

但如果想加一些复杂的交互逻辑呢？
比如两个下拉框需要数据联动，比如有些选项只有会员才能看到。
这些逻辑光靠图形是很难表达清楚的，只能用文字描述，也就是代码。

有些低代码产品经理，和很多做领导的，思路非常简单，他也承认做交互很难，但没有关系，
先做一个简单的版本先发布，其他复杂功能“下个”版本再加。
但这种“下个版本再加”和别的“下个版本再加”是有本质区别的。

因为做交互是不可或缺的核心功能，没有它，整个低代码产品等于废物。就像做抖音，先做团购功能，刷视频的功能“下个版本再加”。
就像做微信，先做钱包支持功能，聊天的功能“下个版本再加”。

很多低代码开发团队从上到下都带着“复杂功能以后再说”的心态，
直到最后团队解散时，依然留了大量未完成的需求。

低代码产品上线后，领导一定会开始分配项目，但会发现和预期差异较大。

有坚持力的老板和产品经理，就开始想到了一个妙计：
既然这个项目的很多交互功能做不了，那就现加，
缺啥补啥，只要项目经验丰富了，低代码产品就无敌了。

于是，所有人都进入一个状态：
一边改造低代码产品、一边做项目。

最终前端开始发疯了。
本来直接完成项目就好，一天的工作量，现在要先改造低代码产品，花个 2 天，然后再用这个产品做项目，花个半天。而且，代码比直接用 React/Vue 要难改多了，不能随意使用 npm 上的包，不能使用一用就爱上的 vite 热刷新，甚至调试都要用最低级的 console.log 。

所以，大部分前端都觉得低代码是“傻逼领导”才会做的事情。

当然，所有领导眼里都和明镜似的，他知道，一个取代前端的产品，无论做的再好，前端都会来挑刺的，
因此前端骂再多，他都当听不到。

2.低代码产品应该是怎样的

多数仍然坚持做低代码的领导眼里，他其实也明白低代码是做不成通用的。

他会将低代码产品的用途缩小到一个特定的场景：比如就是做权限管理工具、就是做流程管理功能。

这是可行的，其实有很多面向运营、财务、人力的工具，都可以做成低代码产品，但这有个前提：
你必须改变你的认知，低代码不一定是一个拖拉拽画界面的工具，而是一个针对特定人群（非程序员）解决重复劳动的工具，
它可能有拖拉拽，也可能没有，具体看需求。

结论：如果你和领导在“2026 开发低代码产品还有没有意义的观点上有矛盾”，大概率是因为你们心理所想的低代码产品压根不是一个东西。

不要再说有 AI 了，谁还用低代码。
要说写代码，用 AI 可能比低代码好，但低代码产品本身就不是用来写代码的。

假如行政部负责人经常需要写一些格式规范的公司红头文件，
希望你做个工具，可以自动生成抬头、时间等信息。你对他的回复是“你用 AI 写”吗？

3. 低代码产品能不能做到通用

我认为能，但这个事情不是一个只会调接口、填数据的前端能做到的。
就像能自己制作电饭煲的厨师，一定是极少数。

所以，站在领导的角度，当一个前端极大的向你否定低代码产品的意义时，大概率是他真的做不了，你需要换人，或放弃这个想法。
否则，坚持开发低代码产品就是浪费公司的资源。

4. 我认为正确的低代码产品架构

一个项目是由前端和后端组成的，从商业角度：要不这个产品收一次钱能完全搞定全部，要不就不收费，
就像你开饭店就得向顾客提供筷子、纸巾，而不是让客户自己想办法。

如果一个低代码产品只能做特定功能的活，那它在商业上基本废了，除非这个产品是公司内部给其他部门的人员使用的。

因此，做低代码产品，必须从后端底层入手——必须要做到能直接生成可部署的后端服务，同时还要提供生态、调试、版本管理、多人协作等相关配套。
至于前端，交互部分其实和后端是一样的解法的，图形部分则靠传统的拖拉拽就可以了。