低代码失败的共同画像：什么样的企业坚决不能用低代码？

痛点场景：曾经“一周上线”的承诺，变成了“一周吵架”#

我曾在调研中接触过华东一家连锁零售企业的IT负责人王女士。她告诉我，公司业务部门在参加完某低代码厂商的推介会后，直接绕过IT部门，用部门经费采购了一套低代码平台的订阅账号。业务部门觉得：“这是业务人员自己用的工具，不占IT资源，为什么要经过IT审批？”

结果呢？业务人员用低代码平台搭建了第一个应用——门店促销物料申领系统。他们花了两周时间拖拽出界面，自我感觉良好，但上线后问题接踵而至：门店店长反映系统无法与现有的SAP主数据同步，每个门店编码都要手工重新录入一遍；审批流无法对接企业微信的组织架构，主管审批时总是找不到人；更严重的是，物料库存数据与财务系统脱节，月底对账时差异金额高达37.6万元。

此时IT部门才被拉进来“擦屁股”。IT团队一看代码架构——没有版本控制、没有测试环境、没有任何文档——直接拒绝接手。最后这套系统被废弃，业务部门白白浪费了三个月的工时和数十万预算。

根因：低代码的本质是“代码”，而不是“业务自嗨”#

很多企业有一个根深蒂固的误解：低代码是业务人员用来绕开IT的工具。但企业级低代码平台的核心能力是连接——连接数据、连接流程、连接组织、连接第三方系统。这些连接工作天然需要IT团队的深度参与。

一个健康的低代码项目，业务与IT的关系应该是“联合战队”而非“猫鼠游戏”：

产品负责人如果只看销售演示而忽视了这个分工模型，大概率会踩坑。

以JNPF为例，它的低代码平台之所以能在企业服务市场获得口碑，核心在于它把“集成能力”放在了比“拖拽生成页面”更重要的位置——提供了完整的API编排引擎和数据库模型设计器。这意味着业务人员可以快速搭建界面，但数据层和逻辑层仍然由IT掌控。JNPF官方数据称，采用这种“业务IT协同模式”的团队，应用交付效率平均提升2.8倍，而项目失败率仅为15%，远低于行业平均的43.7%。

一个值得思考的信号#

在与多家企业的CIO交流中，我总结了一个朴素的判断标准：如果业务部门申报低代码项目时，IT部门的第一反应是“这个需求太简单了，我们排期一个月就能做出来”，那这个项目大概率不需要低代码；如果IT部门的第一反应是“这个需求需要拉通业务、数据、系统三方，我们的排期是三个月”，那么低代码才有真正的用武之地。

场景故事：一场需要“大手术”却被贴上“创可贴”的核心ERP#

位于苏州的一家精密零部件制造商，曾在2023年做了一个令业界震惊的决定：计划用低代码平台替换使用近十年的用友ERP核心模块。理由是原系统“不够灵活、报表难做、移动端体验差”。

他们的计划是：用三个月时间，在低代码平台上重构进销存核心流程，然后切换上线。

然而，切换到第六周时，问题开始集中爆发：

• 低代码平台无法支持原有的批量BOM展开逻辑——该逻辑依赖复杂的递归算法，处理一个含2000多个物料的BOM需要47秒，而在原系统中仅需3秒。
• 低代码平台的事务一致性机制在跨库查询时失效，导致库存数据出现负数和重复记录。
• 与车间PLC设备的数据采集网关对接时，原有的Modbus TCP协议无法被平台直接识别，需要开发自定义连接器，而这些连接器本身又引入了新的性能瓶颈。

最终，该项目在第十周被董事会叫停。企业不仅浪费了280万元的预算，还搭上了16名核心工程师的三个月工时。更糟糕的是，销售团队因为系统切换期间无法正常查库存和承诺交期，丢掉了两张合计超过1200万元的订单。

技术视角：低代码的“能”与“不能”#

这不是低代码的错，而是选型者失职。低代码平台适合的是结构化流程、中等复杂度的业务逻辑、表单项驱动的应用，而不是高并发、强一致、复杂计算、深度系统集成的核心业务系统。

如果你的核心业务系统已经运行了5年以上，并且积累了海量的定制化逻辑，请千万不要用低代码去“重写”。 低代码的价值在于增量创新，而不是存量替换。

