业务同事把一个审批页面投到屏幕上，说需求已经画好了，只等系统里搭出来。这样的场景让低代码显得很顺手：拖几个字段，连两条流程，页面上线。可等到三个月后再看，字段名变了，审批人多了一个，原先的权限规则还藏在某个配置项里。问题不是能不能搭出来，而是搭出来之后谁来读懂它。
快，不等于轻
低代码擅长把表单、流程、列表这类重复劳动压缩成配置。它的价值在交付速度上很容易被看见，但代价往往延后出现：业务逻辑散落在页面、流程和脚本之间，数据模型没有文档，权限按当时的组织关系临时设定。交付时省下的沟通，可能变成维护时的猜测。
我倾向于把它看成一种“可视化编程”，而不是“无需编程”。可视化只是把代码换了一种存放方式。字段类型、关联关系、校验条件、状态流转，仍然需要有人负责。若团队把它当成任何人都能随手改的工具，配置就会像没人整理的表格一样，越叠越厚。
真正的工作量在交付之后
一个应用上线后，变化通常来自三处：组织结构调整、业务流程分叉、数据口径修订。低代码平台如果只提供拖拽界面，却不提供可读的模型视图和变更记录，维护就会变得依赖少数熟悉配置的人。这里的关键不是功能多少，而是可追溯性：谁改过哪条规则，为什么改，能否回退。
权限也值得单独看。表单字段和审批节点一旦与角色绑定，权限就不再是页面上勾选几下那么简单。需要有人定期核对：哪些角色能看到哪些数据，离职或转岗后权限是否回收，临时开放的入口有没有关闭。平台降低了搭建门槛，但没有自动降低治理门槛。
把它当胶水，而不是地基
我的判断是，这类工具适合承接变化频繁、逻辑相对简单的协作场景，比如内部信息收集、轻量审批、状态跟踪。它不太适合承载复杂的核心业务或强监管流程，除非团队愿意为模型设计、测试和审计投入专门的人手。边界清楚，工具才不会被过度期待。
在落地时，可以先问几个具体问题：
- 这个应用的数据结构能否用几句话讲清楚？
- 变更时能否找到责任人，并留下可回看的记录？
- 权限规则是否独立于个人，而不是靠口头约定？
- 如果平台更换，数据能否完整导出？
这些问题不花哨，却决定了一个低代码应用能不能在交付之后继续被维护。工具可以加快搭建，但理解业务、设计模型、管理权限，仍然要由人完成。把它放在合适的位置，它才是省力的胶水；放错了位置，就会变成另一张等待清理的表。