一张报销单要加一栏「项目编号」，提交给IT，排期三周。业务方等不及，先用共享表格顶着，两个版本并行跑了一个月。这种事在多数公司一年会发生几十次，每一次都不大，每一次都要等。
低代码被引进来，多数时候就是冲着这个等待。它的动作其实很朴素：把表单、列表、审批流、权限这些反复出现的东西做成可配置的块，让懂业务的人自己拼起来。省掉的与其说是写代码的力气，不如说是在需求方和开发方之间来回折返的那几趟翻译。
被压掉的那段路
传统开发里，业务方说的话要经过需求文档、原型、评审，才落成代码。每一层都在翻译，也都在丢信息，但也每一层都有人在追问：这个字段为空时怎么办，驳回是回上一节点还是回发起人。这些问题烦人，却把模糊处磨清楚了。
低代码把这几个环节压到一起，链路短了，副作用是那些追问也一起消失了。配置的人自己拍了个默认值，当时觉得没问题，三个月后对账时才发现不对。
真正的工作量在哪
拖拽本身不花时间。花时间的是：这条流程有几个分支、谁在什么条件下能改数据、跨部门取数算谁的口径、报表和台账对不对得上。这些问题跟工具无关，跟组织有没有想清楚有关。
常见的卡点也在这里：平台搭起来了，第一个应用做完，第二个就没人管。最初动手的人调了岗，配置逻辑只留在他脑子里，后来者不敢动，只好另起一套。工具没坏，是没人接住。
谁有权改，比能不能改更要紧
配置权限一旦铺开，很快会长出一批没登记的内部工具。它们不在IT的资产清单上，手里却握着真实数据。出问题时找不到负责人，审计时说不清口径，这类麻烦比开发排期难处理得多。
可行的做法并不复杂，且大多是管理动作：把应用当资产登记，写清归属人和停用条件；关键字段的变更留痕；跨部门取数走统一接口，而不是各自连库。技术上都不难，难的是有人愿意认这笔账。
它舒服的地带，和不该硬塞的地方
表单流转、内部台账、轻量审批、临时统计，这些场景变化快、用户少、容错高，是低代码舒服的地带。反过来，高并发、强一致、复杂算法、对外服务，硬塞进去只是把复杂度挪到更难排查的位置，省下的时间会在排查故障时加倍还回去。
判断标准可以很简单：如果这个应用坏了，多久能被发现，会影响多少人。答案含糊的，先别放上去。
所以我不太认同把这类工具说成「人人都是开发者」。它真正改变的，是需求提出方的责任位置——把「说清楚」这件事退回到离业务最近的人手上。这是好事，但要有心理准备：省下的沟通时间，会以另一种形式回来找你。