低代码平台这两年的声量很大：拖拽表单、可视化流程、一键发布，几周就能上线一套内部系统。于是不少企业决策者会问同一个问题——既然低代码这么快，还有必要花钱做定制开发吗？我们的判断是：低代码替代的是「一部分开发工作量」，而不是替代定制开发本身。它把标准场景的成本压到极低，同时也把复杂场景的天花板暴露得更清楚。
一、低代码的真实能力边界
低代码的核心优势是「确定性场景的快速交付」，典型适用场景包括：
- 表单采集、审批流、报销、请假、台账类内部管理；
- 数据看板与报表汇总，且数据源已在现有系统内；
- 业务流程原型验证，用于在投入定制开发前确认需求；
- 部门级轻应用，用户量在数百人以内、并发较低。
它的边界同样清晰：
- 复杂业务逻辑：多级规则引擎、动态定价、复杂结算，拖拽配置很快会变成「配置地狱」；
- 终端体验与品牌一致性：面向 C 端用户的 APP、小程序，动效、启动速度、UI 细节很难做到位；
- 系统级能力：蓝牙、NFC、离线缓存、工控设备、串口通信等硬件对接；
- 性能与架构可控性：高并发交易、海量数据、需要自主调优的后端服务；
- 数据主权与长期成本：私有化部署受限、按用户数计费、迁移导出困难，容易形成供应商锁定。
一句话概括：低代码解决的是「业务配置问题」，定制开发解决的是「工程问题」。
二、场景适配度对照表
格达软件在项目评估阶段，通常先用一张表把需求分档，再决定技术路线：
| 业务场景 | 低代码适配度 | 建议路线 |
|---|---|---|
| OA 审批、报销、行政台账 | 高 | 低代码承载，少量定制补缺 |
| 电商小程序、会员营销 | 中 | 小程序定制开发 + 低代码后台 |
| 物联网、硬件对接 APP | 低 | 原生 APP 定制开发 |
| 高并发交易、核心 ERP | 低 | PC 软件 / 自研服务 + 私有化部署 |
| MVP 快速验证 | 高 | 低代码先跑通，再评估是否重构 |
关键不是二选一，而是分层：离用户越近、越影响体验和营收的部分越适合定制；离后台越近、越标准化的部分越适合低代码。
三、混合架构怎么落地
实践中比较稳的做法，是用低代码承载管理与流程前端，用自研服务实现核心业务，中间加一层业务网关解耦，避免哪天更换平台就要推倒重来：
# 低代码表单 -> 业务网关 -> 自研微服务
route: /api/v1/gateway/approval
form: leave_apply
handler: hr.leave.calculate # 复杂规则由自研服务实现
fallback: 低代码内置审批流 # 网关异常时降级
结合格达软件的业务，给几条具体建议：
- APP / 小程序开发：面向 C 端、涉及支付与营销的，优先定制，保证体验与迭代节奏；
- PC 软件开发：与设备、算法、专业流程绑定的场景，定制开发几乎是唯一解；
- 开发咨询：先花 1~2 周做需求分档与架构评估，比直接选平台省钱得多；
- 服务器维护：无论低代码还是自研，私有化部署、备份、监控、日志与容灾都要提前设计，这是最容易被忽略的隐性成本。
四、给决策者的四个判断问题
- 这套系统的核心价值，是「流程跑通」还是「体验与效率领先」？
- 三年后数据量、并发量、终端数量会增长到什么量级？
- 是否存在硬件对接、离线使用、深度算法等系统级需求？
- 数据能否接受放在第三方平台，迁移成本能否承受？
四个问题里若有两项以上偏向后者，就该认真考虑定制开发；反之，用低代码快速上线、把预算留给核心业务，是更聪明的选择。低代码不会取代定制开发，它只是把定制开发推到了更该被定制的位置——这也是格达软件一贯的技术选型原则：不追工具，只选合适的解法。