上一篇写表单引擎时，我提到一个判断：
表单不是页面，而是业务模型的入口。
这句话继续往下走，就会进入低代码平台里更底层的问题：数据模型应该怎么设计？
很多人理解低代码平台，会先看到表单、页面、流程、报表这些显性的功能。但真正决定一个平台能走多远的，往往不是页面搭得多快，而是底层数据模型能不能承载复杂业务。
如果数据模型太弱，表单只是一个个孤立页面。
如果数据模型混乱，流程、权限、报表和 AI 都会变得很难做。
所以这一篇，我想聊聊织信里的数据模型设计。
数据模型不是简单建表
很多系统一开始做数据模型，很容易把它理解成“建几张表、加几个字段”。
比如做 CRM，就建客户表、联系人表、跟进记录表。
做项目管理，就建项目表、任务表、成员表。
做进销存，就建商品表、库存表、采购单、销售单。
这当然是数据模型的一部分，但对低代码平台来说还远远不够。
低代码平台面对的问题是：这些表和字段不是开发人员一次性写死的，而是要让用户在平台里动态创建、调整和扩展。
这就带来一个新的要求：
平台不仅要存业务数据，还要存描述业务数据的数据。
也就是元数据。
一张“客户表”本身是一份配置；客户名称、客户等级、负责人、联系人列表这些字段，也都是配置；字段类型、显示方式、校验规则、权限规则、关联关系，同样是配置。
所以低代码平台的数据模型，本质上是两层：
第一层，是平台自己的元数据模型。
第二层，是用户创建出来的业务数据模型。
前者决定平台能力边界，后者承载企业具体业务。
先抽象业务对象
我在设计数据模型时，首先会问一个问题：
业务里真正存在的对象是什么？
客户是对象。
合同是对象。
订单是对象。
项目是对象。
任务是对象。
设备是对象。
审批单也是对象。
这些对象不是页面，也不是字段集合，而是企业业务中可以被识别、被流转、被关联、被统计的一类东西。
如果只从页面出发，系统会变成“这个页面有什么字段”。
如果从对象出发，系统会变成“这个业务对象有哪些属性、关系和行为”。
这两种思路差别很大。
比如客户对象，不只是客户名称、电话、地址这些字段。它还可能有负责人、客户等级、生命周期阶段、跟进记录、联系人、合同、订单、回款、服务工单。
当我们把客户看成业务对象，后面的流程、权限、报表和 AI 分析才有共同的基础。
字段要有业务语义
字段设计不是简单地选择文本、数字、日期。
字段真正重要的地方，是它能不能表达业务语义。
同样是一个“负责人”，如果设计成普通文本字段，系统只知道这里有几个字。
但如果设计成人员字段，系统就可以知道：
这个负责人对应哪个用户；
属于哪个部门；
能不能接收通知；
是否参与数据权限判断；
能不能作为流程审批人；
能不能用于人员维度统计。
这就是字段语义的价值。
低代码平台里的字段类型，不能只服务于页面展示，还要服务于数据查询、权限判断、流程条件、自动化触发、报表统计和 AI 理解。
比如日期字段可以参与时间筛选和到期提醒。
金额字段可以参与汇总和阈值判断。
状态字段可以参与流程流转和看板分组。
关联字段可以建立业务对象之间的关系。
人员字段可以连接组织架构和权限体系。
字段类型越有语义，平台后面的能力就越容易生长。
关系比字段更容易被低估
很多业务系统复杂，不是因为字段多，而是因为关系复杂。
客户和联系人是一对多。
客户和合同是一对多。
合同和订单可能是一对多。
项目和任务是一对多。
任务和成员可能是多对多。
采购单和商品明细是主从关系。
这些关系如果表达不好，系统就只能做成一堆孤立的数据表。
孤立的数据表很快会遇到问题：
客户详情里看不到历史跟进；
合同里找不到关联客户；
订单无法回溯到项目；
报表无法跨对象统计；
AI 也很难回答“这个客户最近有哪些合同和跟进记录”。
所以数据模型里必须认真对待关联关系。
在低代码平台中，关联关系不只是数据库层面的关系，它还会影响页面展示、权限控制、数据联动、流程条件和报表分析。
一个好的关联字段，不应该只是“存一个 ID”，而应该让平台知道两个业务对象之间是什么关系，以及这种关系可以如何被使用。
动态和稳定之间的平衡
低代码平台天然追求动态。
用户可以动态创建表，动态增加字段，动态调整视图，动态配置流程。
但企业系统又不能无限动态。
因为系统还要考虑性能、查询、统计、权限、安全、升级和维护。
这里就有一个长期存在的矛盾：
如果模型太动态，平台很灵活，但底层会越来越复杂。
如果模型太固定，平台很稳定，但业务变化时又会失去低代码的价值。
所以数据模型设计最重要的不是追求绝对灵活，而是划清边界。
哪些能力应该由用户配置？
哪些能力应该由平台固化？
哪些变化可以通过元数据驱动？
哪些变化必须进入开发扩展？
比如字段、视图、表单布局、基础校验，适合做成配置。
但数据权限、系统审计、底层存储、事务边界、性能索引，就不能完全交给用户随意配置。
平台要给用户自由，但也要帮用户守住系统边界。
数据模型要支撑权限
企业系统里，数据模型和权限模型不能分开看。
谁能看哪些数据？
谁能编辑哪些字段？
谁能删除记录？
谁能导出数据？
谁能查看关联对象？
这些问题都依赖数据模型。
如果数据模型里没有对象、字段、关系这些清晰边界，权限就只能靠代码硬写。
一旦权限靠硬写，低代码平台的灵活性就会下降。
所以在织信这样的系统里，数据模型必须为权限留下位置。
数据表可以对应数据权限。
字段可以对应字段权限。
动作可以对应操作权限。
关联关系可以影响可见范围。
流程节点可以改变某些字段的可编辑状态。
从这个角度看，权限不是后补功能，而是数据模型设计时就要考虑的基础能力。
数据模型要支撑流程
流程引擎也离不开数据模型。
一个采购申请流程，流转的是采购申请这个业务对象。
一个合同审批流程，流转的是合同这个业务对象。
一个项目立项流程，流转的是项目这个业务对象。
流程不是凭空跑起来的，它一定围绕某类业务数据发生。
流程节点上的条件判断，也依赖字段。
比如金额大于 10 万走总经理审批。
合同类型是战略客户，走特殊审核。
申请部门不同，审批路径不同。
当前负责人不同，任务分配不同。
这些都要求数据模型能被流程引擎稳定读取。
如果字段只是页面控件，流程就很难理解它。
如果字段有明确类型和语义，流程条件就可以配置化、可视化、可维护。
数据模型要支撑报表
很多企业系统上线之后，马上就会遇到报表需求。
客户数量按来源统计。
合同金额按月份统计。
项目任务按负责人统计。
库存数量按仓库统计。
销售额按区域统计。
这些看起来是报表问题，其实首先是数据模型问题。
如果字段没有类型，金额就不能正确汇总。
如果日期字段不规范，趋势图就做不好。
如果关联关系不清晰，跨对象统计就会很痛苦。
如果状态字段随便写文本，后续看板和统计都会变乱。
所以报表能力不是等到最后再做。
在设计数据模型时，就要想清楚数据将来会如何被筛选、分组、汇总和分析。
数据模型要支撑 AI
现在再设计低代码平台，必须把 AI 放进来考虑。
AI 想真正进入企业业务，不能只靠聊天窗口。
它需要理解业务对象、字段含义、关系结构、权限范围和可执行动作。
比如用户问：
“帮我分析一下最近 3 个月成交客户的来源。”
AI 需要知道什么是客户，什么是成交，哪个字段代表来源，哪个字段代表成交时间。
用户说：
“帮我给客户表增加一个客户等级字段。”
AI 需要知道客户表在哪里，字段类型应该是什么，是否需要选项，是否影响视图和权限。
用户说：
“这个合同金额超过 10 万时，帮我走总经理审批。”
AI 需要理解合同对象、金额字段、流程条件和审批人规则。
这些能力的前提，都是清晰的数据模型。
没有数据模型，AI 只能生成一段看起来像样的内容。
有了数据模型，AI 才有机会成为真正能参与业务系统建设和运行的助手。
我对第一版数据模型的要求
如果只看第一版，我不会追求把所有复杂能力一次做完。
我更在意几个基础点。
第一，业务对象要清楚。
平台要知道每个数据表代表什么业务对象，而不是只知道它是一张表。
第二，字段类型要有语义。
字段不能只是输入控件，而要能被查询、权限、流程、报表和 AI 使用。
第三，关系要能表达。
至少要支持常见的一对一、一对多、主从、关联记录、关联汇总等场景。
第四，模型要能演进。
用户后续增加字段、调整关系、修改视图时，系统不能轻易崩掉。
第五，平台要守住边界。
低代码不是无限自由，而是在可控边界内让业务快速变化。
踩过的一些坑
做数据模型，最容易踩的坑有几个。
第一个坑，是把字段当页面控件。
这样前期很快，但后面做流程、权限、统计和 AI 时会发现字段缺少语义。
第二个坑，是低估关联关系。
企业业务很少是单表业务。客户、合同、订单、项目、任务之间的关系，才是系统复杂度真正来源。
第三个坑，是过度动态。
什么都让用户配，短期看很强，长期看会让平台变得不可控。
第四个坑，是后补权限。
权限如果不进入数据模型，后面字段级权限、数据范围、流程节点权限都会变得很重。
第五个坑，是没有为 AI 留语义。
如果字段、关系、动作都只是技术配置，AI 就很难理解业务含义。
写在最后
数据模型是低代码平台最底层、也最容易被忽视的能力之一。
表单、流程、权限、报表、AI，看起来是不同模块，但它们最终都会回到同一个问题：
平台是否有一套清晰、稳定、可演进的数据模型？
在我看来，低代码平台真正的价值，不是让用户少写几行代码，而是把企业业务抽象成可以持续演进的模型。
表单是入口。
数据模型是底座。
流程、权限、报表和 AI，都是在这个底座上继续生长出来的能力。
这也是我做织信时越来越确定的一件事：
平台型产品不能只追求功能多，而要把底层模型想清楚。
模型清楚，功能才有根。
