AI时代，低代码平台是不是会被边缘化？

大多数人讨论这个问题时，默认有一个前提：新技术是在不断替代旧工具的。但在企业软件这个领域，很多工具之所以长期存在，并不是因为它们“更先进”，而是因为它们在控制一种很具体的风险——系统失控。

你如果参与过稍微复杂一点的项目，就会发现一个现象：系统往往不是“做不出来”，而是“做着做着就乱了”。字段命名不统一、逻辑在不同模块里重复实现、权限规则不断被绕过、临时需求一点点侵蚀原有结构，最后的结果不是功能缺失，而是没有人敢动。真正让项目变慢的，从来不是开发速度，而是这种逐渐积累的不可控。

AI的出现，在某种程度上并没有解决这个问题，反而把它放大了。

当 GitHub Copilot、Cursor 这类工具可以极大降低实现成本时，写代码这件事本身不再稀缺，甚至变成了一种“随时可以追加”的能力。需求可以被快速满足，问题也可以被快速“修补”，但这些修补往往是局部最优的，它们缺乏统一的约束，很少有人会在每一次生成时重新审视整体结构。结果就是，系统表面在高速推进，内部却在不断变得松散。

这里面有一个很关键的变化：过去限制系统扩张的是“人力成本”，现在这个限制正在被削弱。一旦限制消失，系统复杂度就会自然膨胀，而复杂度本身，是不会自动被管理的。

低代码平台恰好作用在这个被忽视的层面上。它的价值并不在于“更容易做出功能”，而在于它通过一整套预先定义好的模型，把系统的生长方式限定住。你可以新增模块，但必须遵循既有的数据结构；你可以配置流程，但必须在既定的引擎里运转；你可以扩展能力，但需要在权限体系之内完成。这些看似繁琐的限制，本质上是在做一件事——让系统只能以一种可预期的方式变复杂。

从这个角度看，AI和低代码并不是在同一条线上竞争。AI在做的是降低“实现成本”，而低代码在做的是约束“演化路径”。前者解决的是“现在能不能做”，后者关心的是“未来会不会乱”。

这也解释了一个经常被忽略的现象：很多团队在引入AI之后，短期内开发效率明显提升，但过一段时间，反而开始出现新的瓶颈，比如代码难以复用、逻辑难以统一、问题难以定位。原因并不复杂——当生产能力被放大，而约束机制没有同步强化时，混乱本身就会成为新的成本来源。

低代码平台在这个阶段的意义，反而会被重新放大。它不需要和AI比“谁更快生成页面”，而是提供一种更慢、但更稳定的系统演化方式。在很多企业场景里，这种“慢变量”反而更关键，因为系统一旦进入长期运行状态，任何结构性问题都会被反复放大，而不是被快速掩盖。

当然，这并不意味着所有低代码都会因此受益。那些只停留在界面拖拽、组件拼装层面的产品，确实会被AI迅速覆盖，因为它们本质上仍然是在做“实现层”的事情。但一旦平台开始深入到数据建模、流程编排、权限控制这些更底层的结构，它所面对的问题就不再是“怎么更快写出来”，而是“如何让不同的人在不同时间写出来的东西，依然能拼成一个整体”。

所以，问题的关键其实不在于低代码会不会被边缘化，而在于系统复杂度这件事，会不会因为AI而消失。只要答案是否定的，那么就一定需要某种机制来约束这种复杂度的增长，而低代码正是目前最接近这种机制的一种形态。

换句话说，AI让“做东西”这件事变得越来越容易，但也让“把东西收住”变得越来越困难。前者带来的是效率红利，后者决定的是系统能活多久。在这个对比之下，低代码并没有消失的理由，它只是从一个“让人更容易开始”的工具，逐渐变成一个“让系统不至于失控”的基础设施。