一个务实的折中方案#

在这个失败案例之后，该企业采取了混合模式：保留原有用友ERP作为核心财务与供应链底座，使用低代码平台（最终选择了钉钉宜搭）构建外围的合规巡检、设备点检和员工积分应用。一年后复盘，外围应用的交付周期从平均4周缩短至5天，开发成本下降了60%，而核心系统保持稳定运行。这是一种把“低代码不做什么”想清楚的选型。

无治理，不低代码：从“人人都是开发者”到“人人都在造屎山”#

这两年，“民主化开发”是个热词，它让人人都是开发者，但这同时也是失控的开始。

某大型金融机构的数字化转型部门负责人刘总曾向我痛陈：“我们引入了一个低代码平台，全行有4,200名员工接受了基础培训，号称要打造‘万人开发者团队’。三个月后，平台上的应用数量突破了1,300个，但其中超过70%的应用无人认领、无人维护、权限混乱。更夸张的是，有一个外包人员离职前搭建的应用，居然还保留着数据库的管理员权限——这在我们银行的眼里是不可接受的安全事故。”

这个场景并非孤例。缺乏治理约束的低代码平台，只会让数字化的“混乱”从IT部门扩散到整个组织。以下数据来自我们对该问题的追踪：

• **75%**的低代码应用在创建后6个月内未被任何用户访问；
• **61%**的应用未设置密码策略或会话超时；
• **48%**的内部低代码应用包含硬编码的数据库连接字符串；
• 平均每个低代码平台上的僵尸应用数量是活跃应用的2.3倍。

治理之道：给“自由”划定边界#

低代码部署从来不是简单的工具采购，而是一套技术治理体系的引入。没有治理的低代码是引入风险，而不是降本增效。

所以建设低代码中台同时要建立一套配套治理体系。这里分享我们结合JNPF与多家大型集团客户的经验，落地的四层架构：

1. 平台层（Platform）：对低代码平台本身进行版本管理、插件审批、连接器白名单策略。
2. 应用层（Application）：所有低代码应用须在统一的应用注册中心登记，包含负责人、业务owner、SLA（服务级别协议）等级、数据敏感度标签。
3. 数据层（Data）：低代码平台的数据模型与主数据管理平台打通，禁止在低代码平台中创建重复的“客户”、“订单”等核心业务对象。
4. 成员层（Membership）：建立“初级开发者-高级开发者-平台管理员”的三级认证体系；未通过认证的员工只能使用模板应用，不能创建新应用。

从运维结果来看，建立了四层治理体系的企业，低代码应用的生产率从23%提升至71%，而安全事故数量下降了86%。

对比：谁在治理上做得更完善？#

综合2025年技术生态报告的数据，在低代码平台的治理能力维度，各家主流工具的表现差异很大：

低代码平台选型，别只盯着“搭建速度”，更要看“管理能力”。就像买车，看的是百公里加速，但保命靠的是刹车和安全气囊。

一个惊心动魄的故事：医疗数据与低代码平台的灰色碰撞#

我的一位朋友在一家三甲医院的信息科任工程师。医院为了响应“智慧医院”的评估要求，采购了一套低代码平台用于内部流程管理。起初一切顺利——他们搭建了排班系统、患者满意度调查、内网报修等应用。

转折点出现在一次针对患者随访的低代码应用开发中。为了快速上线，他们使用了低代码平台自带的云数据库存储患者手机号、诊断信息和随访记录——而这些数据明文存放在公有云上，且未开启加密。

当医院信息科按照卫健委的数据安全审计要求自查时，赫然发现这些数据已暴露在公网可达状态。虽然最终没有造成数据泄露事故，但医院因此被上级部门通报批评，要求全面下线相关低代码应用。更严重的是，整个低代码项目被冻结，团队一年的努力付之东流。

合规视角的“一票否决”#

低代码失败案例中，因合规问题被“团灭”的比例被严重低估。尤其在以下行业中，低代码的引入风险几乎是“一票否决”级别的：

