有位做运营的同事，用低代码平台搭了一张活动报名表。两个下午做完，比走技术排期快得多。半年后再看，同类的表单一共有十几张，名字相近，字段略有出入，有的还在收数据，有的已经很久没人打开。谁也说不清哪一张是准的。
这不是低代码带来的新问题，但它让问题发生得更快。写代码要立项、评审、排期，这些环节本身就是减速带；拖拽搭建几乎不需要许可，试错成本被压得很低，被一起压低的还有“随手留下一个应用”的成本。
配置也是代码，只是不太像
可视化搭建的底层通常是元数据驱动：页面上拖的每个字段、每条规则，最终都以配置的形式存下来，保存即生效。它省掉了编译和发布，也顺带省掉了很多原本附在发布流程上的东西——版本记录、变更评审、回滚方案。
代码出问题会报错，会留下堆栈；配置出问题往往不报错，只是慢慢地不对。一个必填项被取消，一条审批路径被改动，界面上看不出痕迹，要等到某天有人问“这个单子为什么没走到下一环”，才被发现。
快，是先借后还
低代码真正的考验不在第一次搭建，而在第三次、第五次修改。如果每次调整都要绕开原有逻辑打补丁，最初省下的时间会在几个月内被逐步还回去。判断一个应用健不健康，有个朴素的办法：让没参与搭建的人改动其中一个环节，看他要花多久弄明白。
- 归属：每个应用应有明确负责人，而不是“当时是谁搭的”
- 口径：同一个字段在不同表单里含义要一致，否则汇总时对不上
- 权限：搭建者的权限，不等于使用者的权限
- 下线：比上线更需要机制，废弃的应用要及时说明状态
它擅长什么，不擅长什么
流程清晰、参与方不多、变化频繁的内部工具，是这类平台比较自然的落点。反过来，业务规则错综复杂、对一致性要求高、需要深度性能优化的场景，靠配置堆出来的东西迟早会碰到天花板。判断标准不是“能不能搭出来”，而是“出问题时，有没有人能在半小时内定位到原因”。
所以，选平台之前，或许更该先回答一个更笨的问题：这张表半年后归谁管。低代码并没有让人不用思考系统，只是把思考的位置从写代码挪到了设计与治理上。挪过去的那部分，才是真正决定它能不能长久用下去的地方。