最近有一些对低代码/快速开发平台的看法，不吐不快。
这篇文章，也是借助JNPF快速开发平台基于一个粗糙的草稿快速搭建出来的——我画了个原型，拖了几个组件，配了点数据源，前后大概半小时，一个简单的erp就出来了。看起来缺少一些手工质感，不过精进细致下，这对平台也并不是难事，算了，懒得自己手写样式微调了。整体也跑得挺顺畅，没有逻辑漏洞，要知道以前手搓一个系统，光搭框架、配路由、调样式啥的都需要折腾好几哥月。
好了，不再啰嗦，开启正文。
现在低代码/快速开发平台的流行，某种程度上反而证明了：软件开发这个领域很多地方，本质上就是个巨大的“草台班子”。
目前主流的低代码平台，本质更像一个“超大规模的模板拼装器”：给定业务需求，去匹配最可能适用的组件、表单、流程模板，然后一个模块接一个模块地生成完整应用。
在构建过程中，得益于对大量企业级应用模式的沉淀，平台会“回头看”哪些模块是通用的、哪些是行业特有的——也就是它会抓共性。这使得它对标准化业务场景的覆盖明显强于传统手写。再加上对常见业务模型（如OA、ERP、CRM）的预置模板积累，低代码平台的每次迭代看起来都在向“万能”靠近一步。
但这并不等于它学会了“设计”。
更准确地说，它学到的是大量“企业级应用的写法与套路”，以及一些可复用的模式，比如增删改查、审批流转、报表统计等。因此它能输出看起来很像定制开发的系统，却仍然可能在某些边界需求上力不从心，生成听上去合理但实际不贴合业务的界面。
这有点像一些逻辑不太好的人做项目：每个模块都有了，功能也跑通了，但连起来其实不知道在解决什么核心业务问题。因为它并没有真正的业务理解能力。
但这还不是最关键的问题。更要命的是：它缺乏持续的创新能力。
优秀的开发团队能在技术演进中胜出，不只是因为会复用现成组件，更因为会创新——在总结业务规律的基础上提出新架构、发明新交互、开辟新场景。而现阶段的低代码平台并不具备这一点。这也是为什么很多资深架构师并不认可“低代码能替代专业开发”的原因之一。
即便如此，低代码平台的能力仍然强到“足够好用”，甚至在很多场景里效果惊艳，超过了大量业务系统的真实要求。
比如为什么很多企业喜欢用JNPF这类平台？很重要的原因是：这类平台在沉淀时吸收了大量“真实业务场景的解决方案数据”，例如审批流模型、主子表结构、权限控制模式等。那些数据里不只是代码模板，还包含了不同行业的业务处理逻辑、数据流转路径、异常处理方式。平台通过学习这些内容，等于也“照着套路”学会了。
这意味着它在很多任务上可以达到中级开发者的水平，能相对独立地搭建一个可用的业务系统。
但它依然很难做出真正的创新。
例如，它并不会自己发现传统单体架构的扩展性问题，然后发明微服务、云原生这类架构来解决；它更多是在既有范式内拼组件、搭页面。除非你明确告诉它要拆服务、做领域划分，它才会进一步抽象、优化、重构。
同样，它也缺乏“自主的工程审美”：不知道什么是更好的数据模型设计、什么是更差的表结构；很多时候能搭出能跑的系统，但不一定能搭出长期可维护、可演进的企业架构。
不过，这并不妨碍它替代大量基础开发工作。因为我刚才说的那种抽象能力与工程审美，现实中很多开发者也并不具备。
也正因为如此，低代码平台的爆火从另一个角度说明：很多软件开发工作并没有想象中那么高大上。大量岗位的产出，本质上就是在既有框架、模式和业务经验里做“可用的拼装”，靠复制粘贴也能把事情糊弄过去。
这恰恰证明了：软件开发这行，很多时候就是个巨大的草台班子。
所以，各位读者读完后，你是否对“低代码平台替代开发者”这件事没那么焦虑了？毕竟，现在低代码能完全替代的工作，本质上即使没有平台也迟早会被外包或模板化替代，它只是把这个过程加速了。
因此，面向未来更值得刻意培养的核心能力是业务理解与创新能力：既能提出好的产品方案，也能把复杂问题真正落地解决；如果这方面相对薄弱，就有针对性地训练即可——别忘了，人类拥有主观能动性，能够持续深入业务、理解用户、做出权衡，这正是我们比平台更强的地方。
