低代码时代真的过去了吗？很多人其实只看到了表面

前几天看到一个评论，大意是：

低代码时代已经过去了。

这个判断现在很容易获得认同。因为 AI 写代码、AI 生成页面、AI 自动搭应用的演示越来越多，很多人看完以后会自然产生一个疑问：既然 AI 都能把页面和代码生成出来了，低代码这种拖拽式平台还有多少存在价值？

这个问题不能简单回答。

如果讨论的是一些轻量表单工具，或者只能做请假、报销、登记、信息收集的流程工具，那么它们的确会受到很大冲击。AI、在线表格、自动化工具、标准 SaaS 都在往前走，过去靠“快速做一个页面”就能打动客户的阶段，已经没有那么容易了。

但如果讨论的是企业级应用平台，结论就不能这么下。

因为企业系统真正难的地方，从来不只是把页面做出来。页面只是用户每天看见的入口，页面后面还有业务对象、字段规则、组织权限、流程责任、系统接口、数据一致性、日志追溯和后续迭代。

这些东西才是企业软件的骨架。

所以这篇文章，我们先把立场放一边，不替任何概念说话，也不替任何产品站台。就从企业系统本身出发，看一看低代码到底哪些部分正在失去价值，哪些部分反而会被重新需要。

一、先分清楚，大家说的可能不是同一种低代码

低代码这个词，过去几年被混用了。

有些产品主要是表单和审批，能让业务人员快速建一个信息登记表，拉一条简单流程。

有些产品更接近在线表格，强调协作、视图、统计和自动提醒。

有些产品是流程平台，重点放在审批流、节点、条件分支、组织权限和消息通知。

还有一类产品，已经往企业应用平台发展，除了表单和流程，还要处理数据模型、复杂权限、报表、接口、主数据、应用发布、日志审计和运维管理。

这些东西都被叫做低代码，讨论时就很容易错位。

一个人说低代码没用，脑子里可能想的是“拖几个字段，生成一个增删改查页面”。另一个人说低代码有价值，脑子里想的是“用平台承接跨部门、跨系统、持续变化的企业应用”。两个人用的是同一个词，谈的却不是同一层能力。

所以判断低代码有没有未来，第一步先别急着下结论，先问清楚：你说的是哪一种低代码？

如果只是简单表单型低代码，价值确实在变薄。

过去一个部门想做客户登记、物品领用、会议室申请，用低代码搭出来很快。现在很多工具都能做到，AI 也能生成一个差不多的页面。这一类能力会越来越基础，甚至会变成很多办公软件、协同软件里的默认功能。

但企业应用平台型低代码面对的问题不一样。

它要处理的是一组业务对象之间的关系，而不只是一张表单。比如客户、合同、订单、发票、回款、项目、设备、物料、供应商，这些对象之间有前后关系，有权限边界，有数据口径，也有跨系统同步。

这种场景里，低代码的价值不在“少写几行代码”，而在于把企业应用里反复出现的基础能力沉淀成平台。

这两个层次如果不分清，后面的讨论就会跑偏。

二、AI能生成页面，但企业系统难在页面之后

现在很多 AI 应用演示都很漂亮。

你输入一句话：帮我做一个客户管理系统。很快，列表页出来了，详情页出来了，按钮出来了，图表也出来了。对于原型设计、个人工具、简单后台来说，这种能力非常有用。

但企业系统进入真实业务以后，问题马上变多。

比如一个客户管理系统，页面上看就是客户名称、联系人、电话、行业、跟进记录。真正上线时，企业会继续问：

• 客户从哪里创建，是市场线索转入，还是销售手工新增？

• 客户重复了怎么识别，合并后历史跟进记录归谁？

• 销售离职以后，客户、商机、合同和回款记录怎么交接？

• 不同区域、不同部门、不同岗位能看到哪些客户？

• 客户被列入黑名单以后，报价、合同、发货要不要限制？

