低代码平台荣耀不再：AI 浪潮下，企业系统为什么重新回到原生代码

低代码平台荣耀不再：AI 浪潮下，企业系统为什么重新回到原生代码

🌐 演示地址：http://ruoyioffice.com | 📦 源码1：https://gitcode.com/zhouzhongyan/ruoyi-office-vben.git | 📦 源码2：https://gitcode.com/zhouzhongyan/ruoyi-office.git | 📦 源码3：https://github.com/yuqing2026/ruoyi-office.git | 💬 微信：17156169080（备注「RuoYi Office」）

低代码曾经解决了一个真实问题：企业想要更快地把表单、审批和报表上线。但 2026 年的变量已经变了。AI 编程让原生代码的初始开发成本大幅下降，而企业系统真正的成本从来不在“画出第一张表单”，而在流程、权限、数据、移动端、审计、升级和二开。低代码没有消失，但它的荣耀叙事正在退潮。

▲ 低代码解决的是第一版上线速度，AI+原生代码更擅长解决企业系统长期演进、复杂业务和源码可控的问题

引言：低代码为什么会突然显得“不香”了

很多团队对低代码的第一印象，是“拖一拖就能上线”。

这个判断在简单场景里成立：报名表、信息收集、内部台账、轻量审批、活动登记、部门报表，低代码确实能把交付周期从数周压到数天。它的历史价值不该被否定。

问题在于，企业管理系统通常不是一个表单，而是一组长期变化的业务闭环：

企业系统能力	简单阶段	复杂阶段
表单	字段录入	主子表、动态校验、节点级只读、附件和签名
流程	单线审批	会签、或签、退回、加签、撤回、业务回调
权限	谁能看菜单	数据权限、部门隔离、租户隔离、字段可见性
数据	一张业务表	多模块关联、状态机、流水账、历史版本
终端	PC 列表页	Web + APP + 小程序 + 嵌入式审批详情
运维	能访问	日志、审计、性能、升级、容灾、二开交接

低代码平台最舒服的区域，是“结构相对稳定、逻辑相对简单、责任边界相对轻”的内部应用。可一旦进入 OA、HRM、CRM、ERP、资产、合同、项目、BPM 这种企业级组合场景，问题就会集中爆发。

更关键的是，AI 改变了开发效率的参照系。

以前低代码和原生代码比，低代码的优势是“快”。现在 AI 能帮开发者生成实体、接口、前端 API、表格、表单、校验、测试、迁移脚本，原生代码的初始速度被大幅拉高。低代码剩下的优势不再绝对，而它在复杂业务里的弊端反而被放大了。

一、先说公平话：低代码不是错，错的是把它当万能药

低代码的合理使用边界很清晰。

它适合：

• 临时数据收集
• 部门级轻应用
• 简单审批流
• 报表看板
• 业务验证原型
• 对合规、审计和二开要求不高的场景

它不太适合：

• 多模块互相联动的企业级系统
• 长生命周期核心业务系统
• 有复杂权限和数据隔离要求的系统
• 需要深度移动端体验的审批系统
• 需要 AI 读懂、重构、测试和持续演进的代码库
• 未来可能要迁移、私有化、二开和源码交接的项目

低代码最常见的误区，是把“上线速度”当成“总拥有成本”。

真正的企业系统不是一次性项目，而是一种持续运营的资产。它会经历需求变更、组织调整、流程优化、制度更新、接口对接、版本升级、数据迁移和安全审计。第一版做得快，只能说明起跑快；跑到第三年还能改得动，才是系统能力。

二、AI 浪潮为什么会冲击低代码

先看几组公开数据。

Stack Overflow 2025 Developer Survey 显示，84% 的受访者正在使用或计划在开发流程中使用 AI 工具，但 46% 的开发者不信任 AI 工具输出的准确性，45% 的受访者认为调试 AI 生成代码很耗时。也就是说，AI 已经进入主流开发流程，但“可审查、可理解、可验证”仍然是核心问题。

GitHub 在 Universe 2024 发布中提到，已有超过 77,000 个组织采用 GitHub Copilot，同时 Copilot 走向多模型和 AI-native developer experience。这意味着 AI 编程工具不再只是补全插件，而是在重塑开发体验。

McKinsey 2025 State of AI 调研也给出一个冷静信号：几乎所有受访组织都在使用 AI，但接近三分之二还没有在企业范围内规模化 AI。这说明企业真正缺的不是“会不会试用 AI”，而是“有没有工程体系把 AI 产出纳入可控交付”。

