业务人员真的能自己搭系统吗？低代码项目里最大的误解

让业务人员自己搭系统——这句话你可能在各类低代码厂商的官网、PPT、销售嘴里都听过。

• 业务部门不用再等IT排期
• 不用再写需求文档
• 不用再忍受漫长的开发周期
• 想用什么系统自己拖一拖就有了

但如果你真的在企业里跟过几个低代码项目，慢慢会发现一件很尴尬的事。

那些业务人员自己搭出来的东西，十个里有八个最后要么被推倒重来，要么被IT部门接管后大改，要么干脆被弃用，变成企业数字资产里一堆没人敢删、也没人敢用的“垃圾”。

那问题出在哪？

明明工具已经很简单了，为什么业务人员还是搭不出来呢？

最终的答案可能比你想的简单，也比你想的深。

低代码去掉的是语法，不是复杂度

很多人对低代码有一个根本性的误解。他们以为写代码很难，是因为要记语法、要敲键盘、要处理各种报错。所以只要把这些东西变成拖拽，变成可视化，难度就消失了。

这个逻辑，怎么说呢，基本上是从没写过代码的人对编程的想象。

写代码的难度很多时候根本不在语法上。语法往往是程序员工作中最微不足道的一部分。一个工作了三年的程序员，写代码的时候根本不会想语法，就像你说话的时候不会想主谓宾。真正难的东西，是数据建模、是状态管理、是边界条件、是系统集成、是异常处理、是性能瓶颈、是安全策略。这些东西，跟你用什么工具写代码，关系真的不大。

低代码平台做的事情，说白了就是把代码换成了可视化配置。但系统设计的复杂度，往往原封不动地保留在配置项里。你只是不用敲键盘了，但你仍然需要理解数据模型是什么意思，需要知道什么时候该建索引，需要搞清楚行权限和角色权限的区别，需要明白消息队列和定时任务各自适用什么场景。这些东西，一个做了五年采购的经理，大概率一个都不懂。不是他笨，是他的知识结构里压根没有这一层。

低代码平台实际上做了一件事：它把编程的门槛从语法层降到了概念层。但概念层的门槛，对非技术人员来说，依然是一堵墙。很多时候，这堵墙甚至比语法墙更难翻。语法好歹是看得见摸得着的，错了有报错提示。概念层的判断，错了往往要到系统上线很久以后才会暴露，而且暴露的时候你甚至不知道问题出在哪一次配置选择上。

搭表单和搭系统是两件事

低代码行业有一个特别鸡贼的话术，就是把搭表单和搭系统混在一起讲。

你去看任何一个低代码平台的宣传视频，一定有一个经典场景。一个业务人员，拖几个字段，配一个流程，点一下发布，一个小应用就跑起来了。台下观众鼓掌，觉得这玩意儿太神了。但这个东西叫表单，不叫系统。很多时候，厂商就是靠这种视觉上的冲击力，让你产生一种错觉，觉得搭系统也就这么简单。

一个真正的企业级系统，哪怕是内部用的，也远远不只是几个表单加一个审批流。它至少包含这些东西：多张数据表之间的关联关系，不同角色的权限体系，复杂条件下的业务逻辑分支，和外部系统的数据同步，历史数据的版本管理，异常情况的回滚机制，性能瓶颈的预案。

这些东西，没有一个靠拖拽能解决。

你拖一个客户信息表出来很容易。但客户信息要不要和订单表关联？是一对多还是多对多？关联以后删除一条客户记录，关联的订单怎么处理？级联删除还是软删除？谁来删？删了以后能不能恢复？恢复以后关联的订单数据还在不在？

这些问题，业务人员往往在拖拽的时候根本不会想到。但他搭出来的系统，总会在某一天因为这些问题崩掉。不是如果，是总有一天。

如果你之前去看过一些专业低代码平台的产品文档，你会发现一个很有意思的细节。很多平台在配置项里给的东西，远远超出了一个业务人员的认知范围。譬如在织信低代码的产品文档中，它的应用设计器下面有数据表、字段、行权限、索引、表分区、模型定义。有BPMN工作流、搜索引擎、消息队列、定时任务、监听器、环境变量、API接口、脚本引擎。有视图设计、仪表盘配置、组件设计器、自动化规则、表达式编写。

