低代码是围城：进去的人想出来，外面的人还在仰望

我最初接触低代码是四年前，当时公司要快速做一个内部审批流，老板觉得招全栈太贵，拍板买了某国内头部低代码平台的企业版。第一个月确实爽，画流程图跟拼乐高似的，表单字段拖拽一下，按钮事件绑定个脚本，两周时间就上线了。当时我还发朋友圈感叹：程序员要失业了。

但到了第三个月，业务方开始提稀奇古怪的需求，要跟老系统做数据同步，要自定义打印模板，还要移动端适配。低代码平台里那些预置组件开始不够用了，我开始疯狂写自定义JS，甚至通过iframe嵌入了自己写的React页面才勉强搞定。那时候我才意识到，所谓“低代码”其实只是把简单场景的代码量降下来了，一旦遇到真正复杂的企业逻辑，它就变成了一台需要你拿着扳手硬撬的保险柜。

更头疼的是平台本身的升级节奏。某天他们发公告说底层框架要升级，部分老组件API废弃，我们线上三个应用差点挂掉。问题是这些应用根本不是我们主动升级的，而是平台自动灰度推送的。那一刻你会觉得自己不是在使用工具，而是被工具在暗处绑架了。后来我特意去翻合同，上面写着“平台方保留因技术演进调整功能的最终解释权”——好家伙，这词儿什么时候出现在过我们的风控条款里？

再说说“业务人员自己搭应用”这个最大的宣传点。我们公司确实有几个业务骨干被送去培训了，两周后他们能搭出像模像样的报表看板，但只要涉及跨模块的数据关联、权限校验、表单联动，他们就得乖乖回来找我们。最讽刺的是，有一次业务主管把流程配错了节点，导致报销款重复打给供应商，最后责任认定里写的是“流程设计者负主责”，可那位同事连代码仓库都没碰过。所以低代码并没有消灭“技术门槛”，它只是把门槛从“写代码”换成了“懂数据模型和逻辑闭环”，而后者的隐性难度其实一点也不低。

我个人现在的观点是：低代码是一个好的“脚手架”，但绝不是“建筑物本身”。如果你要做一次性活动页面、内部轻量管理工具、原型验证，它确实能帮你省下三倍时间。可如果你想让它承载核心业务系统，尤其是那种要存活五年以上的系统，我劝你认真评估一下“平台退出成本”——包括数据导出格式是否开放、API接口是否完整、是否支持私有化部署，以及最关键的：当平台涨价或者停止维护时，你的业务逻辑怎么迁移？我见过一家初创公司把整个CRM建在低代码平台上，后来平台被收购后立即涨价三倍，他们拿不出钱续费，只能连夜手动导出几千条客户记录，然后重新用传统代码撸了个简易版。那场面，跟逃难似的。

所以别把低代码神话成“技术的民主化”，它更像是技术权力的一次再分配——从程序员手里，分给了平台厂商和少部分懂业务的“假开发者”。如果你恰好是那个被迫只能使用低代码的开发者，请务必在项目启动前就写清楚风险评估文档，把“平台可用性”和“业务可用性”剥离开。如果你是个老板，也别指望让业务部门彻底自力更生，该养的技术团队还是得养，只是他们的工作重心从写增删改查变成了设计变量、配置权限、追着平台方修Bug。说到底，工具没有原罪，盲目的信仰才是。