见过一个部门用几周时间把一件杂事搬到了线上：字段自己加，分支自己画，提醒文案改了三版。上线那天没人庆功，因为这本就不值得庆功。工具退到背景里，事情照常往前走——这大概是低代码比较理想的形态。
但也见过另一种场面：半年后同一个入口下堆着不少流程，有两条同名不同用，原搭建人已经调岗，没人说得清哪条还在跑。同一类工具，两种结局，差别不在工具本身。
省下来的往往不是敲代码的时间
把需求讲清楚、等排期、评审、返工，这一串来回常常比写代码本身更长。业务方自己拖拽，省掉的是翻译环节：脑子里那套流程直接变成界面，不用先翻译成文档、再翻译成代码。代价是，原先由开发者在评审里顺手挡掉的问题——这个字段该不该这么设计、异常分支要不要留口子——现在没人挡了。
所以速度提升是真的，粗糙也是真的。前面快，后面补。
难度没有消失，只是换了位置
一个看起来像表单的东西，往往是个小系统。权限分几层、历史记录留多久、和别的系统怎么对账、两个人同时改一条数据会怎样，这些不会因为界面是拖出来的就自动解决。低代码把常见路径铺平了，把边角留给了使用者。而边角恰恰是最费时间的地方。
更微妙的是，配置出来的逻辑不像代码那样容易被读。代码可以搜索、可以比对差异、可以交给下一个人；配置藏在页面里，改动没有注释，出问题时只能一层层点开去看。这不是工具的错，但它确实改变了排障的成本结构。
它后来归谁管
部门自己搭的应用，天然带着一个缺口：搭建的人走了怎么办。这不是要否定业务自建，而是说，应用一旦承载了真实业务，它就带上了资产属性，需要有名字、有归属、有人定期清点。散落的表格和散落的应用本质上是一回事，只是后者更贵——它跑在服务器上，出错时会波及别人。
比较务实的做法，是把几个问题放在上线之前问，而不是事后追查：谁负责、数据从哪来、坏了找谁。答案通常不复杂，复杂的是没人问。
适用与不适用
- 适合：内部使用、并发不高、规则经常调整、以表单和流程为主的事。
- 适合：补上已有系统之间的缝隙，做一层轻量的衔接。
- 不太适合：算得重、要求实时响应、与外部系统深度耦合的部分。
- 不太适合：需要长期演进、多人协作改动的核心系统。
把这些边界说清楚，比争论它能不能取代开发者更有意义。低代码改变的不是谁在写代码，而是从想法到可用工具之间的距离。距离缩短之后，考验转移到了别处：判断什么该做、什么不该做，以及做完之后，愿不愿意一直养着它。