不少团队第一次认真考虑低代码，起因都挺朴素：某个业务部门等不起排期。一张登记表、一条审批流、一个用来对账的台账，需求本身不复杂，但走完提报、评审、排期的流程，时间就过去了。于是有人提了一句，这类东西能不能让业务自己搭。
这个念头很自然。问题在于，接下来发生的事往往和预期不一样。
拖拽能解决表达，却解决不了理解
产品演示里，拖动几个控件、连两条线、配一个条件分支，一个能跑的页面就出来了。看的人会觉得，门槛确实低了。但真正卡住人的从来不是写代码本身，而是“这件事到底该怎么运转”：谁发起、什么条件下流转、异常了退回到哪一步、两个部门对同一个字段的理解是否一致。
代码只是把这些约定固定下来。如果约定本身模糊，工具再顺手，也只是把模糊做得更快。一些内部系统上线后没人用，回头查原因，几乎都不是界面难看或功能缺失，而是流程设计和实际干活的方式对不上。
瓶颈只是搬了个地方
低代码把“实现”的成本压下来之后，压力会转移到别处：需求梳理、字段口径、权限划分、上线后的变更管理。以前这些环节被开发的排期挡在后面，问题暴露得慢；现在业务自己动手，一周能搭出三版，分歧也就跟着提前浮上来。
这未必是坏事。但如果引入这类工具的同时不把“谁说了算”讲清楚，很快会出现一批各自为政的小应用。数据口径不统一，同一个客户在两个表里状态不同，报表对不上，最后还是回到人工核对。
几个月之后的东西归谁
搭建当天是愉快的。麻烦通常在几个月后出现：最初的人调岗了，字段加了两轮，条件分支叠了五六层，没人说得清某条规则为什么在那儿。这时候再想改，成本不比重新开发低多少。
所以真正需要提前想的是治理，而不是功能清单。可以留意这几件事：
- 哪些场景适合业务自建，哪些必须走正式研发流程，边界写清楚；
- 应用从谁名下创建、由谁接手维护，责任要落到具体角色；
- 关键字段的口径统一维护，不要每个应用各定义一套；
- 定期清理不再使用的应用，避免无人维护的系统越积越多。
它适合什么，不适合什么
边界感比热情更重要。流程清晰、变化频繁、参与人数有限的内部工具，是低代码比较舒服的地带：需求方自己最懂流程，改起来也快。反过来，涉及高并发、复杂算法、强一致性要求，或者要长期演进成核心业务系统的东西，交给它多半会后悔。
还有一类场景容易被忽略：跨部门、口径分歧大的需求。它们表面上是技术问题，实质是协调问题，工具帮不上忙，反而会因为“谁都能改”而让分歧更难收敛。
我倾向于把低代码看成一种把决策权前移的方式，而不是省人力的手段。它让“能不能做”变得容易，也就把“该不该做、按什么标准做”推到了前台。这两件事，工具不负责回答。