• 客户资料修改以后，要不要同步到 ERP、财务系统或客服系统？

• 这些修改以后谁审批，谁操作，能不能查到记录？

这些问题都不是页面生成工具能一次解决的。

页面可以很快，但数据关系不清楚，系统就会乱。

字段可以生成，但字段含义不统一，报表就会错。

流程可以画出来，但责任边界不明确，审批就会变成形式。

接口可以调用，但没有权限和日志，后面出了问题就追不回来。

这也是企业系统和演示系统最大的区别。演示系统追求“看起来能用”，企业系统追求“长期运行还能不出事”。

一个页面今天生成出来并不难。难的是三个月以后业务规则变了，系统还能改；半年以后组织调整了，权限还能跟着变；一年以后要接 ERP、MES、CRM、财务系统，数据还能对得上；出了一次错误操作，还能查清楚是谁在什么时候改了哪一个字段。

所以，用 AI 生成页面来判断低代码失去价值，这个判断本身就有点粗。

AI 会改变低代码的使用方式，但它没有消灭企业系统里的数据、流程、权限和集成问题。

三、企业真正缺的，是标准系统之外的补位能力

很多企业已经有 ERP、MES、CRM、OA、WMS、SRM。

按理说，这些系统加起来已经很多了，为什么还会需要低代码？

原因很简单：标准系统有主干能力，但企业现场有大量边缘变化。

ERP 更擅长处理采购、库存、生产、财务这些稳定主流程。MES 更擅长处理车间执行、工序报工、质量记录、设备状态。CRM 管客户和销售过程。OA 管通用审批和协同。WMS 管仓储，SRM 管供应商协同。

这些系统各有位置，也各有边界。

企业真正麻烦的，往往是几个系统之间的缝隙。

举个制造企业很常见的场景：质量异常闭环。

车间发现某批物料上线后不稳定，MES 里有工单、工序、报工和检验记录；ERP 里有采购订单、供应商、库存批次和成本信息；OA 里可能有异常审批；供应商协同系统里又有整改通知。管理层真正想要的，是一个从发现、确认、隔离、分析、整改、复检、放行到追责的闭环，一张单独的异常表远远不够。

这个闭环里至少要处理这些内容：

• 异常来源：来自来料检验、过程检验、客户投诉，还是售后反馈。

• 关联对象：关联哪一个物料、批次、供应商、工单、订单和客户。

• 责任判断：是供应商问题、工艺问题、设备问题，还是操作问题。

• 处理流程：是否需要隔离库存、暂停发货、通知采购、通知质量和生产。

• 整改记录：责任人、整改措施、完成时间、复检结果和复发情况。

• 系统同步：哪些结果要回写 MES，哪些信息要同步 ERP 或供应商档案。

• 追溯审计：谁修改过结论，谁批准了放行，后续有没有再次发生。

这类应用用标准系统做，往往会卡在边界上。ERP 不一定愿意承接完整的质量整改流程，MES 不一定适合承接供应商准入和财务影响，OA 又缺少业务对象和批次追溯。最后企业很容易退回到 Excel、微信群、临时表单和人工汇总。

低代码如果只是一个表单工具，也解决不了这个问题。

但如果它具备数据模型、流程引擎、权限控制、接口集成和日志审计，就可以在标准系统之间补上这一段业务闭环。

这才是企业级低代码更实际的位置。

它不是把 ERP、MES、CRM 推翻重做，也不是让业务部门随便搭一堆孤立小工具。它更像一个应用补位层，用来承接那些标准系统覆盖不到、变化又比较快、还必须和主系统发生关系的业务。

四、低代码是不是符合软件工程，要看平台能力

有人会问：低代码这么搭应用，真的符合软件工程吗？

这个问题问得很有必要。

但判断软件工程质量，不能只看是不是手写代码。手写代码如果没有设计、测试、版本、权限、日志和运维，同样会做成一团乱。低代码如果只有拖拽、配置和临时上线，也同样会把企业带进新的混乱。

