低代码和无代码项目失败的 7 大原因

在大模型的加持下，低代码和无代码工具现在很受欢迎。根据市场研究公司 Grand View Research 预测，从 2023 年到 2030 年，全球低代码开发平台市场将以约 23% 的复合年增长率扩张。报告指出，这一增长主要归因于企业对数字化转型和业务流程自动化的日益重视。此外，对快速解决方案和更高效业务流程的需求也在推动这一趋势。

尽管“更容易开发”的承诺极具吸引力，比如加快应用程序开发、降低费用、提高灵活性。然而，这种技术并不是所有场景都适用，在某些情况下，低代码和无代码解决方案甚至可能成为提升效率的障碍，企业在选择它们时必须准备好应对潜在的风险和挑战。

以下是低代码项目失败的 7 大原因：

• 失去深度与灵活性
• 过度简化的解决方案
• 无法扩展
• 不稳定的大型语言模型（LLM）
• 安全风险
• 供应商锁定
• 低估了这项技术的能力

1. 不够灵活

低代码和无代码工具的核心用途之一是让非技术人员也能参与软件开发。这不仅扩大了可以参与开发的人群，也为企业节省了雇佣更多开发者的成本。但对于采用这类解决方案的企业来说，也要做好牺牲部分灵活性的心理准备。

“低代码/无代码平台通常提供一系列预设模板和组件，使业务人员能够快速构建简单的应用。”云服务提供商 Caylent 的云原生开发高级总监 Clayton Davis 表示，“但这些模板往往缺乏打造真正定制化、面向用户的应用所需的灵活性和深度。”

Davis 指出，虽然低代码和无代码工具对于内部业务系统或简单任务足够使用，但在面向客户的应用中就显得力不从心——用户体验至关重要，而这类工具往往达不到要求。

对于需要掌控应用架构的开发者来说，这些工具也可能具有限制性。Deep Render（视频压缩技术开发商）的联合创始人兼 CTO Arsalan Zafar 建议，可以选择支持扩展性的低代码平台，或在必要时通过 API 集成自定义功能。

2. 过度简化

Zafar 认为，另一个相关挑战是“过度简化问题”——业务人员可能会创建出不能充分解决复杂问题的应用。

他的团队曾尝试用无代码平台构建一个用于比较视频编解码器的应用。“最初，这个平台让我们能快速搭建基本版本，比起传统开发方式节省了大量时间。”他说。

但随着开发推进，平台的局限性逐渐显现出来。“当我们想要加入一些能让产品脱颖而出的定制功能时，发现平台的限制变得非常明显。”Zafar 表示。

集成更高级的功能，如多层视频对比指标或 AI 驱动的增强功能，变成了繁琐且耗时的过程。平台缺乏对定制集成的支持，迫使团队花费额外时间绕过其限制，影响了交付定制化解决方案的能力。

“这次经历告诉我们，无代码工具在快速构建初期原型方面非常方便，但在满足复杂、企业级需求的可扩展性方面存在明显不足。”Zafar 总结道。

3. 无法扩展

“低代码和无代码在原型设计或测试最小可行性产品（MVP） 方面表现非常出色，但在规模化方面却远远不足。”DigitalSamaritan 创始人兼软件工程师 Kushank Aggarwal 表示。该平台专注于分享人工智能（AI）教程和工具。

他举例说：“当我们提出 [AI 工具] Prompt Genie 的想法时，我们仅用了四天时间就完成了从构思到上线并获得第一个付费客户的全过程，完全依靠无代码方法。”

“但一旦我们实现了市场契合度，就遇到了扩展方面的重大挑战。”Aggarwal 表示，所使用的低代码/无代码平台并未设计来支持不断增长的用户群，“因此我们必须彻底重建并迁移所有用户数据，这过程极其复杂。”

他还提到，可能会遇到数据丢失、停机和工作流中断等问题。“根据你的创意验证程度，你可以跳过低代码和无代码，直接从零开始构建以实现更好的可扩展性。”

Zafar 补充道：“虽然这些平台适合小型、不太复杂的项目，但它们很难满足大规模企业级应用的需求。在将它们部署到关键系统之前，务必评估平台的长期可持续性。”

4. 不稳定的大型语言模型（LLM）

如今大多数低代码或无代码开发都依赖大型语言模型（LLM） 来生成内容，但这对企业来说可能是昂贵的。

AWS 高级机器学习工程师 Devansh Agarwal 表示：“LLM 在预测下一个词或 token 上表现出色，基于此，它们可以生成句子和代码。但它们不像人类那样具备推理能力。”

他说：“软件产品的需求非常复杂且不断变化。要从 LLM 得到较好的输出，我们需要尝试多种提示，这会带来较高的成本。”

Agarwal 表示：“你很难把所有的产品需求信息输入给 LLM 并期望它生成完整的解决方案，因为产品需求本身就在不断变化。”

他补充说：“如果你让 ChatGPT 写代码，结果出错了，你让它修正，它可能会生成一个全新的方案。试想一下当产品需求频繁变更时，这种情况会造成多么混乱的局面。”

5. 安全风险

Quickbase（项目管理软件提供商）的首席信息官 Jon Kennedy 表示：“作为 CIO，你希望提供给组织的技术既安全又实用。不幸的是，并非所有无代码或低代码平台都在框架层面考虑到了安全性与治理机制。”

Kennedy 指出，像医疗等高度监管的行业有严格的安全合规要求，不是所有平台都能满足这些需求。

他说：“当一个无代码平台在整个组织中广泛部署，或者开放给外部用户时，限制访问权限和控制措施可能是明智之举。Quickbase 的许多客户都拥有大量的工具和供应商需要整合管理，他们需要在合适的时间、合适的地点安全地访问这些数据。”

Agarwal 补充说：“如果大量网站使用了一个带有微小代码漏洞的无代码工具来创建，那么这些网站及其数百万用户都将面临巨大风险。这非常可怕，因为使用这些工具的人根本不知道如何修复这些问题，所以这些风险将在公共领域存在很长时间。”

随着低代码和无代码工具的普及，这种严重故障的风险也在呈指数级增长。Agarwal 建议：“始终让人类掌握主导权，把工具当作辅助手段。你至少应该有一个专家团队来审核这些工具生成的内容。”

6. 供应商锁定

Aggarwal 表示，许多低代码或无代码平台都是封闭生态系统，切换平台非常困难。

“这种依赖关系可能导致更高的成本、更低的灵活性，还存在平台关闭你需要的功能的风险。”他说。

微软安全技术负责人 Siri Varma Vegiraju 表示：“如果你想更换平台，那简直是一场噩梦。因为你被锁死在这个平台上，切换意味着要从头开始理解新平台的一切。”

他说：“这意味着你要重新构建所有东西，而如果是写代码的话，你只需要修改一些基础设施组件和依赖项就可以了。”

7. 低估了这项技术的能力

虽然大多数专家都在谈论低代码的技术短板，但也有一种倾向是低估这些工具的潜力。

Alteryx 的首席数据与分析官 Alan Jacobson 表示：“有些人对低代码的偏见来源于它的名称以及它让非技术人员也能使用的特性。这种偏见导致人们错误地认为这些工具不够强大或不够先进。”

Jacobson 表示，企业可以通过确保团队全面了解这些工具的功能，来纠正这种误解，从而释放其真正价值，实现最大效益，并赋能终端用户。