一张内部表格用了两年，字段从十几个长到几十个，审批还散在群消息里。有人提议：用低代码搭个工具，把登记、流转和查询收在一起。演示通常很顺，拖表单、连流程、配权限，半天就能跑通。可真正上线几周后，问题往往不在“能不能搭”，而在“搭完谁来管”。
低代码把搭建入口往前移了一截。业务人员能直接表达流程，IT 不必从每个页面写起，转而处理数据模型、接口和边界。这个变化本身有吸引力，但也容易让人误判：看见的是拖拽，没看见的是约束。
拖拽之外，先看四个容易被低估的地方
- 数据模型。字段可以随手加，报表和历史记录却未必跟得上。命名、类型和关联关系一旦松散，后面清洗成本会上升。
- 权限。配置权限看起来只是勾选，组织调整后却可能留下隐性入口。谁创建、谁审批、谁导出，需要在搭建时就写清楚。
- 版本。流程能跑通，不等于能回滚。修改频繁的应用，至少要留下变更记录和恢复路径。
- 系统衔接。接口、字段映射、异常处理常被低估，这部分仍需要工程判断。
这些点不复杂，却决定了应用能不能长期用。低代码适合变更频繁、逻辑相对直白、参与人数有限的场景；碰到关键数据、复杂计算或外部系统较多时，仍要有传统开发兜底。判断依据不是工具强弱，而是变更成本和出错代价。
把它当作协作界面
我更愿意把它看成业务与 IT 之间的协作界面：业务把规则讲清楚，IT 把约束做扎实。上线前问几个笨问题——数据从哪来、谁能改、出错怎么退回、应用不用了谁负责关掉——往往比多做几页培训有用。模板库、命名规范、上线评审、权限回收，这些看似琐碎的规则，才是低代码不变成新孤岛的前提。
所以，低代码的价值不在让所有人都变成开发者，而在让需求更早暴露，减少业务与技术之间的来回翻译。若只追求搭建速度，忽略数据与运维习惯，工具很快会制造新的清理工作。真正值得投入的，是模型设计和治理耐心，而不是演示时那几下拖拽。