低代码平台：一场精心包装的复杂性转移

低代码这几年火得离谱，随便一个CTO峰会都要喊几句“全民开发”。但我一直觉得哪里不对劲。大家吹的是“不用写代码了”“业务人员自己搭系统”，可实际上呢？我在上一家公司用钉钉宜搭做了一个库存管理模块，本来觉得挺美，拖拖拽拽两周搞定。结果上线第三周，财务说要按批次号自动匹配采购订单，宜搭那个逻辑配置里根本做不了这种多条件联动，搞了半天还是得请后端同事写了个接口把数据导出来，再用Python脚本处理完回填回去。那一刻我明白了，低代码没有消灭复杂性，它只是把复杂性从代码挪到了别处——挪到了配置逻辑、外部脚本和平台没覆盖到的边界上。

对比传统编码，低代码的“快”确实是存在的，尤其前端表单和审批流。但开发快不等于总成本低。传统代码虽然写起来慢，但一切都可控，出问题翻源码就能查。低代码呢？配置堆积成的业务逻辑散落在各种可视化界面里，没有版本控制，没有单元测试，甚至连个diff都做不了。我在另一个项目里用过OutSystems，它倒是能生成代码，也支持git，但那是企业级的价格，一年几十万，而且对开发者的要求并不低——你得懂他那一套自定义数据模型和生命周期钩子。说白了，低代码只是让“简单的事”变得更快，让“复杂的事”变得更复杂。平台为了易用而做的抽象，一旦遇到真实业务里的异常流程，就变成一层厚厚的胶水，你得用各种hack去绕过它。

我印象最深的一次，是在一家制造企业帮他们选型。IT经理说他们用微软Power Apps做了个质检报表，一开始挺好，后来业务部门要求跟ERP联动，还要回写审核状态。Power Apps连企业版Dynamics倒是方便，但他们的ERP是SAP R3，没有现成连接器，只能走自定义连接API。结果搞了三个月，最后发现Power Apps调SAP时每次token刷新都会超时，数据一多页面直接卡死。IT经理苦笑说，“我们用低代码省下的那点时间，全赔在跟平台打架上了。”那件事让我彻底改变了对低代码的看法：它适合那些业务场景相对固定、数据模型简单的内部工具；一旦牵扯到核心系统、复杂状态机或者高并发，低代码就是给自己挖坑。而且坑是隐性的，业务方只看到初始交付快，后面每次改动都要跟平台的能力较劲。

再说维护。传统代码有生命周期，有技术债一说，低代码的技术债更隐蔽也更危险。代码再烂，你能重构；低代码里的那些拖拽配置，很多供应商连迁移工具都不愿意好好做。今天用宜搭，明天想换到Mendix？那你就把几十个流程、权限模型、数据关系重画一遍吧，而且很可能画得还不一样。钉钉宜搭的数据模型绑定在钉钉组织架构上，离开钉钉你什么都不是。Mendix的微流向Java，但逻辑还是平台解释执行，跑不了离线。我的一个朋友在他们银行内部用低代码做了个信贷审批应用，结果审计要求提供逻辑变更记录，那个平台虽然能导出日志，但全是乱码，最后他们花了三周补文档。所以低代码不是没有技术债，而是债主变成了平台厂商，它哪天调整定价或者停服，你连哭都哭不出来。

但我也不是说低代码一无是处。它最适合的其实是“一次性”或“快速验证”的场景，比如给团队搭个内部预约系统、做一个临时的数据收集页面、或者给老系统包一层新界面。这些场景里，低代码的优势碾压传统开发。关键在于你别指望它替代专业开发，也别拿它去承载核心业务逻辑。我现在的原则很简单：如果这个流程三个月后还需要存在，且未来会改动三次以上，那我宁愿用代码写；如果它只活几周或者就是个表单收集，低代码随便整。你甚至可以混合用——用传统框架搭底座，用低代码做管理后台。这样既能保住核心系统的健康度，又能享受一点“拖动生成界面”的爽感。总之，低代码不是解药，也不是毒药，它就是一把剪刀。剪个包装袋很快，但你要用它拆墙，那就是你的问题了。