孙玲的空间1. 低代码平台的隐痛：表单驱动为什么"能入门、难深入"
前阵子和一个创业团队聊他们的低代码平台，对方技术负责人随口说了句："我们这产品客户用着还行，但凡是遇到跨部门的核心业务系统，基本都得定制开发兜底。"
这句话我太熟悉了。过去几年里，我在不同场合反复听到类似的表述——不是产品功能不够多，而是整套架构在设计起点上就分出了高下。今天想借"表单驱动"和"模型驱动"这两个词，把这层窗户纸捅破。
1.1 表单驱动架构的运作逻辑
先用最简单的方式说清楚表单驱动是什么。
市面上大部分低代码平台，尤其是国内早期的那批，核心抽象单元是"表单"。你新建一个"请假申请单"，往表单里拖几个字段：请假人、开始时间、结束时间、请假事由。然后配一个审批流程：部门经理审批、人事备案。平台做的事情是：把这张表单的字段定义、布局规则、校验逻辑打包成一个JSON配置文件，运行时由引擎解释执行，再配一套流程引擎在多个表单之间传递单据状态。
这套思路的优点是显而易见的——门槛极低。业务人员经过半小时培训，就能像个"高级Excel用户"一样搭出能用的东西。一个小部门的台账系统、一个几十人用的内部申请流程，用表单驱动两三天就能上线，效率和传统开发完全不在一个量级。
但问题也恰恰藏在这里。
1.2 表单驱动的三个典型瓶颈
我在实际项目里观察下来，表单驱动架构在以下三个场景里会连续撞墙。
瓶颈一：数据散落，无法互通。 表单驱动的世界里，每个表单自带一套数据表。客户的联系方式维护在"客户登记表"里，订单关联的客户信息又存在"订单管理表"里，两边的客户名称、电话完全可能不一致。等你想做一张"客户所有订单汇总报表"的时候，只能靠跨表查询或者手动导Excel。换句话说，表单驱动天然缺少一个统一的数据模型层，数据孤岛是从出生就注定的。
瓶颈二：逻辑复用极其困难。 字段级的校验规则、计算逻辑、联动规则，全部挂在某个表单的配置里。你今天在"采购入库单"里写了一段计算库存的逻辑，明天做"销售出库单"时如果也想扣减库存，只能把这段逻辑再写一遍。一旦规则升级，比如要增加"库存不足时拦截出库"，你得到处找"当初在哪个表单里写的这个逻辑"。这种累加式开发在系统规模小的时候还能忍受，到了上百个表单、十几个模块的阶段，维护成本会成倍增长。
瓶颈三：复杂业务表达乏力。 稍微复杂一点的业务结构，比如一张订单带多条明细、多个附件、多级审批、多种变更状态，表单驱动往往只能靠"主子表""子表单""流程分支"这些补丁功能去凑。每凑一个功能，平台的复杂度就上一个台阶，最后维护的还是那些越滚越大的配置文件，写起来和传统开发的代码没什么区别，却没有代码的表达力和调试工具。
所以，表单驱动的问题不是"不好用"，而是"上限太低"。它把"建模"这件事简化成了"配表单"，短期见效快，长期却撑不起复杂业务。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 模型驱动的底层设计逻辑：从配表单到建模型
那模型驱动到底改了什么？一句话概括：**把平台的建模对象从