1、能力弱

低代码平台本身是一个开发框架，能在平台上做出什么很大程度上依赖于框架本身的内容。在当前阶段，很多低代码玩商拿出BPM（业务流程管理）、BI（数据分析）等产品在企业协同领域进行竞争，而在其他方面的应用还不存在更好的商业模式。

但同时我们也发现，低代码在一些领域也能为许多企业信息化转型提供很大助力；另一方面，已经有很多人开始向APP、游戏甚至更高的层面进行探索，承载核心业务、复杂应用、多变的C端未来可期。

2、灵活性不够

虽然很多低代码平台注明自身的灵活性强、能解决企业的个性化需求，但其前提是在框架的能力之内。如果公司的个性化需求刚好不在框架能力范围内，二次开发的话成本、时间都会增大。若企业所选的低代码平台恰好又不够开放，对平台支持和升级的强依赖性会让企业举步维艰。如果灵活性高，又可能造成易用性的降低，灵活性与易用性的平衡对低代码平台来说是个难题。

3、对开发者不友好

很多低代码平台框架对开发者来说是黑盒，这给开发者带来两大难题，一是活难干，二是前途不可知。

1）活难干是在开发时一旦遇到Bug、性能等问题，由于不清楚内部实现逻辑，问题排查无从下手，代码调试要反复切换界面，只能干等平台支持。

2）前途不可知是专业程序员高度依赖低代码平台，而疏于Coding会造成能力蜕化，这长期来看意味着未来专业能力的下降。

专业开发者是低代码生态中很重要的参与者，如何让专业开发者更和谐的融入低代码平台是个问题。

4、业务方观念扭转难

普通业务人员是低代码平台的重要用户，但让业务部门把低代码平台用起来，至少要跨过3道沟：技术门槛、心理门槛、动机门槛。

1）技术门槛，稍有技术含量、需要一定学习成本，便会阻挡下很多人；

2）心理门槛，很多人会出于畏惧新事物和学习而望而生畏；

3）动机门槛，以往业务方提出需求就能拿到软件，现在让他动手自己搭建结果还未可知。

这3道沟并非不可跨越，但却需要花些心思来解决。

1）跨越技术门槛，可以采用无代码，但需要平衡灵活性的妥协；

2）跨越心理门槛，需要产品讲好故事、做好交互设计，调整如“BPMN图、ER图、外键、函数、脚本”等专业词汇，尽量避免触发用户畏惧心态；

3）跨越动机门槛，需要找到足够痛的场景，通过行业模板、业务模板、交互设计等打造足够简单的操作方式。

5、应用治理、平台性能等

低代码平台降低了应用开发成本，如果应用爆发式增长，出现大量无人或较少人使用的应用，则对业务价值不大，却会带来额外的认知、管理成本。同时，应用数和使用人数的增长，也会给平台性能带来挑战。另外，用户追求个性化前端呈现与平台固化的前端呈现也是一种需要应对的矛盾。

总之，低代码是个好技术，框架本身可以大大提升效率，但同时，它也存在着一些问题。企业需要拿出手段解决相应的矛盾才能能更好的发展。