这些东西，你让一个业务人员去理解，他可能连目录都看不完。

而且织信在产品文档里还专门有一段话，讲的是AI开发团队的建议。对于简单应用场景，比如任务管理一类不涉及复杂逻辑的，可以由产品经理来担任设计。但对于复杂的大型应用，比如ERP、MES之类的，他们建议团队由产品经理、开发人员、测试人员组成。产品经理负责需求梳理、模型设计、页面设计、交互设计、权限设计。开发人员负责自动化搭建、脚本编写、表达式编写。测试人员负责功能测试。

注意，这说的是产品经理，不是业务人员。产品经理和业务人员之间，隔着一整套系统设计的方法论。产品经理至少懂数据建模、懂交互逻辑、懂权限设计，这些是他们的基本功。业务人员懂什么？懂自己的业务。但懂业务和懂系统设计，往往是两套根本不重叠的知识体系。

织信说得很客气，但翻译成大白话就是：不要让完全不懂系统设计的人来碰系统设计。这不是工具的问题，是人的问题。

业务人员搭的系统长什么样

如果你没见过业务人员自己搭的低代码系统，我给你描述一下。不用具体案例，就说共性。

它们通常有一个共同特征：能用，但一碰就碎。

界面看起来还行，表单、列表、审批流都有了。但只要稍微偏离主流程，立刻出问题。审批人不在，系统就卡死，因为没有超时转交机制。数据量超过一万条，列表页加载越来越慢，因为没有人建过索引。跨部门的人要看数据，权限直接全开，因为没有做行级权限。要改一个字段类型，系统直接报错，因为关联表没有同步更新。

这些问题，很多时候不是低代码平台的问题。是搭系统的人根本不知道这些问题是问题。

程序员写代码的时候，脑子里始终有一根弦：异常情况。输入为空怎么办？网络超时怎么办？并发冲突怎么办？数据不一致怎么办？这根弦是多年的专业训练形成的肌肉记忆，不是几个小时的平台培训能培养出来的。很多时候，一个程序员和一个业务人员面对同一个系统需求，他们的思考路径是完全不同的。业务人员想的是，正常流程怎么走。程序员想的是，出了异常怎么兜。

业务人员用低代码平台搭系统，本质上是在用一个不需要驾照的车。车确实能开，但遇到复杂路况，往往不知道什么时候该刹车、什么时候该变道、什么时候该看后视镜。撞了以后甚至不知道是自己操作的问题，还是车的问题。

系统设计的隐性知识

这里有一个特别值得展开的点：系统设计到底需要什么能力。

很多人以为，系统设计就是把需求翻译成功能。这个理解太浅了。真正的系统设计，说白了，是在一堆互相矛盾的需求之间做取舍和平衡。

就拿一个采购审批系统来说。财务部门希望审批流程越严格越好，采购部门希望越快越好。怎么设计？你可以做一个多级审批流程，但审批节点多了，效率就低。你可以加一个金额阈值，小额自动过、大额走审批，但阈值设多少？不同品类要不要设不同的阈值？如果同一个人既是申请人又是审批人，要不要自动跳过？如果审批人离职了，他的待办怎么处理？

这些决策，往往没有标准答案。每一个都取决于你对业务的理解深度、对系统边界的把握、对异常场景的预判。这是一种综合判断能力，不是掌握某个工具的操作就能获得的。

程序员在写代码的时候，天天都在做这种决策。只是他们不叫决策，叫设计。业务人员在自己的领域里也天天做决策，但那是业务决策，不是系统设计决策。两种决策的思维方式完全不同。业务决策追求的是结果最优。系统设计决策追求的是逻辑完备。业务人员会想，这个流程怎么走效率最高。但往往不会想，如果流程里某个环节出错了，数据怎么回滚。这不是他的思维习惯。

所以你会发现一个很有意思的悖论：低代码平台越强大，功能越丰富，业务人员反而越没法用。因为功能多了，意味着需要做的设计决策也多了。一个只有十个配置项的平台，业务人员还能摸清楚。一个有上百个配置项的平台，每一层配置背后都是一个需要专业判断的设计决策，业务人员往往不知道该怎么选，最后要么随便选一个默认值，要么干脆空着。这两种做法，都会在系统上线后的某个时刻以故障的形式找回来。

