低代码真的不符合软件工程吗？先看它解决的是哪类工程问题

前段时间看到一个挺有代表性的评论：

低代码不就是快速上线要钱的，省时间省成本，可是真的符合软件工程吗？

这个问题问得很直接，也问到了很多 IT 负责人心里的担心。

在不少人的印象里，软件工程应该是需求分析、架构设计、数据库设计、编码规范、测试验证、版本管理、上线运维。这是一套很严肃的工程活动。低代码听起来却像是另一种东西：拖拖拽拽，配几个表单，画几条流程，业务部门自己搭一搭，就上线了。

如果低代码真的只是这样，那这个担心就很正常。

企业系统不是临时网页。它要承接订单、库存、合同、付款、审批、权限、日志和报表。一个系统如果只有页面，没有模型；只有流程，没有责任；只有配置，没有版本；只有上线，没有测试；那它确实谈不上工程化。

但问题也在这里。

判断低代码是否符合软件工程，不能只看它是不是少写了代码，也不能只看它是不是拖拽配置。真正要看的，是它解决的是哪类工程问题，以及它有没有把这些问题纳入可管理的结构。

这篇文章，我们就从企业应用开发的角度，把这件事讲清楚。

一、先说清楚，软件工程不是等于手写代码

很多人把软件工程理解成写代码。

这个理解太窄了。

写代码只是软件工程里的一个环节。软件工程真正关心的，是如何用一套可控制、可验证、可维护的方法，把业务需求变成长期可运行的软件系统。

换句话说，软件工程真正关心的是：系统能不能被严肃地设计、交付和维护。

一个企业系统至少要回答这些问题：

• 需求是谁提出的，是否经过确认？

• 业务对象有哪些，字段含义是否清楚？

• 数据从哪里来，流向哪里去？

• 谁能看，谁能改，谁能审批，谁能导出？

• 流程节点由谁负责，超时以后怎么处理？

• 系统上线前有没有测试和验收？

• 版本变更有没有记录，出了问题能不能回溯？

• 后续运维、权限调整、字段变更由谁负责？

这些问题，才是软件工程的基本盘。

所以，一个系统是否符合软件工程，不能只看它用了 Java、Python、Go，还是用了低代码平台。手写代码也可能写成一堆没人敢改的烂系统；低代码如果有清晰的模型、权限、流程、日志、版本和测试机制，也可以成为一种工程化交付方式。

当然，这里有一个前提：低代码平台本身要具备企业级能力。只会生成页面和表单的工具，不能替代软件工程。

二、低代码最容易被误解的地方，是把它看成页面工具

低代码最早给很多人的印象，就是快。

快到什么程度？以前一个简单管理页面要开发几天，现在拖几个字段，半小时就出来了。以前一个审批流程要排开发，现在业务人员画一画节点，流程就能跑起来。

这当然是低代码的优势。

但也正因为这个优势，很多人容易把低代码看轻。觉得它只是把前端页面做快一点，把增删改查做快一点，把审批表单做快一点。

如果低代码停在这个层次，它确实很容易变成“快速上线工具”。

这种低代码项目最常见的问题是：

• 表单很多，但业务对象没有整理。

• 流程很多，但责任边界没有讲清。

• 页面很多，但数据口径不统一。

• 应用很多，但权限和日志没有统一治理。

• 上线很快，但后续没人维护。

这种做法表面上很快，后面会很重。

因为企业应用的难点不在“做出一个页面”，而在“这个页面背后的业务动作能不能长期运行”。

比如供应商准入管理。

页面上看，只是供应商名称、联系人、资质文件、评分、审批状态几个字段。但真正运行时，企业要管理供应商分类、黑名单、准入审批、资质有效期、采购员权限、付款主体、合同主体、质量异常记录，还要和 ERP、采购系统、财务系统发生关系。

如果只做一个供应商登记表，这叫页面。

如果把供应商从申请、审核、准入、变更、停用、风险预警、历史记录都管起来，才开始接近企业应用。

所以低代码是否有工程价值，关键看它停在哪一层。

只停在页面层，风险很大。

能进入业务对象、权限、流程、数据、接口、日志和版本这一层，它才有讨论软件工程的资格。

三、哪些低代码场景确实不适合硬上

讨论低代码，不应该把它说成万能工具。

企业里有些系统，本来就不适合用低代码硬做。

第一类，是高性能核心交易系统。

