市场部的人用两周时间拖出一个活动报名页，表单、审批、通知都能跑通；半年后他调了岗，页面还在收数据，只是那条自动提醒为什么总在周三凌晨发出去，已经没人说得清。这一幕在不少公司重复上演，问题不在工具本身，而在于交接的责任没有记录清楚。
省下来的到底是哪一段
低代码做的事，说到底是把界面、表单、流程、权限、数据表这些重复度高的部分抽象成配置，运行时由引擎去解释。它减少的是“把需求翻译成代码”这段的手工量。它并不减少“把需求想清楚”这一段。恰恰相反，因为动手成本低了，很多人会跳过这一步直接开始拖拽，把没想明白的地方留在流程分支里。
所以经常出现的反差是：搭建只花三天，改起来花三周。原因在于最初那版结构是边走边定的，字段命名随手写，流程节点按当时的口头约定连，等到业务变化，改一个状态要顺着七八条线从头到尾理清。
权限下放之后，责任要跟上
低代码真正的变化并不在技术，而在开发权的分配。以前业务部门提需求，IT 排期；现在业务部门自己就能上线一个工具。好处很明显，代价是原本集中在技术团队的那套隐性纪律，包括版本、命名、测试、下线，被削弱了。
比较务实的做法是把这几件事变成硬性动作：每个应用必须有明确的归属人，不只是创建者；上线前登记用途和所依赖的数据源；设一个复核周期，到期没人认领就进入待下线状态。听起来像行政手续，但它决定了两年后这些东西是可维护的资产，还是没人敢动的黑箱。
有些东西不该往里塞
配置的表达力是有上限的。逻辑分支不多、生命周期短、参与人数有限的内部工具，用它很划算。但一旦碰上几类情况，就要谨慎：需要跨系统保证数据一致的流程；状态机复杂到分支互相嵌套的审批；对性能和审计留痕有硬性要求的场景。这些地方硬用配置去凑，最后往往靠脚本和插件绕过去，绕完之后既不规范，也没人看得懂。
- 先问清楚这个工具打算活多久，半年就废的东西不值得精细设计；
- 字段和流程的命名一次定好，改名的成本远高于当初多想五分钟；
- 把数据出口想清楚，报表和导出往往比录入更早暴露结构问题。
低代码本身不会让系统变乱，它只是把决定权交到了更靠近业务的人手里。交出去之后能不能守住基本的工程习惯，才是这类工具在一个组织里能不能长久用下去的分界线。