公民开发不是公民搭系统

这里有必要区分两个概念：公民开发和公民搭系统。这往往是低代码行业最大的话术陷阱。

公民开发，英文叫 citizen development，指的是非技术人员在IT部门的治理框架下，使用低代码工具完成一些简单的、标准化的、边界清晰的开发任务。比如某个部门的数据收集表单，某个团队的内部任务看板，某个简单审批流的快速搭建。这些东西的特点是：逻辑简单、边界固定、不会影响核心业务、出问题了也不会造成严重后果。

公民搭系统，是另一个概念。指的是让非技术人员去搭建承载核心业务、涉及多部门协作、有复杂逻辑和大量数据的系统。比如ERP、MES、CRM、OA。这些东西的特点是：逻辑复杂、边界模糊、牵一发而动全身、出问题了直接影响业务运转。

低代码厂商在宣传时，往往拿着公民开发的案例，去暗示公民搭系统的可能性。这中间的逻辑跳跃，很多时候骗过了大量不懂技术的企业决策者。

Gartner的数据也经常被断章取义。那句被引用了几万次的预测，说到2026年80%的技术产品将由非专业开发者构建，很多人不知道的是，Gartner在同期报告里还说了另一句话：治理能力不足的公民开发正在催生大量的安全漏洞和数据风险。同一家机构，同一份报告，两句话被不同的人拿着用。厂商取前半句，CIO该看后半句。

数据建模是真正的分水岭

如果你问我，业务人员和IT人员用低代码搭系统的本质区别在哪里，我会说数据建模。

数据建模是系统设计的根基。表结构怎么设计，哪些字段放一张表，哪些拆出去，关联关系用什么类型，索引建在哪些字段上，分区策略怎么定——这些决策直接影响系统能不能跑起来、跑得快不快、以后好不好改。

业务人员怎么看数据？他们看的是Excel表格。一行一行的数据，按列排列，筛选、排序、汇总。这种思维模式，往往会让他们天然地把数据当成一张大宽表。所有信息放在一起，用得方便。

但数据库不是这么设计的。数据库要遵循范式，要减少冗余，要考虑查询效率，要预留扩展空间。一个订单系统，专业的做法是拆成订单主表、订单明细表、客户表、产品表、库存表，通过外键关联。业务人员大概率会把所有字段塞进一张表里，因为这样看着最直观，做报表也方便。

这套系统刚上线的时候，数据量小，运行得挺顺畅。三个月后，订单量上来，查询越来越慢。半年后，要加一个新字段，发现会影响整个表的索引结构。一年后，业务调整，要改订单状态的定义，发现所有报表都写死了原来的状态值，改一个等于全改。

这就是数据建模能力缺失的后果。它不会在第一天就暴露出来，但会在系统运行一段时间后，像一个定时炸弹一样引爆。到时候，往往已经错过了重构的最佳时机，只能打补丁，越打越乱。

程序员是不是天生就懂数据建模？不是。但程序员的专业训练里，数据库原理、范式设计、查询优化是必修课。哪怕他毕业后没做过数据库设计，这些概念也在他的认知框架里。遇到问题的时候，他知道要去查索引、看执行计划、优化查询。业务人员遇到同样的问题，大概率只会觉得系统慢了，不知道为什么慢，也不知道该怎么查。很多时候，他甚至不知道可以查。

权限设计的黑洞

另一个业务人员几乎不可能做对的事情，是权限设计。

一个稍微复杂一点的企业系统，权限往往至少分三层：功能权限，谁能用什么功能。数据权限，谁能看什么数据。字段权限，谁能看哪些字段。这三层再叠加角色、部门、职位、项目组，形成一个立体的权限矩阵。

业务人员是怎么设计权限的？通常就两种做法。要么全开，因为觉得麻烦，反正都是内部人用。要么全关，每个功能都要申请，结果搞得没人用。这两种做法，一种造成安全隐患，一种造成系统废置。中庸之道在哪，往往需要系统性的判断，不是靠直觉就能找准的。

真正合理的权限设计，是在安全和便利之间找一个平衡点。这个平衡点怎么找？需要对组织架构、业务流程、数据敏感度有系统性的理解。这恰恰是产品经理和系统架构师的专业领域，不是业务人员的直觉能做到的。