真正要看的，是平台有没有把企业应用里的工程要素管起来。

至少要看几个方面。

1、数据模型

一个应用不是一堆字段堆起来的。客户、订单、合同、项目、设备、物料、供应商之间是什么关系，哪些字段是主数据，哪些字段来自交易过程，哪些字段可以修改，哪些字段需要审批，这些都要讲清楚。

如果平台只关心表单长什么样，不关心业务对象之间的关系，后面一定会越来越乱。

2、权限体系

企业权限不是简单的管理员和普通用户。

它可能涉及组织、角色、岗位、区域、部门、项目、客户归属、字段可见性、数据范围和操作动作。比如销售能不能看其他销售的客户，采购能不能改供应商银行账户，项目经理能不能查看成本明细，这些都要有明确控制。

权限做不细，低代码应用越多，风险越大。

3、流程和责任

流程不是画几个节点就结束。

退回到哪一步，谁能加签，谁能转交，超时怎么提醒，条件分支怎么判断，审批意见是否进入日志，流程结束后数据状态怎么变，这些都是工程问题。

企业应用里，流程既是效率问题，也是责任问题。

4、接口和集成

低代码应用如果长期孤立运行，最后还是新的信息孤岛。

真正有价值的平台，要能连接 ERP、MES、CRM、OA、财务、人事和数据平台。接口要有鉴权、重试、异常记录、字段映射和同步状态。同步失败以后，系统要能提示谁处理，而不是让业务人员自己猜。

5、版本和发布

业务人员今天想加字段，明天想改流程，后天想调整权限。平台不能让所有修改都直接影响线上。

比较稳妥的方式，是有测试环境、发布记录、版本说明、影响范围和回滚机制。尤其是涉及审批、财务、库存、客户、合同这些数据时，不能随手改。

6、日志和审计

企业系统一定要能回答：谁改了什么，什么时候改的，改前是什么，改后是什么，为什么改。

这个能力平时看起来不显眼，出问题时非常关键。比如客户回款账号被改了，供应商资质被放行了，合同金额被调整了，库存状态被手工改了，如果查不到记录，系统就不可信。

从这些标准看，低代码本身不天然代表工程水平差。

真正危险的是把低代码当成随手搭工具，把平台治理、数据规范、权限设计和运维机制都省掉。

企业级低代码的门槛，恰恰在这里。

五、低代码真正有价值的地方，是让变化有秩序

很多宣传会把低代码讲成“快”。

快速开发，快速上线，快速响应业务。

快当然重要，但只讲快是不够的。企业系统如果只追求快，很容易把混乱快速放大。

低代码真正有价值的地方，是让变化变得有秩序。

企业每天都在变。组织调整、流程调整、价格政策调整、审批权限调整、供应商规则调整、客户分级调整、项目状态调整，这些变化不会因为上了 ERP 或 CRM 就消失。

标准系统负责主干稳定，低代码平台负责承接变化。

这件事听起来普通，落地时很关键。

比如采购付款账号变更。看起来只是供应商档案里的一个字段变化，实际可能涉及采购、财务、风控和审计。

如果用 Excel 管，风险很大。谁发来的变更申请，证照是否核验，财务是否复核，原账号是否停用，历史付款是否受影响，后续付款是否自动使用新账号，这些都很难追。

如果直接改 ERP，很多企业又会觉得流程太重，定制成本太高，调整周期太长。

比较合理的方式，是用低代码搭一个供应商关键信息变更流程：业务提交申请，系统自动拉取供应商基础资料，要求上传证明材料，采购初审，财务复核，必要时风控确认，审批通过后再同步到 ERP 或财务系统，并保留完整操作日志。

这个应用不复杂，但很有用。

它解决的是一次高风险数据变更如何做到有流程、有权限、有记录、有同步、有追溯，页面只是承载这些规则的入口。

