一个部门想要一个“提交—审批—归档”的小工具，过去要排期，现在有人下午拖出表单、连上审批节点，第二天就能用。变化是真的。几周后再看，这个工具往往还在跑，只是没人说得清它的字段为什么是这些，也没人说得清谁有权改。
省下来的时间，转移到哪里了
低代码最容易被误解的地方，是把它当成“写得更快的代码”。它确实能压缩界面搭建的时间，但界面从来不是这类需求里最贵的部分。真正耗时的是搞清楚业务到底要什么：谁提单、卡在哪一步、异常怎么退回、数据最后落在哪。
它的价值更像把讨论提前。因为拖拽便宜，业务方愿意先做一个能跑的东西，再拿着它去改。以前要先写需求文档，现在对着屏幕说“这里不对”。省下的不是开发工时，是来回确认的轮次。
麻烦通常在看不见的地方
表单、流程、权限、集成——这四件事里，前两项被平台包得越来越好，后两项才是真正考验人的部分。一个内部工具要接组织架构、要读历史数据、要在人员离岗时收回权限，这些往往没有现成的积木。
- 集成：对方系统没有开放接口，或者有接口但没人愿意给你开。
- 权限：谁能看全部、谁只能看自己那条，规则一多就变成需要专门维护的东西。
- 生命周期：临时工具没人认领，最后既不敢删也不敢改。
所以常见的情况是，第一版很快，第二版开始变慢，第三版又要回到研发手里。这不说明工具不行，只说明复杂度没有消失，只是往后移了。
它适合什么，不适合什么
我的判断比较朴素：逻辑简单、变化频繁、使用者有限、出错代价可控的内部工具，适合交给业务侧自己做。反过来，涉及大量计算、高并发、外部用户、需要留痕审计的场景，还是应该走正规研发流程。判断标准不是“能不能搭出来”，而是“出问题时谁来兜”。
这里有个容易被忽略的成本：治理。当十几个部门各自搭了表单，命名五花八门，同一个“客户名称”有三种写法，汇总口径就开始打架。低代码降低的是创造的门槛，并没有降低收尾的门槛。谁负责命名规范，谁定期清理不再使用的应用，这些问题在试点阶段不显眼，规模一上来就会变成日常摩擦。
一件可以先做的小事
如果准备引入，不妨先定几件小事：每个应用登记负责人和用途，字段命名走一套最简单的规则，使用范围超出预期的转交研发评估。这些规则写下来不超过一页，但能省掉后面很多解释。
工具终究只是工具。它缩短了从想法到可用的距离，也把“该不该做”这个问题更早地推到了台前。以前这个问题被排期掩盖了，现在它藏不住了。