很多团队里都有这样一幕：一个没写过程序的运营同事，花两个下午在低代码平台上搭出一个内部报名页。表单、字段校验、列表页、导出按钮，拖拽加配置，跑起来了，也确实能用。
这大概是低代码最容易被看见的部分——它把“写代码”这一层抽掉了。以前要做出一个能填数据的东西，至少得有人搭环境、写接口、连数据库；现在这些被预先封装成模块，剩下的工作是选字段、定必填、想清楚谁可以看哪一行。
被省掉的，和被提前的
值得琢磨的是，省下来的时间不一定等于省下的时间。传统开发里，很多决定是被迫延后的：先跑通再说，权限以后再补，异常分支以后再想。低代码把动手的门槛降得很低，这些决定反而被推到了前面——你得在建表那一刻就想清楚，这条记录属于谁、能不能被改、删掉之后关联数据怎么办。
换句话说，工具削掉的是语法，不是建模。一个人如果不习惯把流程拆成状态和数据，拖拽并不会替他完成这件事，只会让混乱更快地长出来。
它的边界比想象中清楚
用久了会发现，低代码擅长的场景有个共同点：结构稳定、参与角色有限、逻辑以“录入—流转—查看”为主。审批流、内部台账、活动页、数据收集，大致落在这个范围里。
它不太舒服的地方也很集中：
- 需要高频对接外部系统，而对方接口并不规范；
- 业务规则大量是长尾特例，每一条都“只出现一次”；
- 对性能敏感，或数据量大到需要认真设计索引；
- 后期要交给专业团队接管，而平台生成的产物难以迁移。
这些谈不上缺陷，更像是任何一层抽象都要付的代价。抽象抬得越高，覆盖常见情况越快，遇到非常规情况时回旋余地就越小。
真正要问的几个问题
所以判断要不要用，与其问“能不能做出来”，不如问三个更具体的问题：这东西的生命周期有多长，半年后还有没有人维护；出问题时，谁能看懂它是怎么运转的；以及，如果哪天要把它拆掉重来，数据能不能完整带走。
第三个问题常被忽略，却最实际。这类平台通常自成一套运行环境，业务数据在表里，但让它运转的那套配置、流程定义、页面逻辑，往往是平台私有的。迁移成本不会在搭建时显现，而是在你想离开的时候。
我并不觉得这是劝退的理由。对大量“必须有、却不值得专门组队开发”的内部需求来说，用低代码把它做出来，胜过让它在需求列表里躺上一年。只是需要有人在一开始就承认：这是一次取舍明确的选择，并非一次免费的加速。