这些数据放在一起，会得到一个很关键的判断：

AI 提高了代码生成速度，但也提高了对工程透明度的要求。

低代码平台的问题恰好在这里。

AI 最擅长读懂的是原生语言：Java、TypeScript、SQL、YAML、测试用例、接口定义、错误日志。它可以沿着源码、类型、调用链、提交记录去理解系统。

但很多低代码平台把业务逻辑封装在：

• 可视化配置
• 平台私有 DSL
• 表单设计器 JSON
• 节点脚本
• 规则引擎片段
• 平台运行时元数据

这些内容对人已经不够直观，对 AI 更不友好。AI 可以帮你写脚本，但很难像理解一个 Spring Boot 项目那样理解整个平台运行时。

三、低代码的 5 个深层弊端

3.1 复杂度不会消失，只会换地方藏起来

低代码把代码藏起来，并不等于复杂度消失。

以一个用印申请为例，简单版只需要：

• 申请人
• 用印类型
• 申请原因
• 审批人

真实企业里往往会继续追加：

• 不同印章对应不同审批链
• 合同类用印必须关联合同
• 外带印章需要归还节点
• 附件必须包含盖章文件
• 审批通过后要生成用印记录
• 超期未归还要提醒
• 移动端审批详情要展示业务字段

这些逻辑如果在原生代码里，会分布在实体、枚举、Service、Mapper、BPM 回调、前端表单和移动端详情中，每个位置都有清晰责任。

如果全部压进低代码平台，就会变成一堆配置、脚本和节点条件。短期看少写代码，长期看是把复杂度藏进更难审查的地方。

3.2 业务语义容易被“字段化”

低代码经常以字段为中心：字段类型、字段校验、字段显示、字段权限。

但企业系统真正重要的是业务语义：

业务对象	不是字段，而是规则
请假单	请假余额、假期类型、销假、考勤抵扣
出差单	行程明细、预算、报销联动、费用校验
资产卡片	入库来源、折旧、调拨、维修、报废
合同	客户、商机、审批、应收、回款
公文	套红、密级、收发文联动、归档

如果系统只把业务看成字段，就很容易做出“能录入，但管不住”的应用。

这也是很多低代码项目后期会变成“平台上套平台”的原因：业务一复杂，就开始补脚本、补插件、补接口、补数据库视图，最后既不像低代码，也不像原生工程。

3.3 审计和代码评审天然困难

企业系统不是个人工具，很多变更需要能回答：

• 这次改了哪些业务规则？
• 哪些权限受影响？
• 哪些接口被调整？
• 哪些流程节点被改动？
• 回滚方案是什么？
• 是否影响历史数据？

原生代码可以通过 Git diff、代码评审、单元测试、接口测试和数据库迁移脚本来追踪。

低代码平台如果没有很强的版本化、配置差异比较、导出审查和自动化测试能力，变更审计会非常吃力。

尤其是当一个流程节点里嵌了脚本，一个表单字段上挂了表达式，一个按钮权限依赖某段配置时，团队很难通过传统工程手段评审它。

3.4 平台锁定比想象中更重

低代码平台最初看起来是在节省开发成本，后期却可能把成本转移到平台绑定上。

常见绑定包括：

• 数据模型绑定
• 表单引擎绑定
• 流程引擎绑定
• 权限模型绑定
• 页面运行时绑定
• 插件市场绑定
• 部署和授权绑定

一旦企业想迁移，问题就会变成：能不能把平台配置还原成可运行、可维护、可测试的原生系统？

很多时候答案并不乐观。

3.5 AI 难以真正接管低代码项目

AI 编程不是“写几行代码”，而是理解上下文之后做跨文件变更。

例如在 RuoYi Office 里，AI 可以沿着以下路径理解一个业务：

数据库表-> Java DO / Mapper / Service / Controller-> SaveReqVO / RespVO / PageReqVO-> TypeScript API 类型-> Vue 列表 / 表单 / 详情-> UniApp 移动端页面-> BPM 流程定义与回调

这条链路越显式，AI 越能参与。

低代码平台如果把大部分逻辑存在数据库配置或运行时元数据里，AI 很难通过普通代码上下文理解完整业务。最后就会出现一个尴尬局面：平台号称低代码，AI 却只能在平台外写补丁。

四、AI+原生代码的优势，不是“写代码更快”这么简单