比如高并发交易、实时撮合、复杂计费、大规模搜索、底层调度、工业控制系统。这类系统对性能、稳定性、算法、底层资源控制要求很高，通常需要专业研发团队进行架构设计和深度开发。

低代码可以做外围管理、运营后台、审批配置、数据看板，但不宜承担核心交易引擎。

第二类，是已经高度标准化的大型主系统。

比如成熟 ERP 里的总账、应收应付、库存核算、成本结转；MES 里的工序报工、设备采集、质量追溯；CRM 里的标准销售流程和客户管理。企业如果已经有成熟系统承接，就不要为了“统一到低代码”而把主系统重做一遍。

低代码更适合补空白、做扩展、做跨系统协同，而不是为了替代而替代。

第三类，是需求还没有想清楚的临时想法。

有些业务部门今天想要一个表，明天想要一个看板，后天又想换一套口径。这个阶段可以用 Excel、在线表格或原型工具先跑一跑。等业务动作稳定下来，再考虑是否系统化。

低代码虽然开发快，但快不代表可以跳过需求梳理。需求混乱时上平台，只会把混乱固化得更快。

第四类，是没有责任人的应用。

低代码降低了应用开发门槛，也带来一个新问题：谁都能提，谁都想用，但上线以后没人负责。

没有业务负责人，没有数据负责人，没有运维负责人，这类应用即使做出来，也很容易变成没人维护的系统垃圾。

所以，低代码要符合工程要求，第一步反而是克制。该做的做，不该做的别乱做。

四、哪些场景反而最适合用低代码做工程化承接

低代码真正适合的地方，常常位于企业主系统和一次性临时表格之间。

这些应用有几个共同特点：

• 业务确实长期存在。

• 流程需要多人协同。

• 数据会被反复查询和统计。

• 规则会变，但不是每天推倒重来。

• 需要和 ERP、MES、CRM、OA 等系统发生关系。

• 如果继续放在 Excel 或微信群里，会带来版本、权限、追溯和责任问题。

这类场景，在很多企业里非常多。

比如质量异常闭环。

异常来自车间、仓库、客户投诉或供应商来料。它要关联物料、批次、工单、供应商、责任部门、整改措施、复检结果和关闭状态。这个业务不一定适合直接改 ERP，也不应该长期靠 Excel 追。用低代码做成应用，就可以把发现、隔离、分析、整改、复检、关闭这些动作串起来。

再比如供应商交期跟踪。

采购订单在 ERP 里，但供应商承诺交期、延期原因、影响工单、责任采购、生产调整，往往在系统外流转。低代码可以把这些现场协同动作接住，再把关键结果反馈给采购和计划部门。

再比如客户回款风险管理。

财务系统有应收账款，CRM 有客户跟进，但“这个客户为什么可能逾期、谁去催、客户承诺哪天付款、需不需要领导介入”，这些过程信息常常没有被标准系统完整记录。低代码可以把客户、合同、发票、回款计划、风险等级、跟进记录、催办流程放到一个轻量应用里。

这些场景并不低级。

它们恰恰是企业管理里最常见、最琐碎、最容易失控的部分。

从软件工程角度看，低代码在这里的价值，重点不在“少写代码”，而在于把分散在 Excel、聊天记录、邮件、会议纪要里的业务动作，整理成可运行、可追溯、可迭代的应用结构。

五、判断低代码是否工程化，要看这六个检查项

企业选低代码平台，或者评估一个低代码项目，不能只问“搭得快不快”。

更应该问下面六个问题。

1、有没有业务对象建模

表单不是模型。

一个客户管理应用，核心对象可能有客户、联系人、商机、合同、发票、回款、跟进记录。一个质量异常应用，核心对象可能有异常事件、物料、批次、供应商、整改措施、复检记录。

如果平台只能做一张张孤立表单，后面很难形成真正的业务应用。

2、有没有权限体系

企业应用必须处理组织、角色、岗位、数据范围和操作权限。

谁能看全部客户，谁只能看本区域客户；谁能修改供应商银行账户，谁只能提交变更申请；谁能导出数据，谁只能查看报表。这些都要进入权限体系。

权限如果靠人工约定，系统上线越多，风险越大。

3、有没有流程和状态管理

审批流只是流程的一种。

很多业务还涉及状态流转，比如待确认、处理中、待复检、已关闭、已退回、已作废。状态变化背后有责任人、时间、原因、通知和后续动作。

低代码如果能把流程和状态管理起来，就能减少很多口头催办和线下确认。

