业务会上常见一种错位：流程刚讨论完，需求文档还没定稿，一线已经换了做法。此时有人提起低代码，语气里往往带着两层期待——快点上线，顺便少麻烦技术团队。这个期待不算错，但需要拆开看。
它吸引人的地方并不神秘。表单、审批、列表、权限和简单联动，重复度高，用拖拽和配置先搭出骨架，能让懂业务的人先把路径跑通。省下的常常是沟通和等待，不一定是思考。需求里那些含糊的例外，配置界面不会替你问清楚。
它更像一层“可调整的中间层”
如果把企业系统粗粗分开，一边是稳定而核心的业务记录，一边是变化快、但逻辑不深的协作流程。低代码比较适合夹在中间：不直接替代核心系统，也不要求每个小流程都排进长队。它把一部分应用搭建权下放到离业务更近的人手里，同时保留技术团队对账号、数据和发布的看管。
但“中间层”也有代价。配置出来的应用同样要面对版本、权限、数据质量和后续维护。搭得快，不代表改得轻松。一个表单字段今天加、明天删，后面牵动的可能是报表口径、接口映射和审计记录。若没有基本的命名约定、变更记录和责任人，配置化会把技术债从代码仓库搬到配置后台，只是更难被看见。
边界通常出现在三个地方
规则复杂度先冒出来。流程里充满例外、回退、跨部门协商和频繁变化的计算，配置图会迅速变成一张难读的网。数据一致性紧随其后。应用一旦要同时写多个系统，或对同一笔记录做并发处理，问题就不再是页面好不好搭，而是谁说了算。长期维护则更隐蔽。临时应用被用成日常系统后，原先的搭建者调岗，后来的人面对一堆字段和自动化规则，未必比读代码轻松。
所以，这类平台进入企业时，真正该先定的不是“哪些部门能用”，而是“哪些场景可以先试、哪些必须走常规研发”。可以把内部登记、轻量审批、信息收集这类低风险流程放进去，给它们明确的试用期和退出机制；涉及关键主数据、对外服务和高频写入的部分，仍应谨慎。这个分界不必一刀切，但需要写下来，并随着使用情况调整。
还有个容易被忽略的角色：平台管理员。他未必写业务逻辑，却要管权限边界、环境隔离、模板复用和废弃应用清理。没有这个角色，平台很容易从“业务自助”滑向“谁都能改、谁都不负责”。
回到开头那个时刻。低代码能接住的，是那些业务比文档快半步、但又没复杂到必须重做一套核心系统的场景。它接不住的，是把模糊需求直接变成可运行系统的幻想。工具把搭建门槛降下来了，判断门槛还在。真正省时间的做法，可能是在动手前多问一句：这个流程的例外，究竟由谁来决定？