AI 原生代码的价值，不只是生成 CRUD。

它更像是在企业系统开发里增加了一个“高频协作者”：

阶段	AI 能做什么	人必须负责什么
需求拆解	整理字段、状态、流程、边界条件	判断业务真实性和优先级
数据建模	生成表结构、索引、枚举建议	确认数据生命周期和审计要求
后端开发	生成 Controller、Service、Mapper、VO	审查事务、权限、异常和一致性
前端开发	生成 API、表格、表单、详情页	调整交互、体验和业务语义
移动端	复用 API 生成移动列表和详情	确认审批场景和弱网体验
测试审查	补测试、找边界、解释报错	定义验收标准和风险级别

以前原生代码最大的阻力，是人力成本高、重复劳动多。

现在 AI 把重复劳动降下来了，原生代码的优势就变得更明显：

• 代码可读
• 类型可查
• 逻辑可审
• 测试可跑
• Git 可追
• 架构可演进
• 平台可迁移
• 团队可接手

这才是“AI+原生代码”真正冲击低代码的地方。

五、RuoYi Office 为什么是这个趋势的典型样本

RuoYi Office 不是把几个页面拼在一起，而是基于 RuoYi-Vue-Pro / Yudao 深度定制的一体化企业管理平台，覆盖 OA、HRM、CRM、ERP、BPM、AI、资产、合同、项目、移动端等多个模块。

它的关键不是“功能多”，而是这些功能处在同一套工程体系里。

▲ Web 工作台展示待办、已办、OA、HRM、CRM、ERP、项目、资产等入口，说明业务并不是孤立表单，而是统一流程中心驱动的企业协同

▲ 移动端工作台展示考勤打卡、公告、工资信息、企业云盘和任务管理入口，低代码很容易做出表单，但难点在 Web 与 APP 的同一套业务闭环

RuoYi Office 的工程结构很典型：

层级	技术与职责
后端	Spring Boot 3.5、Java 17、MyBatis-Plus、多租户、权限、流程回调
Web 前端	Vue3、TypeScript、Vben Admin、VxeGrid、统一 API 封装
移动端	UniApp、Vue3、wot-design-uni、移动审批和业务详情
流程	Flowable 7、BPMN 2.0、流程变量、业务单据回调
AI	Spring AI、多模型、知识库、AI 工作流、MCP 工具

这种结构对 AI 非常友好，因为所有关键语义都能在源码里找到。

一个代码片段：流程通过后自动写回业务

下面是资产入库审批的业务回调片段。它不是配置里藏着的一段脚本，而是明确实现 FlowBillService，审批通过后将入库明细生成资产卡片。