织信的产品文档里，在应用设计器下面专门列了行权限、角色权限、登录设置、应用授权这些模块。说明它把这些东西当成了系统设计的一等公民，而不是一个锦上添花的附加功能。但这些东西，对业务人员来说，往往就是一堆看不懂的配置项。他们大概率会跳过，或者随便填一下。等系统上线了，权限问题开始暴露，再回头改，成本已经很高了。

维护才是真正的噩梦

就算业务人员真的搭出了一个能用的系统，故事到这里也远没有结束。

系统是要维护的。业务会变，流程会改，人员会流动。今天搭好的系统，三个月后可能就需要调整。谁来调？如果是业务人员搭的，大概率还是得他自己调。但他可能已经忘了当时的配置逻辑，可能换了岗位，可能离开了公司。

这就是低代码项目里最被低估的问题：系统的可维护性。

程序员写的代码，至少有注释，至少有版本管理，至少团队里其他人能接手。业务人员用低代码平台搭的系统，配置是黑盒，逻辑是隐式的，文档是不存在的。除了他自己，没人知道这个系统是怎么运作的。一旦他离开，这个系统就变成了企业里的一个幽灵应用——还在运行，但没人敢碰，没人会改，出了事只能关掉。很多时候，关掉都不敢关，因为不确定哪些业务还在依赖它。

Gartner在2026年的调研里提到，78%的IT部门已经开始建立正式的公民开发治理策略，2024年这个数字还是42%。为什么涨得这么快？因为吃过亏的企业太多了。大量业务部门自己搭的应用，在运行一段时间后变成了IT部门的负债。IT部门接手的不是系统，是烂摊子。

织信的坦诚和行业的虚伪

回到织信。我觉得它的产品文档里那句建议，其实是整个低代码行业最该被看到的一句话。

一个低代码厂商，在官方文档里告诉你，用我们的产品，你还是需要开发人员。这不是在削弱自己的产品价值，是在说真话。低代码的价值很多时候从来不是让技术人员失业，是让技术人员的人效翻倍。一个开发人员加上低代码平台，能干以前三个人的活。但一个业务人员加上低代码平台，往往还是干不了开发人员的活。

织信的产品架构也印证了这一点。它的设计器里，模型设计、脚本编写、自动化配置、API对接，这些模块的受众明显是技术人员。一个不懂代码的业务人员，看到脚本编辑器会直接傻眼。看到环境变量配置会完全不知道在干什么。看到消息队列的参数设置，可能连这个功能是干嘛的都不清楚。

但织信把这些功能都做出来了。为什么？因为它的目标客户从来不是那些想自己搭系统的业务人员，而是那些想用更高效的方式搭系统的技术人员。它降低的是技术人员的开发成本，不是系统设计的认知门槛。

说到底，这才是低代码的真相。它不是一个让所有人都能写代码的万能工具，它是一个让会写代码的人写得更快的工具。就像Excel没有让所有人都变成财务分析师，Photoshop没有让所有人都变成设计师。低代码也不会让所有人都变成系统架构师。很多时候，工具的进步反而会拉大专业和非专业之间的差距，因为专业的人用同样的工具，效率提升的幅度远远大于非专业的人。

最后

业务人员能不能自己搭系统？能搭，但搭出来的大概率是一个能用但不稳定的东西。这个系统会在某个边界条件触发时崩溃，会在数据量增长后变慢，会在人员变动后变成无人维护的僵尸应用，会在安全审计时暴露出大量合规问题。

低代码平台解决的从来不是系统设计的难度，而是代码实现的效率。它让一个懂系统设计的人不再需要吭哧吭哧从零写代码，但从来没有让一个不懂系统设计的人突然就懂了。

那些告诉你业务人员可以自己搭系统的低代码厂商，要么是在迎合你的幻想，要么是对自己的产品没有清醒的认识。织信至少在这一点上说了实话：你需要一个懂系统设计的人来主导这件事。这个人可以是产品经理，可以是开发人员，但一定不能是一个对数据建模、权限设计、系统架构一无所知的业务人员。

这不是工具的局限。往往是系统设计这件事本身，它就不相信捷径。