见过几次这样的情形：一个部门用低代码搭了套表单，上线时大家说好，三个月后再问，填写的人还在，走流程的人没了。表单躺在系统里，审批又回到群里喊一声。搭的时候很快，用的时候很慢。
这件事值得说清楚，因为关于低代码的讨论常常停在“快”上，好像拖拽几下就能把管理问题一并解决。实际不是。
省下的是搭建时间，不是达成一致的时间
低代码压缩的是“把想法变成一个能点开的界面”这段距离。以前要排期、要开发、要对齐接口，现在一个人一个下午能做出原型。这段压缩是真实的，也确实有用。
但它没有压缩另一段：谁来决定这张表要填哪些字段，谁来批准，异常了找谁，两个部门对同一个字段的理解是否一样。这些问题跟工具无关，开会照样要开，争论照样要争。很多项目卡在这里，却被误以为是“系统不好用”。
所以评估它的价值，最好先看它被用来做什么。如果需求本身清晰、边界明确、只有一两个人在用，收益很直接。如果需求背后是几个部门的拉扯，那真正要设计的是流程本身，而不是工具。
它擅长的地方，往往不在舞台中央
低代码比较舒服的位置，是那些长尾的、临时的、变化快的内部工具：登记、盘点、巡检记录、活动报名、内部申请。这类需求零散，找研发排期不划算，交给业务自己搭反而合适。
不太舒服的位置也很清楚。核心交易链路、需要扛并发和精细性能调优的部分、权限模型复杂的系统，交给可视化配置往往会在后面付出更大的调试代价。另外，可视化搭出来的逻辑，读起来不像代码那样有清晰的调用链，改动的人一多，理解成本就上来了。
还有一个容易被忽略的点：搭建门槛降下来之后，系统数量会迅速增加。多本身不是问题，问题是没有人负责收尾。
真正难的是第二年
搭出来的东西会老。字段会加、流程会改、搭它的人可能调岗了。如果没有命名规范、没有责任人、没有停用的约定，两三年后你会面对一堆没人敢删、也没人说得清用途的表单。这种情况在传统开发里也会发生，只是在这里发生得更快。
所以用低代码，配套的东西得一起想：谁拥有这个应用，什么条件下它该被合并或停用，改动留不留记录。这些不是工具的职责，但它们决定了工具能不能长期待下去。
我对低代码的判断是中性的：它把“做出来”的门槛拉低了，但没有把“管好”的门槛拉低。把它当成万能解会失望；把它当成一把顺手的工具，让业务离自己的需求更近一点，倒是挺实在的。