@Override
@Transactional(rollbackFor = Exception.class)
public void onProcessApproved(String businessKey) {Long id = Long.parseLong(businessKey);log.info("[onProcessApproved] 资产入库审批通过，id: {}", id);AssetReceiveDO receive = validateReceiveExists(id);Long existed = cardMapper.selectCount(new LambdaQueryWrapperX<AssetCardDO>().eq(AssetCardDO::getSourceBillType, SOURCE_BILL_TYPE).eq(AssetCardDO::getSourceBillId, id));if (existed != null && existed > 0) {return;}List<AssetReceiveItemDO> items = receiveItemMapper.selectListByReceiveId(id);if (CollUtil.isEmpty(items)) {return;}List<AssetCardDO> cards = new ArrayList<>();for (AssetReceiveItemDO item : items) {int qty = item.getQuantity() == null || item.getQuantity() < 1 ? 1 : item.getQuantity();BigDecimal lineAmount = item.getAmount() != null ? item.getAmount() : BigDecimal.ZERO;BigDecimal perOriginal = qty > 0? lineAmount.divide(BigDecimal.valueOf(qty), 2, RoundingMode.HALF_UP): lineAmount;// ...}
}

这段代码体现了企业系统的几个关键点：

• 审批不是结束，审批通过后要触发业务动作
• 业务动作要具备幂等判断，防止重复生成资产卡片
• 金额、数量、来源单据都要显式处理
• 事务边界清晰，可审查、可测试、可追踪

这类逻辑如果完全藏在低代码配置里，后期维护人员会非常痛苦。

六、低代码 vs AI 原生代码：真正要比较什么

不要只比较“做一张申请单谁快”。

企业选型应该比较 8 个维度：

维度	低代码平台	AI+原生代码平台
第一版速度	快	AI 加持后也很快
复杂流程	依赖平台能力和脚本扩展	Flowable / BPMN / Service 回调可控
数据模型	容易平台绑定	表结构、实体、接口清晰
权限体系	看平台抽象深度	RBAC、数据权限、多租户可细化
移动端	常需要适配或另建应用	API 与流程复用，移动端按场景实现
AI 协作	AI 难读懂平台配置	AI 可读源码、日志、测试和调用链
运维审计	依赖平台导出和审计能力	Git、日志、测试、SQL 迁移链路完整
迁移自由度	容易被平台锁定	源码和数据模型更可控

结论不是“低代码一定不能用”，而是：

越接近企业核心业务，越应该让关键逻辑回到可审查的原生代码里。

七、AI 时代，低代码平台可能会走向哪里

低代码不会消失，它会被重新定位。

未来低代码更适合成为：

• 原型设计器
• 内部轻应用平台
• 数据采集工具
• 简单流程自动化工具
• 企业系统里的动态表单补充能力
• 面向业务人员的可视化配置层

但它不应该替代企业核心系统的工程底座。

比较合理的架构是：

核心系统：原生代码- 业务模型- 权限体系- 流程引擎- 数据结构- API 契约- 审计与运维灵活扩展：低代码/动态表单- 非核心表单- 临时流程- 个性化字段- 报表配置- 业务人员自助配置

RuoYi Office 采用的也是这种思路：底层是清晰的 Spring Boot + Vue3 + UniApp + Flowable 工程体系，上层可以接入动态表单、AI 工作流、业务配置和多端体验。

八、给企业团队的选型建议

如果你的需求是“部门内部做一个临时登记工具”，低代码非常合适。

如果你的需求是“建设一套 OA、HRM、CRM、ERP、BPM、AI 一体化平台”，建议重点看以下问题：

问题	为什么重要
是否拿得到完整源码	决定二开、审计、迁移和长期维护能力
是否有标准后端架构	决定事务、权限、接口、日志和性能边界
是否有真实移动端	决定审批和现场业务能不能落地
是否有流程回调机制	决定审批能不能真正驱动业务
是否支持 AI 能力	决定未来知识库、写作、对话和自动化空间
是否有多模块联动	决定是不是只是一堆孤立应用

对中小企业来说，更现实的路线不是“买一个无所不能的低代码平台”，而是选择一个源码可控、模块完整、AI 友好、能二开的企业系统底座。

这也是 RuoYi Office 的定位：

用一套原生工程，把 OA、HRM、CRM、ERP、BPM、AI 和移动端放在同一个可演进体系里。

九、快速体验

本地演示地址：

端	地址	说明
Web 端	http://localhost:5800/	PC 管理后台、工作台、流程中心、业务模块
移动端	http://localhost:9000/	UniApp H5、移动审批、业务申请、个人工作台

在线资料与源码：

类型	地址
文档	http://ruoyioffice.com
前端源码	GitCode - ruoyi-office-vben
后端源码	GitCode - ruoyi-office
GitHub 镜像	GitHub - ruoyi-office

参考资料

• Stack Overflow 2025 Developer Survey：AI 工具采用率、信任度和调试成本数据，见 Stack Overflow 2025 Developer Survey Press Release 与 AI 章节。
• GitHub Universe 2024：Copilot 多模型、AI-native developer experience 与组织采用情况，见 GitHub Universe 2024 Press Release。
• McKinsey 2025 State of AI：企业 AI 规模化仍处早期阶段，见 The State of AI 2025。
• Gartner 对企业低代码平台能力的定义包含治理、AI 辅助开发、运行时、扩展性等要求，见 Gartner Peer Insights - Enterprise Low-Code Application Platforms。

结语

低代码的黄金时代并不是被谁打败了，而是被企业系统的复杂度和 AI 编程的新效率重新校准了。

未来的企业应用开发，不会回到纯手写时代，也不会停留在纯拖拽时代。更可能的方向是：AI 负责提速，原生代码负责承载，工程体系负责兜底。

RuoYi Office 想做的，就是在这个方向上给企业一个可直接落地的选择：不是一堆孤立页面，而是一套源码可控、流程可编排、移动端可用、AI 能接入的企业管理一体化平台。

💡 想要体验 RuoYi Office 的完整能力？

🌐 在线文档：http://ruoyioffice.com

📦 源码仓库：GitCode 前端 | GitCode 后端 | GitHub

💬 技术咨询：添加微信 17156169080，备注「RuoYi Office」