先看一个很常见的场景：有人想把纸质巡检记录搬到线上，字段清楚，流程也不复杂。按过去的做法，要先提需求、排期、等开发；现在，业务同事打开低代码平台，拖几个输入框，配一条审批路径，很快就能跑通。问题也从“能不能做”变成“做出来之后谁来管”。
低代码省下的，是起步阶段的搭建动作。它把页面、表单、流程这些重复劳动收进可视化界面，让懂业务的人先做出可讨论的东西。但省下的时间并没有消失，它往往转移到另外几件事上。
先被省掉的，是“把想法说清楚”之前的等待
需求在邮件和会议里来回描述，容易失真。这类工具让业务人员先搭一个粗页面，字段对不对、审批节点顺不顺，一眼能看见。这个变化看似只是快，实质是把讨论对象从抽象描述换成了可点击的草稿。它也有代价：草稿太容易生成，容易让人误以为需求已经明确。真正的澄清仍要发生，只是从“等开发做出来再改”提前到了“搭之前先想”。
接下来冒出来的，是权限、口径和维护
一个表单能填，不等于一个系统能长期用。谁能看、谁能改、离职后账号怎么处理，这些问题在演示时常常被跳过；数据字段叫同一个名字，含义却可能在不同页面里不一致；流程跑顺后，谁来处理异常单、谁来清理重复记录，也不会因为工具简单就自动消失。可视化搭建降低的是构建门槛，并没有同步降低治理门槛。
- 权限设计要在搭建时一并考虑，而不是上线后补。
- 数据口径需要有人负责解释，避免同一字段多种含义。
- 维护责任要提前落到具体角色，否则应用越多，问询越散。
这也是这类工具常被误解的地方。它像一张显影纸，把组织里原本模糊的分工照出来：业务能搭页面，但未必愿意承担后续维护；IT能管账号，但未必清楚每个字段的业务含义。工具没有替人做决定，只是让决定来得更早。
所以，边界不在“能不能搭”，而在“停在哪一步”
我的判断是，低代码适合承接那些边界清楚、变化频繁、参与人数有限的内部小应用：资料收集、简单审批、状态登记、轻量台账。它们不必进入核心系统，却长期消耗沟通成本，先搭出来能减少来回。反之，涉及复杂权限、跨系统数据一致性、长期追溯要求的场景，单靠拖拽容易留下隐性负担。此时这类工具可以作为原型，帮助把问题暴露清楚，再决定是否进入正式开发。
回到开头那张巡检表。真正值得关心的，不是它很快搭出来，而是一段时间后还有没有人敢改字段、出了问题能不能找到责任人。这类工具省下的时间，最后都去了这些地方。承认这一点，才不至于把它当成万能钥匙。