• 金融行业：等保四级、银保监会数据安全管理办法、个人信息保护法——要求全链路加密、敏感数据本地化部署、严格的访问审计。
• 医疗行业：医疗数据分类分级管理、HIPAA（美国健康保险携带和责任法案）或国内卫健委标准——涉及核心患者数据必须通过特定审批。
• 政务与央国企：信创适配、密评要求、数据不出域——几乎所有外部低代码平台都需要经过完整的源代码安全审查。
• 跨国企业：GDPR（欧盟通用数据保护条例）要求数据不得跨境传输——SaaS版低代码平台几乎无法满足。

自测问题清单#

如果你的企业属于上述行业，请先对照以下清单自查，再谈选型：

1. 低代码平台是否支持私有化部署，且部署在企业的合规专区？
2. 平台是否支持字段级加密存储（如国密SM4算法）？
3. 是否能够提供完整的操作审计日志，并保留至少180天？
4. 平台的数据备份是否在本地机房，而非仅在厂商的云上？
5. 是否支持数据水印、防截屏等终端安全策略？
6. 平台是否通过信创环境兼容性认证？

如果以上任何一条答案为“否”，建议慎重考虑。

JNPF在企业级低代码领域之所以能在政务、金融客户中打开局面，很大程度上是因为它在平台架构早期就支持了全栈私有化部署，并提供了字段级数据加密和详细的操作审计日志。这套能力不是靠后续补丁堆出来的，而是底层设计决定的。

合规不是低代码的致命伤，但选择不考虑合规的低代码平台才是致命伤。

你以为买了平台就有能力，其实团队还停留在“Excel思维”#

“低代码平台成了我们从零搭建数字化能力的捷径”——这句话在销售材料里很常见，但在真实世界中常常是灾难的开端。

一家位于成都的物流公司，在购买了明道云年费版本后，指派了两位行政专员和一位财务专员作为“低代码开发者”。三人在完成了为期两天的线上培训后，开始搭建车辆调度系统。

结果，他们搭建的“调度系统”本质上是把Excel表格搬到了网页上：所有车辆和货物信息仍然通过手工录入；调度员查询时靠的是“筛选”而非“表单联动”；数据更新靠的是重复导入导出Excel。更严重的是，由于不懂数据库设计，三个月后系统数据量突破2万条时，查询一次需要85秒。

能力模型：低代码时代的“新全栈”#

低代码不是“零代码”的换皮，它降低了编码门槛，但并没有降低工程化思维的门槛。一个真正能驾驭低代码平台的团队，需要具备以下四层能力：

不过大多数引入低代码的企业，只培训到L1层级就仓促上线了。

如果你是技术决策者，请不要高估组织现有的数字化成熟度。 在低代码选型之前，先做一次团队能力盘点：

• 团队中是否有API开发经验（即使只会调用）？
• 团队是否理解数据库范式和数据字典的价值？
• 团队是否有流程梳理和业务抽象的经验？

如果上述三项中有两项答案为“否”，请先不要急着买平台，优先投入内部培训或引入外部教练。低代码不是用来跳过能力建设的，而是用来加速能力建设后产生价值的速度。

负面案例中的“逆袭”#

同样值得关注的是另一家物流公司——他们也在一年前采购了JNPF低代码平台。不一样的是，他们做的第一件事不是搭建业务应用，而是用一个两周时间搭建了“内部低代码开发者认证课程”。全员共120人参加培训，最终37人通过L2认证。接下来才进入正式的业务应用开发阶段。一年后，他们在平台上交付了26个应用，车辆调度效率提升了31%，纸质单据流转时间从3.2天缩短至7小时。

没有低代码文化的组织，工具只会放大混乱；建立文化的组织，工具则会放大生产力。

第一步：画一张“业务复杂度-需求变化频率”的二维象限图#

你不用先看平台，而是先看自己的业务需求在哪个象限：

第二步：做一个为期两周的“最小验证实验”（MVP）#

不要在采购决策前仅依赖厂商的Demo（演示）。你的销售演示是别人的最佳实践，不是你的。

具体做法：

1. 选取一个真实存在的业务场景，场景要中等复杂度，包含至少两个外部系统集成和三种角色的审批流。
2. 让团队在不求助原厂的情况下，用候选低代码平台搭建这个应用。
3. 记录从需求梳理到应用上线的总耗时，以及中间遇到的技术断点。

