设想这样一个场景。业务同事想把一张表单的审批从三级改成两级，提需求、排期、等开发，两周过去流程还是老样子。后来有人在一个可视化平台上拖了几下，半天就跑通了。当天皆大欢喜。麻烦通常从第二天开始。
省下来的时间并没有消失
把搭建周期从两周压到半天，是低代码最容易被看见的那部分。界面拖拽、字段配置、流程连线，确实不必逐行写代码。可一个流程上线之后要面对的事情一件没少：字段口径谁来定，历史数据怎么迁，权限开到哪一层，改坏了怎么退回。这些工作不会因为界面上没有代码而消失，只是从开发人员手里，转移到提出需求的人手里。
这不算坏事，但需要说清楚。以前业务方只需描述“我想要什么”，剩下的翻译工作由工程师完成；现在翻译这一步被部分交回业务方，而他未必受过这种训练。于是常见的结果是：应用搭出来了，逻辑却是含糊的，等用的人多了，含糊的地方就开始出问题。
适合与不适合的分界
判断一个需求该不该交给低代码，我更愿意看两个维度：变化频率，和出错代价。
- 规则简单但改动频繁的内部流程，比如登记、审批、信息收集，值得一试。改一次的成本低，试错也不心疼。
- 参与人数有限、并发不高的工具型应用，同样合适。用完即弃的小系统，本来也不值得走完整开发流程。
- 反过来，牵涉核心数据、需要严格审计留痕、与多个系统深度对接的部分，交给它就要谨慎。不是做不到，而是排查问题时会更费劲。
这条线不是技术能力划出来的，而是责任划出来的。出错的代价越高，越需要有人能完整说清系统里发生了什么。
越容易搭建，越容易散落
低代码降低了创建的门槛，也就降低了重复创建的门槛。同一个需求，三个部门各搭一套，字段还不太一样，这种事在有平台之前就发生过，有了平台只会更快。等要合并数据的时候，才发现没人说得清哪套是准的。
所以治理的关键不在于限制谁能用，而在于留一个能被找到的入口：谁建的、给谁用、数据从哪来、不用了归谁管。这几行信息比工具选型重要得多。
回到开头那个场景。拖几下就能跑通，这件事本身是有价值的，它让一个想法在一天内被验证，而不是在两周后被告知排不上。但低代码真正改变的，是谁来完成搭建，而不是搭建这件事有多少工作量。它把一部分判断权交出去，也就要求拿回判断权的人能把话说清楚——需求是什么，边界在哪，坏了谁来收。这一关过不去，省下的时间迟早会在别处补回来。