可以替代一部分，但边界必须提前讲清楚，否则省下的时间会以返工的方式还回来。
我们不反对低代码，恰恰相反，我们在几个项目里主动用它做内部工具。问题从来不是「能不能用」，而是「用到哪里为止」。
表单驱动、流程固定、用户量在几十人以内、生命周期预期的内部工具，用低代码的交付速度可以做到定制开发的三到五倍。这类需求过去常常因为「不值得开发」而被搁置，低代码让它们第一次变得经济可行。
在我们的项目里，审批流、数据看板与运营后台的一部分模块都是这样交付的，客户满意度并不比定制模块低。
面向外部用户、并发不可控的场景，性能与成本会很快失控。
低代码的优势是快，代价是改起来同样快。流程每周都在变的业务，反而更需要结构化的模型层。
三年以上的核心系统，要考虑平台锁定、迁移成本与人才供给，而不只是首年交付速度。
另外两个问题是：平台宕机或涨价时的应对方案，以及当需求超出平台能力时的迁移路径。这三个问题的答案，比任何功能对比表都更值得写进合同。
问「能不能导出数据与逻辑」比问「能不能做这个页面」重要得多。前者决定你三年后还有没有选择权。
低代码与定制开发不是替代关系，而是分工关系。真正需要避免的是：用低代码快速做出一个将来必须重写的东西，却事先没人说过这一点。
告诉我们所在行业与业务阶段，我们提供对应的交付路径与周期参考。