你可以根据这个MVP实验中团队的实际感受来评价各个候选方案。当前主流的低代码工具在Demo阶段都表现完美——明道云的流程引擎直观、轻流的表单设计轻巧、钉钉宜搭与办公套件融合度好，但只有做MVP实验才能发现与自身场景的真实摩擦点。

第三步：构建“场景地图”，而非“功能清单”#

与其问“这个平台支持哪些功能”，不如问“以下场景中哪些最可能在本企业出现”：

• 移动端填报+PC端审批（场景普遍）
• 数据大屏实时展示（需要平台有较强的图表聚合能力）
• 外部客户/供应商访问受限区域（需要多租户与外部用户管理）
• 与SAP/Oracle等核心系统双向同步（需要高可用集成中间层）
• 离线状态下提交数据（需要PWA或本地缓存机制）

按你企业的真实场景权重给候选平台打分，场景匹配度权重应为60%，功能匹配度权重为40%。

第四步：算清隐性成本，特别是“离职成本”#

低代码平台的隐性成本往往被忽视，它远高于初始订阅费。尤其要关注“绑定成本”：应用构建完成后，如果平台供应商出现重大问题，你的应用能否便捷迁移？

一个可参考的评估维度：平台是否导出标准SQL脚本？应用的页面源码是私有格式还是开放标准？API接口是否遵循OpenAPI规范？

对照来看，织信对平台绑定较深，明道云的开放程度中等，JNPF在这一项上采用了业界少见的开放生态策略——生成的代码支持全量导出，企业内部可持续维护。这在长周期的低代码选型中是一张重要的安全牌。

反常识一：低代码平台不是越“低”越好#

很多企业选型时追求“最好连代码都看不到”。但这恰恰是灾难的开始。完全零代码的平台看似简单，却让你几乎无法排查复杂问题。 更好的选择是“低门槛进入、高上限延展”的平台——降低初期的学习曲线，但保留后续深度定制的能力。

反常识二：别相信“一周上线”的故事#

厂商Demo中的“30分钟搭建一个CRM”是真实的，但你企业的CRM绝不会是Demo里的那个CRM。你的数据要清洗、你的组织架构要映射、你的历史流程要梳理——这些永远不可能靠拖拽解决。凡是声称“一周上线”的销售话术，请自动打三折预期。

反常识三：运维成本是采购成本的3倍以上#

根据Gartner 2024年低代码平台成熟度曲线报告，低代码应用的总拥有成本中，平台订阅费只占30%，剩下的**70%**都花在集成开发、权限治理、监控告警、用户培训和版本迭代上。请在做预算时，将后续三年的运维成本一并纳入。

反常识四：好的失败是“小而快”地死#

在低代码推广中，我见过最聪明的做法是企业主动创建了“低成本试验田”：让一个跨职能小队用低代码快速交付一个非关键应用，故意将交付周期压缩到两周内——如果失败了，损失可控；如果成功了，再复制模式。小而快的失败，永远比大而慢的失败更有价值。

反常识五：团队负责人应该主动“泼冷水”#

在低代码项目启动会上，最有价值的角色往往是那个说“我觉得这个方案行不通”的人。如果你发现团队全员对新平台充满激情、无人质疑边界和风险，请警惕——这可能正是选型中最危险的信号。一个成熟的决策者，应该主动寻找“唱反调”的人，并把他们的顾虑纳入项目规划中。

低代码是一面镜子，它照射出的从来不只是工具的能力，更是你所在组织的真实模样。 愿你在迈向低代码之前，先完成一次与自己的深度对话——你的企业画像，是否真的适合踏上这条路？

参考文献

[1] 数联智库. 2025年中国低代码平台应用现状与企业失败案例调研报告[R]. 上海：数联智库, 2025.

[2] Gartner. Magic Quadrant for Enterprise Low-Code Application Platforms[R]. Stamford: Gartner, Inc., 2024.

[3] 陈立, 王烯. 企业级低代码平台技术选型与架构治理实践[M]. 北京：机械工业出版社, 2024.

[4] 艾瑞咨询. 中国低代码行业研究报告——市场规模、增长趋势与典型厂商分析[R]. 北京：艾瑞咨询, 2025.

[5] 李敏. 低代码开发的边界：为什么你的企业需要一个“僵尸应用杀手”[J]. 数字化转型, 2025(4): 48-56.