最近有个问题一直在我脑子里打转：当Vibe Coding（氛围编程）越来越火的时候，我们还需要低代码平台吗？这个问题就像在问，有了自动驾驶汽车，我们还需要手动挡吗？
让我先讲个真实案例。去年我参与了一个金融科技项目，团队同时使用了某知名低代码平台和我们的Vibe Coding工作流。结果很有意思：低代码平台在处理标准业务流程时确实很快，但当我们遇到需要自定义风控规则时，就卡壳了。而Vibe Coding呢？我们只是重新描述了业务意图，AI就自动生成了符合要求的代码。
从系统架构的角度看，低代码平台就像预制菜——方便快捷，但口味固定。Vibe Coding则像是米其林大厨——给你精准的烹饪意图，就能做出定制化大餐。这背后是根本性的范式差异：低代码仍然在“编写”的框架内，而Vibe Coding已经跃升到了“定义意图”的层面。
来看看具体的对比。在开发效率方面，低代码平台通过可视化组件确实降低了入门门槛。但根据Gartner 2023年的报告，超过60%的低代码项目在遇到复杂业务逻辑时需要专业开发人员介入。Vibe Coding则不同，它让业务人员直接用自然语言描述需求，AI负责把意图转化为可执行代码。
再说灵活性。低代码平台往往受限于其预设的组件库，就像玩乐高——你能拼出很多造型，但终究受限于积木的形状。而Vibe Coding遵循“代码是能力，意图才是资产”的原则，你可以无限组合各种微程序，创造出前所未有的解决方案。
不过我得说句公道话，低代码平台在企业级管控、权限管理这些方面确实更成熟。这也是为什么我认为在未来相当长一段时间内，两者会共存甚至互补。Vibe Coding需要借鉴低代码在治理方面的经验，而低代码平台也需要融入更多AI能力。
说到这里，我想起Qgenius提出的一个观点：“人人编程，专业治理”。这或许就是未来的方向——Vibe Coding让每个人都能参与创造，而专业团队专注于制定标准、确保安全。这不正是我们一直追求的吗？
那么，回到最初的问题：Vibe Coding会取代低代码吗？我的看法是，就像电灯没有完全取代蜡烛一样，它们会找到各自最适合的场景。但不可否认的是，Vibe Coding代表的是更加根本的变革——从“如何编码”转向“想要什么”。
最后留个问题给大家思考：当AI能理解我们的意图并自动生成代码时，我们到底是在编程，还是在用另一种语言与机器对话？