3. 低代码阵营分两条路
低代码这个概念一出来，市场上就冒出了各种形态的'低代码平台'，有的像Excel加工作流，有的像可视化开发环境。很多人纠结于功能对比，但真正决定选型的，是这些平台想解决的根本问题不一样——你到底是想快速出活，还是想让系统能长期改下去？
Forrester 把低代码平台分成了两类：
- 面向业务开发者（LCDP for Business Developers）
- 面向专业开发者（LCDP for Professional Developers）
注意，这里的'业务'和'专业'不是指写代码的技能高低，而是他们在组织里的角色和负责的边界不同。这种差异，直接带来了两种完全不同的价值取向。
3.1 面向业务开发者：图个快，别算长远账
这类平台通常就是表单驱动，把数据和逻辑揉在一起，衍生自 ERP、OA 里的可配置技术，用起来像在实施成品软件。市场上常叫它'无代码'。
业务开发者是谁？他们不归IT管，但自己动手给团队做个小系统用，类似 Gartner 说的平民开发者。在公司里，他们往往是流程负责人、业务负责人或者运营负责人。他们门儿清业务规则，但对长期技术维护既没责任也没动力。
所以，这类平台的出发点不是'构建一个可以不断演进的软件系统'，而是用最短路径把明确的业务目标变成能用的工具。在业务部门看来，软件价值就是：
- 当下问题解决了没？
- 能不能快速支撑一个管理动作？
- 短期内有没有看得见的效果？
说白了，这类平台的价值就是压低一次性投入成本和沟通摩擦，迅速出成果。
但问题是，一旦这些工具开始要跨部门协同、规则越搞越复杂、数据被反复引用时，隐性成本就冒头了：配置乱成了麻，治理跟不上；应用一大堆，数据互相不认；看起来产出很多'应用'，整体却越来越难维护。这不是平台不行，而是它生来就是为了压住显性成本，追求短期成果最大化，不负责长期演进。
3.2 面向专业开发者：把变化的长期成本算进来
与上面那类相反，面向专业开发者的低代码平台把数据和逻辑拆开，是模型驱动的，源于可视化开发技术的演进，有明确的开发态和运行态之分。通常被叫作'狭义低代码'。
这一类平台的价值起点不是更快交付某个应用，而是当你需要持续改动时，系统不至于乱掉。专业开发者不是技术多高超，而是因为他们向IT部门汇报，有动力也有责任让系统稳定、可扩展、安全、可维护。他们承担的，是系统负责人和技术治理者的角色。所以，他们衡量软件价值的天平，自然偏向成本：
- 每次业务变化，改动成本是不是可控？
- 系统越做越大，复杂度是不是线性增长？
- 换人接手，系统还理得清楚吗？
所以这类平台不试图隐藏复杂性，而是用适度的工程抽象，把通用中间件和规范内建进去，把重复出现的结构固化为模型和约束，让变化的影响范围落到可控边界内。
它存在的目的不是消灭代码，而是降低长期变化的成本，持续提升IT团队的产出能力。通过重构生产方式，让系统在持续变化中还能保持结构稳定，支撑真正的可持续演进。
代价呢，就是对企业提出了更高的前置要求，我把它概括成四个前提。
前提一：开发者必须愿意持续学习平台抽象
和业务开发者的低代码不同，这里的平台不会把复杂性藏起来。相反，它会通过模型、约束和规范把复杂性重新暴露出来让你管理。开发者得理解这些抽象背后的设计道理，才能在变化发生时用对平台能力，而不是绕道走。低代码在这里更像一门新的工程语言。如果团队光想着用它写更快，而不愿花时间弄懂架构思想和治理边界，那所谓的长期成本优势根本兑现不了。
前提二：企业得有技术治理的意识和制度保障
因为这类平台的目标是控制长期成本，它一定会引入统一的数据模型、服务边界、权限体系和扩展规范。但这些不会自动生效，得靠制度、流程和角色分工落地，比如：
- 哪些能力用内建模型实现，哪些走扩展
- 限制跨系统、跨模块的依赖方式，避免隐性耦合
- 关键模型和服务的变更有评审和演进规则
如果企业还是'项目做完就散伙'，没有对系统整体结构的长期治理，那平台的工程抽象很快就会被侵蚀，退化成另一种快速堆砌。
前提三：不适合完全去中心化的开发模式
平台强调结构稳定和可持续演进，就必须有人对系统整体负责。这要求企业至少在核心系统层面，保留架构责任和平台责任的角色，不能把所有开发彻底下沉、完全分散。如果组织内部对统一技术路线和长期架构约束有抵触，那这类低代码的优势就很难发挥，还会被抱怨'限制灵活性'。