很多企业真正需要的，就是这一类能力。

六、AI时代，低代码会换一种形态存在

AI 对低代码一定会有影响。

以前搭应用，业务人员要写需求，实施顾问要建表，开发人员要写接口，管理员要配置权限。以后很多动作会变成自然语言交互。

比如：

• 给供应商准入流程增加一个财务复核节点。

• 合同金额超过 50 万时，自动追加总监审批。

• 设备巡检表增加异常等级，并按等级通知维修负责人。

• 把客户回款情况做成一张区域经营看板。

• 当质量异常重复发生三次时，自动生成供应商复盘任务。

这些动作，AI 会让搭建和调整效率更高。

但企业不会因为 AI 很快，就放弃基本管理。AI 生成了一个字段，字段含义谁确认？AI 改了一条流程，会不会绕过原来的审批责任？AI 新增一个接口，会不会越权读取客户数据？AI 修改报表口径，会不会影响经营分析？

越是让 AI 进入企业系统，越需要一个稳定的业务结构层。

这个结构层要管理对象、字段、关系、流程、权限、接口、日志和版本。低代码平台如果能承接这些能力，它就不只是拖拽工具，而会成为 AI 应用进入企业现场的一层底座。

所以低代码在 AI 时代不会保持原样。

它会从“人拖拽搭应用”，逐步变成“AI 辅助搭建，人负责确认和治理，平台负责运行和管控”。

这一点很重要。

未来被淘汰的，可能是只会做简单表单的低代码。真正被留下来的，会是能承接企业应用结构的平台。

七、企业应该怎么判断低代码还值不值得用

对于企业来说，争论低代码有没有过时，意义没有那么大。

更实际的做法，是拿自己的业务场景去判断。

可以问几个问题。

• 这个平台能不能描述清楚业务对象，而不是只做表单字段？

• 能不能支持组织、角色、字段、数据范围和操作动作的细粒度权限？

• 能不能连接 ERP、MES、CRM、OA、WMS、SRM、财务和人事系统？

• 能不能处理审批、退回、变更、复核、归档和异常闭环？

• 能不能记录数据变更、流程流转、接口调用和人工操作日志？

• 应用修改以后，有没有测试、发布、版本和回滚机制？

• 后续业务调整时，是靠平台配置迭代，还是每次都变成新的定制项目？

如果这些问题大部分答不上来，那它可能只是一个部门工具。

部门工具不是没有价值，但不要拿它承担企业级应用平台的责任。

如果这些问题能答得比较清楚，并且能在真实业务里跑起来，低代码就还有很明确的位置。

企业软件不是谁替代谁这么简单。

ERP、MES、CRM、OA 解决的是相对稳定的主干问题。AI 解决的是生成、理解、辅助决策和交互效率问题。低代码如果做得足够扎实，解决的是企业变化过程中的应用交付和业务补位问题。

各自有边界，也各自有位置。

结语：低代码没有结束，只是混日子的低代码没那么好过了

所以，低代码时代真的过去了吗？

我的判断是：简单低代码的红利在变小，企业级低代码的门槛在变高。

过去，拖表单、画流程、生成页面，就能让很多企业觉得新鲜。现在不行了。AI 能生成页面，SaaS 越做越细，在线表格和自动化工具也越来越强。低代码如果还停留在“快搭一个页面”这一层，确实很难继续讲出价值。

但企业真正需要的，不是又多一个页面工具。

企业需要的是一套能把业务对象、数据关系、权限边界、流程规则、系统接口、日志审计和持续迭代管起来的平台能力。

从这个角度看，低代码没有结束。

它只是从“快速开发工具”，往企业应用平台、业务系统补位层和 AI 时代的应用承载层继续走。

对企业来说，别急着问低代码是不是过时。

更应该问的是：你眼前这个低代码平台，到底只能帮部门做几张表，还是能支撑企业业务系统长期运行？

这个问题问清楚了，答案自然就出来了。