很多团队第一次动念搭系统，起因都不宏大。某个业务组用表格维护一份清单，转发到第五个人手里时已经出现三个版本，于是有人说，不如做个系统。一周之后，一个能录单、能审批、能导出的小应用上线了。
这个过程里最容易被忽略的一点是：真正被省掉的不是敲代码的时间，而是“把话说明白”的往返。需求方描述一件他每天都在做的事，开发方要把它翻译成字段、状态和权限，翻译过程中总有损耗。可视化界面把这段翻译压到同一块屏幕上，损耗确实小了。很多团队引入低代码的契机也正在这里。
省掉的是翻译，不是判断
拖拽能压缩需求与实现之间的来回，却压缩不了另一件事：这个流程究竟该有几步，谁有权改状态，异常情况退回哪一层。这些判断在可视化界面里同样要做，只是做的人从工程师换成了业务方自己。以前这类含糊会被开发追问出来，现在没人追问，含糊就被直接搭进系统，上线后才在某个边界情况上暴露。
所以第一个务实的问题不是“能不能搭”，而是“想清楚了吗”。想不清楚的流程，换成界面搭建只会更快地变成一个想不清楚的系统。
代码债看得见，配置债看不见
低代码把一部分逻辑从代码搬进了配置。好处显而易见，代价是这些配置缺少代码那套习惯：没有版本对比，没有评审，少有注释。一个审批节点被谁在什么时候挪走，往往说不清。应用少的时候靠记忆还能维持；等到十几个应用互相读写同一批数据表，排查一个问题要先弄清是哪次改动引起的，事情就变味了。
这不是好坏问题，而是成本换了个位置。原来集中在一处、有人负责的复杂度，被摊到很多处、由不同的人随手处理。摊薄之后单点压力小了，整体却更难被看见。
哪些情形值得放慢一点
有几类场景需要谨慎：状态多且互相牵制，比如一张单据十几种状态、每种状态允许的操作都不同；需要与外部系统反复核对数据，对容错要求高；以及改动频繁、每次改动都要回溯历史的模块。这些地方硬用可视化去搭，前期确实快，后面每调一次都要重新理一遍全局。
还有一种更隐蔽的情况：搭建的人走了。搭建降低的是入门门槛，不是接手的门槛。由业务人员自己搭起来的应用，结构往往贴合他本人的思路，换个人来看，字段命名、流程分叉都得重新猜一遍。
躲不掉的那部分
工具能解决的是动手门槛，解决不了的是秩序。真要长期用下去，有几件事得有人管：
- 命名和字段含义有统一约定，否则半年后没人说得清“状态2”指什么；
- 每个应用有明确的归属人，废弃的要能下线，不然数据表会越积越多；
- 关键流程的改动留个痕，哪怕只是记一行字，也强过全凭回忆。
这些事听起来琐碎，却决定了一个团队是把工具用成资产，还是用成新的历史包袱。低代码真正考验的，是组织愿不愿意把“谁能改、改了什么”当回事。门槛降下来之后，剩下那张清单，还得人自己写。