4、有没有接口和数据集成能力

企业应用很少完全孤立。

它要读取主数据，调用 ERP 订单，关联 MES 工单，引用 CRM 客户，推送 OA 待办，输出 BI 报表。没有接口能力，低代码很容易变成新的信息孤岛。

5、有没有测试、版本和发布机制

低代码应用也要测试。

字段改了，会不会影响报表？流程节点改了，会不会影响审批？权限调整了，会不会让不该看的人看到数据？接口参数改了，会不会导致同步失败？

这些都需要测试环境、版本记录、发布审批和回退机制。

6、有没有日志和审计

企业系统最怕出了问题查不到。

谁修改了客户信用等级，谁改了供应商付款信息，谁关闭了质量异常，谁调整了项目预算，谁导出了客户清单，都应该留下记录。

如果低代码应用没有日志和审计，它就很难进入关键业务。

六、真正不符合软件工程的，是把低代码当成临时搭表工具

很多低代码项目失败，问题往往出在用法上。

把低代码当成“业务部门想要什么就搭什么”的工具，很快会出问题。

今天销售部搭一个客户台账，明天采购部搭一个供应商跟进，后天质量部搭一个异常记录。每个应用都能跑，但字段口径不统一，权限规则不统一，数据无法复用，应用之间也没有边界。

几年下来，企业可能从 Excel 堆，变成低代码应用堆。

这当然不符合软件工程。

正确做法应该更像平台治理。

企业至少要建立几条规则：

• 哪些应用可以由业务部门自建，哪些必须 IT 参与。

• 哪些数据对象必须使用统一主数据。

• 哪些字段、编码、状态、权限必须遵守企业标准。

• 哪些应用上线前必须测试和审批。

• 哪些接口调用必须经过安全评估。

• 哪些操作必须记录日志。

• 哪些应用长期没人使用要下线或合并。

做到这一步，低代码才不会变成新的混乱来源。

像织信这类企业级低代码平台，真正应该发挥价值的地方，是把应用建模、流程、权限、接口、日志和发布管理放进同一套平台规则里。这样业务部门可以更快表达需求，IT 部门也能保住工程边界。

七、AI来了以后，这个问题会更重要

现在很多人讨论 AI 生成应用。

这件事会继续往前走，而且速度不会慢。以后业务人员描述一句需求，AI 生成页面、生成字段、生成流程，都会越来越常见。

但 AI 让应用生成更快以后，工程化问题会更突出。

因为生成越容易，企业越容易生成一堆没人治理的应用。

谁来确认需求？

谁来审查权限？

谁来检查字段口径？

谁来测试流程？

谁来管理版本？

谁来处理接口调用？

谁来记录日志？

这些问题不会因为 AI 会写代码就自动消失。

相反，AI 越强，企业越需要一个稳定的平台层来承接它生成出来的东西。否则应用生成速度上去了，管理失控的速度也会跟着上去。

所以，低代码和 AI 的关系，不能只看谁替代谁。

更现实的方向是：AI 提高应用生成和配置效率，低代码平台提供业务模型、权限边界、流程机制、接口连接、版本发布和运行审计。

一个负责把需求更快变成初稿，一个负责让应用能在企业里长期运行。

这也是为什么我认为，AI 时代反而更需要讨论低代码是否工程化。因为企业不缺更多页面，企业缺的是可控、可维护、可追溯的业务应用体系。

结语

低代码到底符不符合软件工程，答案不能一刀切。

如果它只是一个拖页面、搭表单、快速上线的工具，那它确实很难承接严肃的企业系统。

如果它能把业务对象、字段口径、流程状态、权限控制、系统接口、测试发布、日志审计和后续运维纳入平台管理，那它就可以成为企业应用工程化的一种方式。

企业要警惕的，不是低代码本身。

真正要警惕的是：用低代码绕过需求分析，用低代码绕过 IT 治理，用低代码绕过权限和测试，用低代码把一堆 Excel 换成一堆网页表单。

这样做，当然不符合软件工程。

但如果企业把低代码放在正确的位置，把它用于承接标准系统之外的业务应用、跨系统协同和现场变化，再配合统一的模型、权限、流程、接口和日志管理，它就不是工程的反面。

它解决的，是企业软件工程里长期存在的一类问题：

主系统太重，Excel 太散，业务变化又太快。

这中间，需要一层可治理、可迭代、可持续沉淀的应用平台。

低代码真正的价值，就在这里。